Reducing the jsf.js filesize

[Werner Punz <we...@gmail.com>]

Hello I just want to start another discussion.

I have been checking the filesizes today of our jsf.js. We currently 
have 106kbyte compressed. While this is tolerable I would suggest following.
I tried a quick test where I stripped out all exeperimental non spec 
features like the iframe transport the internationalized strings etc...

I came down to 76 kbytes. I probably by even more strict code stripping 
would come down below 70Kbytes like we used to have before introducing 
the internationalisation and iframe features.

Now here is are a few proposals:
a) We could externalize all the internationalisation into a separate js 
file something like myfaces_extras.js. Our code fortunately is structued 
in a way that this would be easily achievable.

This however would induce a second request. And we would have a 
documentation problem to notify our users.

b) We could roll a jsf_minimized.js with all the features stripped and 
we could patch the implementation accordingly, that if this script is 
included the standard jsf.js is not included anymore.

c) Or we could go vice versa, making line in a the jsf.js the minized 
version and add a full blown jsf_maximized.js to the mix.

What is your opinon about it. I personally think there must be at least
one minimized version in the system which does not show localized 
messages etc...

Werner

Re: Reducing the jsf.js filesize

[Werner Punz <we...@gmail.com>]

Ok here are a few initial numbers

jsf.js for modern browsers without i18n about 67k
jsf.js with legacy browser support 68k
legacy browser support standalone 11k
i18n support roughly 28k
experimental features 14.6 KB

jsf.js all features on 106 kbyte (our current jsf.js)

There is still some room to get those numbers a little bit down. But for 
now I am pretty happy with the result.


I finally also found out why one of my performance tests was roughly 10% 
slower than Mojarra on modern browsers( the funny part was that on IE it 
was faster), it was a lot of IE fallback code which seemed to be walked 
through. By removing that one for dom level 3 compliant browsers, I was 
able to get up to the same speed on that test which used to be slower.


Werner



Am 10/17/11 6:31 PM, schrieb Bernd Bohmann:
> Thanks Werner
>
> +1 for b
>
> Regards
>
> Bernd
>
>
>
> On Mon, Oct 17, 2011 at 5:58 PM, Werner Punz<we...@gmail.com>  wrote:
>> Ok I am doing a major code reorg now, since no one answered. Here is the
>> deal.
>>
>> I will roll several jsf.js packages
>> a) A full package with everything
>> b) A minimal package without i18n support and additional features but ie6
>> support included
>> c) An even smaller package with legacy browser support stripped and only
>> the latest browsers supported
>>
>> Additional packages which can be combined with b an c
>> i18n support for the additional languages
>> legacy browser support
>> experimental (non jsf 2.1 spec) features
>>
>>
>> I think that should give the users the possibility to choose and combine
>> what they need.
>>
>> I have not detailed filesize numbers but the overall package should be
>> slightly bigger while the minimal packages should be significantly smaller.
>> (Most people probably do not need the client side i18n for instance and the
>> additional features like the iframe file submit, while
>> mobile platforms as target can strip the entire legacy browser support out)
>>
>> I am not sure which package in the future will be default for the standard
>> jsf.js, but I assume b) would make sense and a proper documentation on how
>> to include the rest.
>>
>> The good news is that the code reorg helped me to isolate a load ie 6 and
>> old mobile browser related code, which in the future then can be dropped in
>> an instance.
>>
>>
>> Werner
>>
>>
>>
>> Am 10/14/11 1:51 PM, schrieb Werner Punz:
>>>
>>> Hello I just want to start another discussion.
>>>
>>> I have been checking the filesizes today of our jsf.js. We currently
>>> have 106kbyte compressed. While this is tolerable I would suggest
>>> following.
>>> I tried a quick test where I stripped out all exeperimental non spec
>>> features like the iframe transport the internationalized strings etc...
>>>
>>> I came down to 76 kbytes. I probably by even more strict code stripping
>>> would come down below 70Kbytes like we used to have before introducing
>>> the internationalisation and iframe features.
>>>
>>> Now here is are a few proposals:
>>> a) We could externalize all the internationalisation into a separate js
>>> file something like myfaces_extras.js. Our code fortunately is structued
>>> in a way that this would be easily achievable.
>>>
>>> This however would induce a second request. And we would have a
>>> documentation problem to notify our users.
>>>
>>> b) We could roll a jsf_minimized.js with all the features stripped and
>>> we could patch the implementation accordingly, that if this script is
>>> included the standard jsf.js is not included anymore.
>>>
>>> c) Or we could go vice versa, making line in a the jsf.js the minized
>>> version and add a full blown jsf_maximized.js to the mix.
>>>
>>> What is your opinon about it. I personally think there must be at least
>>> one minimized version in the system which does not show localized
>>> messages etc...
>>>
>>> Werner
>>>
>>>
>>
>>
>>
>

Re: Reducing the jsf.js filesize

[Bernd Bohmann <be...@atanion.com>]

Thanks Werner

+1 for b

Regards

Bernd



On Mon, Oct 17, 2011 at 5:58 PM, Werner Punz <we...@gmail.com> wrote:
> Ok I am doing a major code reorg now, since no one answered. Here is the
> deal.
>
> I will roll several jsf.js packages
> a) A full package with everything
> b) A minimal package without i18n support and additional features but ie6
> support included
> c) An even smaller package with legacy browser support stripped and only
> the latest browsers supported
>
> Additional packages which can be combined with b an c
> i18n support for the additional languages
> legacy browser support
> experimental (non jsf 2.1 spec) features
>
>
> I think that should give the users the possibility to choose and combine
> what they need.
>
> I have not detailed filesize numbers but the overall package should be
> slightly bigger while the minimal packages should be significantly smaller.
> (Most people probably do not need the client side i18n for instance and the
> additional features like the iframe file submit, while
> mobile platforms as target can strip the entire legacy browser support out)
>
> I am not sure which package in the future will be default for the standard
> jsf.js, but I assume b) would make sense and a proper documentation on how
> to include the rest.
>
> The good news is that the code reorg helped me to isolate a load ie 6 and
> old mobile browser related code, which in the future then can be dropped in
> an instance.
>
>
> Werner
>
>
>
> Am 10/14/11 1:51 PM, schrieb Werner Punz:
>>
>> Hello I just want to start another discussion.
>>
>> I have been checking the filesizes today of our jsf.js. We currently
>> have 106kbyte compressed. While this is tolerable I would suggest
>> following.
>> I tried a quick test where I stripped out all exeperimental non spec
>> features like the iframe transport the internationalized strings etc...
>>
>> I came down to 76 kbytes. I probably by even more strict code stripping
>> would come down below 70Kbytes like we used to have before introducing
>> the internationalisation and iframe features.
>>
>> Now here is are a few proposals:
>> a) We could externalize all the internationalisation into a separate js
>> file something like myfaces_extras.js. Our code fortunately is structued
>> in a way that this would be easily achievable.
>>
>> This however would induce a second request. And we would have a
>> documentation problem to notify our users.
>>
>> b) We could roll a jsf_minimized.js with all the features stripped and
>> we could patch the implementation accordingly, that if this script is
>> included the standard jsf.js is not included anymore.
>>
>> c) Or we could go vice versa, making line in a the jsf.js the minized
>> version and add a full blown jsf_maximized.js to the mix.
>>
>> What is your opinon about it. I personally think there must be at least
>> one minimized version in the system which does not show localized
>> messages etc...
>>
>> Werner
>>
>>
>
>
>

Re: Reducing the jsf.js filesize

[Werner Punz <we...@gmail.com>]

Ok I am doing a major code reorg now, since no one answered. Here is the 
deal.

I will roll several jsf.js packages
a) A full package with everything
b) A minimal package without i18n support and additional features but 
ie6 support included
c) An even smaller package with legacy browser support stripped and only
the latest browsers supported

Additional packages which can be combined with b an c
i18n support for the additional languages
legacy browser support
experimental (non jsf 2.1 spec) features


I think that should give the users the possibility to choose and combine 
what they need.

I have not detailed filesize numbers but the overall package should be 
slightly bigger while the minimal packages should be significantly 
smaller. (Most people probably do not need the client side i18n for 
instance and the additional features like the iframe file submit, while
mobile platforms as target can strip the entire legacy browser support out)

I am not sure which package in the future will be default for the 
standard jsf.js, but I assume b) would make sense and a proper 
documentation on how to include the rest.

The good news is that the code reorg helped me to isolate a load ie 6 
and old mobile browser related code, which in the future then can be 
dropped in an instance.


Werner



Am 10/14/11 1:51 PM, schrieb Werner Punz:
> Hello I just want to start another discussion.
>
> I have been checking the filesizes today of our jsf.js. We currently
> have 106kbyte compressed. While this is tolerable I would suggest
> following.
> I tried a quick test where I stripped out all exeperimental non spec
> features like the iframe transport the internationalized strings etc...
>
> I came down to 76 kbytes. I probably by even more strict code stripping
> would come down below 70Kbytes like we used to have before introducing
> the internationalisation and iframe features.
>
> Now here is are a few proposals:
> a) We could externalize all the internationalisation into a separate js
> file something like myfaces_extras.js. Our code fortunately is structued
> in a way that this would be easily achievable.
>
> This however would induce a second request. And we would have a
> documentation problem to notify our users.
>
> b) We could roll a jsf_minimized.js with all the features stripped and
> we could patch the implementation accordingly, that if this script is
> included the standard jsf.js is not included anymore.
>
> c) Or we could go vice versa, making line in a the jsf.js the minized
> version and add a full blown jsf_maximized.js to the mix.
>
> What is your opinon about it. I personally think there must be at least
> one minimized version in the system which does not show localized
> messages etc...
>
> Werner
>
>