Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Etienne Basso]

Yes I confirm this.  For using SSO I had to set only one language. 

I do multiple build manually for each language until I find a better solution. 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Etienne Basso]

Yes I use SSO and Cc from gwt 2.7
I also use other optimizations like XdisableClassMetadata and 
XdisableCastChecking. 

I also use smaller css class names:


In my very specific case this makes a big difference. 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Slava Pankov]

Still not working for me.

  
  
  
  

[ERROR] The module must not have multiple fragments when using the Single 
Script Linker.

Probably the problem is that I have many languages (i18n) in my app.
Any other ideas?


On Wednesday, November 30, 2016 at 11:08:13 PM UTC-8, Kirill Prazdnikov 
wrote:
>
> Please try single permutation
>   
>
>
> On Thu, Dec 1, 2016 at 1:50 AM, Slava Pankov  > wrote:
>
>> SSO is not working for my project, I cannot successfully compile with it.
>> Put the following to my gwt.xml, but no luck:
>>
>> 
>> 
>> 
>>
>>
>> On Tuesday, November 29, 2016 at 6:44:37 AM UTC-8, Kirill Prazdnikov 
>> wrote:
>>>
>>> Do you use SSO ? SSO script is smaller then no SSO. Did you run CC on it 
>>> ?
>>>
>>> 29 нояб. 2016 г. 17:29 пользователь "Etienne Basso"  
>>> написал:
>>>
>>> Hi Ignacio,

 This is not only about loading time over the network, but also about 
 script parsing by the web browser. 
 In 98% of the case this is not an issue, but I have a very specific use 
 case were the code is directly embedded on a special device which doesn't 
 even have a real CPU but an ASIC emulating one. This device is really 
 really not powerful and GWT is the only framework providing decent speed.  
 I noticed significant differences in the script parsing delay as js 
 sources 
 are getting bigger.

 In my case 100KB are a huge deal.

 Le samedi 26 novembre 2016 09:56:27 UTC+1, Ignacio Baca Moreno-Torres a 
 écrit :
>
> But IMO if you really care user experience you have other places to 
> improve your page. I thinks updating to the last version is always a good 
> idea, if any security or compatibility blocker problem is detected in 
> your 
> version you will need to update, and having a old version won't help. 
> Also 
> this helps move forward the community and the lib (GWT), because everyone 
> focused in the last version, also focus the issues and improvements in 
> that 
> version.
>
> The small step back eliminating the closure compiler just increase a 
> bit the code size of your app. But 100k?! did you see the trends and the 
> average code size of webs? 
> http://httparchive.org/trends.php?s=All=Nov+15+2014=Nov+1+2016,
>  
> you should note that even google.com uses 500k in 13request to load, 
> and it's ""just"" a text inbox in the center of your window (
> http://httparchive.org/viewsite.php?pageid=70036564).
>
> I might be wrong, but probably trying to embed the app.nocache.js in 
> your index.html will gain some milliseconds, probably just that dummy 
> change will get more ms than the cache-ables 100k you have lose without 
> the 
> closure pass. If your app is quite big, various MBs, you should take care 
> than the first split point load a minimum as possible to show something 
> to 
> the user. But, in your case, less than a 1M, I think that using split 
> point 
> is not a good idea. Your code will get cached, and most of static apps 
> already has more than 500k of JS, so your single page app having a 
> 500k-1M 
> of JS is pretty reasonable.
>
> You can go forward and apply the progressive web concepts (
> https://developers.google.com/web/progressive-web-apps/checklist). 
> Pretty sure you get there without the closure compiler ;). Service 
> workers 
> will allow maximum control to preload other split point or resources, and 
> to absolutely control how your app caches, so you can use previous 
> version, 
> load the next one and in the next page reload the new app version will be 
> used. This is not easy at all, but... some time we focus on the 
> optimization we have no control of (like the closure pass) and we don't 
> apply other we have control of, but that requires our effort.
>
> So,  update to GWT 2.8! it's awesome!, try other solutions to 
> improve page loads and share how you do it!
>
> On Friday, November 25, 2016 at 10:39:44 PM UTC+1, Slava Pankov wrote:
>>
>> @Jens
>>
>> I've tried WITHOUT any success to use closure compiler externally 
>> with GWT 2.8
>> See my question here: 
>> https://groups.google.com/forum/#!searchin/google-web-toolkit/closure$20compiler%7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ
>> Still want to find out exact steps to get it working :-(
>>
>>
>> On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov 
>> wrote:
>>>
>>> Hi Jens, 
>>>
>>> What if we have SSO linker ? 
>>> Then no hacks is needed, right ?
>>> Then just run the Google Closure Compiler on the output.
>>>
>> -- 

 -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "GWT Users" group.
>> To unsubscribe from this topic, visit 

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Kirill Prazdnikov]

Please try single permutation
  


On Thu, Dec 1, 2016 at 1:50 AM, Slava Pankov  wrote:

> SSO is not working for my project, I cannot successfully compile with it.
> Put the following to my gwt.xml, but no luck:
>
> 
> 
> 
>
>
> On Tuesday, November 29, 2016 at 6:44:37 AM UTC-8, Kirill Prazdnikov wrote:
>>
>> Do you use SSO ? SSO script is smaller then no SSO. Did you run CC on it ?
>>
>> 29 нояб. 2016 г. 17:29 пользователь "Etienne Basso" 
>> написал:
>>
>> Hi Ignacio,
>>>
>>> This is not only about loading time over the network, but also about
>>> script parsing by the web browser.
>>> In 98% of the case this is not an issue, but I have a very specific use
>>> case were the code is directly embedded on a special device which doesn't
>>> even have a real CPU but an ASIC emulating one. This device is really
>>> really not powerful and GWT is the only framework providing decent speed.
>>> I noticed significant differences in the script parsing delay as js sources
>>> are getting bigger.
>>>
>>> In my case 100KB are a huge deal.
>>>
>>> Le samedi 26 novembre 2016 09:56:27 UTC+1, Ignacio Baca Moreno-Torres a
>>> écrit :

 But IMO if you really care user experience you have other places to
 improve your page. I thinks updating to the last version is always a good
 idea, if any security or compatibility blocker problem is detected in your
 version you will need to update, and having a old version won't help. Also
 this helps move forward the community and the lib (GWT), because everyone
 focused in the last version, also focus the issues and improvements in that
 version.

 The small step back eliminating the closure compiler just increase a
 bit the code size of your app. But 100k?! did you see the trends and the
 average code size of webs? http://httparchive.org/t
 rends.php?s=All=Nov+15+2014=Nov+1+2016, you should
 note that even google.com uses 500k in 13request to load, and it's
 ""just"" a text inbox in the center of your window (
 http://httparchive.org/viewsite.php?pageid=70036564).

 I might be wrong, but probably trying to embed the app.nocache.js in
 your index.html will gain some milliseconds, probably just that dummy
 change will get more ms than the cache-ables 100k you have lose without the
 closure pass. If your app is quite big, various MBs, you should take care
 than the first split point load a minimum as possible to show something to
 the user. But, in your case, less than a 1M, I think that using split point
 is not a good idea. Your code will get cached, and most of static apps
 already has more than 500k of JS, so your single page app having a 500k-1M
 of JS is pretty reasonable.

 You can go forward and apply the progressive web concepts (
 https://developers.google.com/web/progressive-web-apps/checklist).
 Pretty sure you get there without the closure compiler ;). Service workers
 will allow maximum control to preload other split point or resources, and
 to absolutely control how your app caches, so you can use previous version,
 load the next one and in the next page reload the new app version will be
 used. This is not easy at all, but... some time we focus on the
 optimization we have no control of (like the closure pass) and we don't
 apply other we have control of, but that requires our effort.

 So,  update to GWT 2.8! it's awesome!, try other solutions to improve
 page loads and share how you do it!

 On Friday, November 25, 2016 at 10:39:44 PM UTC+1, Slava Pankov wrote:
>
> @Jens
>
> I've tried WITHOUT any success to use closure compiler externally with
> GWT 2.8
> See my question here: https://groups.google.co
> m/forum/#!searchin/google-web-toolkit/closure$20compiler%
> 7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ
> Still want to find out exact steps to get it working :-(
>
>
> On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov
> wrote:
>>
>> Hi Jens,
>>
>> What if we have SSO linker ?
>> Then no hacks is needed, right ?
>> Then just run the Google Closure Compiler on the output.
>>
> --
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/google-web-toolkit/IIQk4xH0-g8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe 

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Slava Pankov]

SSO is not working for my project, I cannot successfully compile with it.
Put the following to my gwt.xml, but no luck:






On Tuesday, November 29, 2016 at 6:44:37 AM UTC-8, Kirill Prazdnikov wrote:
>
> Do you use SSO ? SSO script is smaller then no SSO. Did you run CC on it ?
>
> 29 нояб. 2016 г. 17:29 пользователь "Etienne Basso"  > написал:
>
>> Hi Ignacio,
>>
>> This is not only about loading time over the network, but also about 
>> script parsing by the web browser. 
>> In 98% of the case this is not an issue, but I have a very specific use 
>> case were the code is directly embedded on a special device which doesn't 
>> even have a real CPU but an ASIC emulating one. This device is really 
>> really not powerful and GWT is the only framework providing decent speed.  
>> I noticed significant differences in the script parsing delay as js sources 
>> are getting bigger.
>>
>> In my case 100KB are a huge deal.
>>
>> Le samedi 26 novembre 2016 09:56:27 UTC+1, Ignacio Baca Moreno-Torres a 
>> écrit :
>>>
>>> But IMO if you really care user experience you have other places to 
>>> improve your page. I thinks updating to the last version is always a good 
>>> idea, if any security or compatibility blocker problem is detected in your 
>>> version you will need to update, and having a old version won't help. Also 
>>> this helps move forward the community and the lib (GWT), because everyone 
>>> focused in the last version, also focus the issues and improvements in that 
>>> version.
>>>
>>> The small step back eliminating the closure compiler just increase a bit 
>>> the code size of your app. But 100k?! did you see the trends and the 
>>> average code size of webs? 
>>> http://httparchive.org/trends.php?s=All=Nov+15+2014=Nov+1+2016,
>>>  
>>> you should note that even google.com uses 500k in 13request to load, 
>>> and it's ""just"" a text inbox in the center of your window (
>>> http://httparchive.org/viewsite.php?pageid=70036564).
>>>
>>> I might be wrong, but probably trying to embed the app.nocache.js in 
>>> your index.html will gain some milliseconds, probably just that dummy 
>>> change will get more ms than the cache-ables 100k you have lose without the 
>>> closure pass. If your app is quite big, various MBs, you should take care 
>>> than the first split point load a minimum as possible to show something to 
>>> the user. But, in your case, less than a 1M, I think that using split point 
>>> is not a good idea. Your code will get cached, and most of static apps 
>>> already has more than 500k of JS, so your single page app having a 500k-1M 
>>> of JS is pretty reasonable.
>>>
>>> You can go forward and apply the progressive web concepts (
>>> https://developers.google.com/web/progressive-web-apps/checklist). 
>>> Pretty sure you get there without the closure compiler ;). Service workers 
>>> will allow maximum control to preload other split point or resources, and 
>>> to absolutely control how your app caches, so you can use previous version, 
>>> load the next one and in the next page reload the new app version will be 
>>> used. This is not easy at all, but... some time we focus on the 
>>> optimization we have no control of (like the closure pass) and we don't 
>>> apply other we have control of, but that requires our effort.
>>>
>>> So,  update to GWT 2.8! it's awesome!, try other solutions to improve 
>>> page loads and share how you do it!
>>>
>>> On Friday, November 25, 2016 at 10:39:44 PM UTC+1, Slava Pankov wrote:

 @Jens

 I've tried WITHOUT any success to use closure compiler externally with 
 GWT 2.8
 See my question here: 
 https://groups.google.com/forum/#!searchin/google-web-toolkit/closure$20compiler%7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ
 Still want to find out exact steps to get it working :-(


 On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov 
 wrote:
>
> Hi Jens, 
>
> What if we have SSO linker ? 
> Then no hacks is needed, right ?
> Then just run the Google Closure Compiler on the output.
>
 -- 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Kirill Prazdnikov]

Do you use SSO ? SSO script is smaller then no SSO. Did you run CC on it ?

29 нояб. 2016 г. 17:29 пользователь "Etienne Basso" 
написал:

> Hi Ignacio,
>
> This is not only about loading time over the network, but also about
> script parsing by the web browser.
> In 98% of the case this is not an issue, but I have a very specific use
> case were the code is directly embedded on a special device which doesn't
> even have a real CPU but an ASIC emulating one. This device is really
> really not powerful and GWT is the only framework providing decent speed.
> I noticed significant differences in the script parsing delay as js sources
> are getting bigger.
>
> In my case 100KB are a huge deal.
>
> Le samedi 26 novembre 2016 09:56:27 UTC+1, Ignacio Baca Moreno-Torres a
> écrit :
>>
>> But IMO if you really care user experience you have other places to
>> improve your page. I thinks updating to the last version is always a good
>> idea, if any security or compatibility blocker problem is detected in your
>> version you will need to update, and having a old version won't help. Also
>> this helps move forward the community and the lib (GWT), because everyone
>> focused in the last version, also focus the issues and improvements in that
>> version.
>>
>> The small step back eliminating the closure compiler just increase a bit
>> the code size of your app. But 100k?! did you see the trends and the
>> average code size of webs? http://httparchive.org/t
>> rends.php?s=All=Nov+15+2014=Nov+1+2016, you should
>> note that even google.com uses 500k in 13request to load, and it's
>> ""just"" a text inbox in the center of your window (
>> http://httparchive.org/viewsite.php?pageid=70036564).
>>
>> I might be wrong, but probably trying to embed the app.nocache.js in your
>> index.html will gain some milliseconds, probably just that dummy change
>> will get more ms than the cache-ables 100k you have lose without the
>> closure pass. If your app is quite big, various MBs, you should take care
>> than the first split point load a minimum as possible to show something to
>> the user. But, in your case, less than a 1M, I think that using split point
>> is not a good idea. Your code will get cached, and most of static apps
>> already has more than 500k of JS, so your single page app having a 500k-1M
>> of JS is pretty reasonable.
>>
>> You can go forward and apply the progressive web concepts (
>> https://developers.google.com/web/progressive-web-apps/checklist).
>> Pretty sure you get there without the closure compiler ;). Service workers
>> will allow maximum control to preload other split point or resources, and
>> to absolutely control how your app caches, so you can use previous version,
>> load the next one and in the next page reload the new app version will be
>> used. This is not easy at all, but... some time we focus on the
>> optimization we have no control of (like the closure pass) and we don't
>> apply other we have control of, but that requires our effort.
>>
>> So,  update to GWT 2.8! it's awesome!, try other solutions to improve
>> page loads and share how you do it!
>>
>> On Friday, November 25, 2016 at 10:39:44 PM UTC+1, Slava Pankov wrote:
>>>
>>> @Jens
>>>
>>> I've tried WITHOUT any success to use closure compiler externally with
>>> GWT 2.8
>>> See my question here: https://groups.google.co
>>> m/forum/#!searchin/google-web-toolkit/closure$20compiler%
>>> 7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ
>>> Still want to find out exact steps to get it working :-(
>>>
>>>
>>> On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov
>>> wrote:

 Hi Jens,

 What if we have SSO linker ?
 Then no hacks is needed, right ?
 Then just run the Google Closure Compiler on the output.

>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/google-web-toolkit/IIQk4xH0-g8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Etienne Basso]

Hi Ignacio,

This is not only about loading time over the network, but also about script 
parsing by the web browser. 
In 98% of the case this is not an issue, but I have a very specific use 
case were the code is directly embedded on a special device which doesn't 
even have a real CPU but an ASIC emulating one. This device is really 
really not powerful and GWT is the only framework providing decent speed. 
 I noticed significant differences in the script parsing delay as js 
sources are getting bigger.

In my case 100KB are a huge deal.

Le samedi 26 novembre 2016 09:56:27 UTC+1, Ignacio Baca Moreno-Torres a 
écrit :
>
> But IMO if you really care user experience you have other places to 
> improve your page. I thinks updating to the last version is always a good 
> idea, if any security or compatibility blocker problem is detected in your 
> version you will need to update, and having a old version won't help. Also 
> this helps move forward the community and the lib (GWT), because everyone 
> focused in the last version, also focus the issues and improvements in that 
> version.
>
> The small step back eliminating the closure compiler just increase a bit 
> the code size of your app. But 100k?! did you see the trends and the 
> average code size of webs? 
> http://httparchive.org/trends.php?s=All=Nov+15+2014=Nov+1+2016,
>  
> you should note that even google.com uses 500k in 13request to load, and 
> it's ""just"" a text inbox in the center of your window (
> http://httparchive.org/viewsite.php?pageid=70036564).
>
> I might be wrong, but probably trying to embed the app.nocache.js in your 
> index.html will gain some milliseconds, probably just that dummy change 
> will get more ms than the cache-ables 100k you have lose without the 
> closure pass. If your app is quite big, various MBs, you should take care 
> than the first split point load a minimum as possible to show something to 
> the user. But, in your case, less than a 1M, I think that using split point 
> is not a good idea. Your code will get cached, and most of static apps 
> already has more than 500k of JS, so your single page app having a 500k-1M 
> of JS is pretty reasonable.
>
> You can go forward and apply the progressive web concepts (
> https://developers.google.com/web/progressive-web-apps/checklist). Pretty 
> sure you get there without the closure compiler ;). Service workers will 
> allow maximum control to preload other split point or resources, and to 
> absolutely control how your app caches, so you can use previous version, 
> load the next one and in the next page reload the new app version will be 
> used. This is not easy at all, but... some time we focus on the 
> optimization we have no control of (like the closure pass) and we don't 
> apply other we have control of, but that requires our effort.
>
> So,  update to GWT 2.8! it's awesome!, try other solutions to improve 
> page loads and share how you do it!
>
> On Friday, November 25, 2016 at 10:39:44 PM UTC+1, Slava Pankov wrote:
>>
>> @Jens
>>
>> I've tried WITHOUT any success to use closure compiler externally with 
>> GWT 2.8
>> See my question here: 
>> https://groups.google.com/forum/#!searchin/google-web-toolkit/closure$20compiler%7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ
>> Still want to find out exact steps to get it working :-(
>>
>>
>> On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov wrote:
>>>
>>> Hi Jens, 
>>>
>>> What if we have SSO linker ? 
>>> Then no hacks is needed, right ?
>>> Then just run the Google Closure Compiler on the output.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Slava Pankov]

No, I have not tried SSO. But in 2.7 it was working fine without SSO, I 
will try SSO and let you know.

On Saturday, November 26, 2016 at 12:55:25 AM UTC-8, Kirill Prazdnikov 
wrote:
>
> Hi
>  
>
>> I've tried WITHOUT any success to use closure compiler externally with 
>> GWT 2.8
>>
>
> Did you try SSO ? Did you run Closure Compiler on SSO output script ?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Kirill Prazdnikov]

I have some glue. Google JS Compiler used in chrome is able to detect some
patterns and jit. But some patterns are not detected.

Ex: for are deceted, do ... while sometimes not.

It happens so that GWT produce patterns detectable for JS Compiler. And
Closure can break that structure.

I am happy that GWT dropped cl suppert and focus on JsInterop (where is
JsIndexer?)

28 нояб. 2016 г. 11:04 пользователь "Frank" 
написал:

> I am also interested in answers to this question.
>
> When Closure became available in GWT I did many real world tests on real
> world projects. And in the end the code compiled with closure was slower in
> every case (although smaller). So I never understood why anyone would want
> to use that closure compile on top of gwt compile.
>
> Op donderdag 24 november 2016 15:05:50 UTC+1 schreef Kirill Prazdnikov:
>>
>> Do you have performance measurements ?
>> Did the performance better for 2.7 ?
>> Did you measured real transfer traffic (web server supports real-time GZ
>> compression over HTTP) ?
>>
>> Thanks
>>
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "GWT Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/google-web-toolkit/IIQk4xH0-g8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Frank]

I am also interested in answers to this question.

When Closure became available in GWT I did many real world tests on real 
world projects. And in the end the code compiled with closure was slower in 
every case (although smaller). So I never understood why anyone would want 
to use that closure compile on top of gwt compile.

Op donderdag 24 november 2016 15:05:50 UTC+1 schreef Kirill Prazdnikov:
>
> Do you have performance measurements ? 
> Did the performance better for 2.7 ?  
> Did you measured real transfer traffic (web server supports real-time GZ 
> compression over HTTP) ?
>
> Thanks
>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Ignacio Baca Moreno-Torres]

But IMO if you really care user experience you have other places to improve 
your page. I thinks updating to the last version is always a good idea, if 
any security or compatibility blocker problem is detected in your version 
you will need to update, and having a old version won't help. Also this 
helps move forward the community and the lib (GWT), because everyone 
focused in the last version, also focus the issues and improvements in that 
version.

The small step back eliminating the closure compiler just increase a bit 
the code size of your app. But 100k?! did you see the trends and the 
average code size of 
webs? 
http://httparchive.org/trends.php?s=All=Nov+15+2014=Nov+1+2016,
 
you should note that even google.com uses 500k in 13request to load, and 
it's ""just"" a text inbox in the center of your window 
(http://httparchive.org/viewsite.php?pageid=70036564).

I might be wrong, but probably trying to embed the app.nocache.js in your 
index.html will gain some milliseconds, probably just that dummy change 
will get more ms than the cache-ables 100k you have lose without the 
closure pass. If your app is quite big, various MBs, you should take care 
than the first split point load a minimum as possible to show something to 
the user. But, in your case, less than a 1M, I think that using split point 
is not a good idea. Your code will get cached, and most of static apps 
already has more than 500k of JS, so your single page app having a 500k-1M 
of JS is pretty reasonable.

You can go forward and apply the progressive web concepts 
(https://developers.google.com/web/progressive-web-apps/checklist). Pretty 
sure you get there without the closure compiler ;). Service workers will 
allow maximum control to preload other split point or resources, and to 
absolutely control how your app caches, so you can use previous version, 
load the next one and in the next page reload the new app version will be 
used. This is not easy at all, but... some time we focus on the 
optimization we have no control of (like the closure pass) and we don't 
apply other we have control of, but that requires our effort.

So,  update to GWT 2.8! it's awesome!, try other solutions to improve 
page loads and share how you do it!

On Friday, November 25, 2016 at 10:39:44 PM UTC+1, Slava Pankov wrote:
>
> @Jens
>
> I've tried WITHOUT any success to use closure compiler externally with GWT 
> 2.8
> See my question here: 
> https://groups.google.com/forum/#!searchin/google-web-toolkit/closure$20compiler%7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ
> Still want to find out exact steps to get it working :-(
>
>
> On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov wrote:
>>
>> Hi Jens, 
>>
>> What if we have SSO linker ? 
>> Then no hacks is needed, right ?
>> Then just run the Google Closure Compiler on the output.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Kirill Prazdnikov]

Hi
 

> I've tried WITHOUT any success to use closure compiler externally with GWT 
> 2.8
>

Did you try SSO ? Did you run Closure Compiler on SSO output script ?


-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Slava Pankov]

@Jens

I've tried WITHOUT any success to use closure compiler externally with GWT 
2.8
See my question 
here: 
https://groups.google.com/forum/#!searchin/google-web-toolkit/closure$20compiler%7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ
Still want to find out exact steps to get it working :-(


On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov wrote:
>
> Hi Jens, 
>
> What if we have SSO linker ? 
> Then no hacks is needed, right ?
> Then just run the Google Closure Compiler on the output.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Kirill Prazdnikov]

Hi Jens,

What if we have SSO linker ?
Then no hacks is needed, right ?
Then just run the Google Closure Compiler on the output.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Óscar Frías Barranco]

> Do you have a step by step guide to run the closure compiler externally ?
>>
>
> Basically you would need to replicate what has been done programmatically
> in the removed ClosureJsRunner class. See commit
>
> https://github.com/gwtproject/gwt/commit/162ccc9c9112a09bf9e
> a046da95760f5f1886b72
>
> Looks like you have to
> - define your own gwt_externs file to tell Closure Compiler which special
> GWT variables not to rename
> - maybe create a hack.js file that exports gwtOnLoad function so it does
> not get removed by Closure Compiler. Maybe its not needed if also passing
> in the .nocache.js file to Closure compiler. no idea.
> - Give Closure Compiler the GWT output (your *.cache.js files including
> split points) in the correct ordering as split point files have
> dependencies (initial fragment, leftover, split points)
>



Thanks for your help, but unfortunately this does not look like a simple
process to implement for GWT users like us.  For the moment we will remain
in GWT 2.7 which generates a smaller code for our website, and hoping that
future GWT versions will be able to reduce or at least maintain the same
code size as version 2.7

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Jens]

> Do you have a step by step guide to run the closure compiler externally ?
>

Basically you would need to replicate what has been done programmatically 
in the removed ClosureJsRunner class. See commit

https://github.com/gwtproject/gwt/commit/162ccc9c9112a09bf9ea046da95760f5f1886b72

Looks like you have to
- define your own gwt_externs file to tell Closure Compiler which special 
GWT variables not to rename
- maybe create a hack.js file that exports gwtOnLoad function so it does 
not get removed by Closure Compiler. Maybe its not needed if also passing 
in the .nocache.js file to Closure compiler. no idea.
- Give Closure Compiler the GWT output (your *.cache.js files including 
split points) in the correct ordering as split point files have 
dependencies (initial fragment, leftover, split points)


-- J.



-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Óscar Frías Barranco]

>
> And why don't keep it experimental too in 2.8 instead of removing it?
>>
>
> Why keeping it if it's only half baked into GWT and you can run it
> externally as well?
>


Do you have a step by step guide to run the closure compiler externally ?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Jens]

> And why don't keep it experimental too in 2.8 instead of removing it?
>

Why keeping it if it's only half baked into GWT and you can run it 
externally as well? 

But I guess part of the reason to delete it is because GWT is in the 
process of cleaning itself up to move forward to GWT 3.0. Given that it is 
very likely that GWT 3.0 will be based on the upcoming J2CL compiler, you 
will probably need to run Closure Compiler manually as part of your build 
process (Gradle, Maven, whatever) anyways if you switch to GWT 3.0.

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Kirill Prazdnikov]

Hi,

I think you can
  - enable single permutation, single script linker
  - run the tool from maven build: apply gwt maven plugin, and then apply
required version of Closure Compiler



On Thu, Nov 24, 2016 at 5:43 PM, Óscar Frías Barranco 
wrote:
>
>
>> Do you plan to bring Closure Compiler (-XenableClosureCompiler option)
>>> back to GWT? It was very useful for us.
>>>
>>
>> No. It was experimental and had some rough edges that haven't been fully
>> implemented.
>>
>
>
> And why don't keep it experimental too in 2.8 instead of removing it?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Óscar Frías Barranco]

> Do you plan to bring Closure Compiler (-XenableClosureCompiler option)
>> back to GWT? It was very useful for us.
>>
>
> No. It was experimental and had some rough edges that haven't been fully
> implemented.
>


And why don't keep it experimental too in 2.8 instead of removing it?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Kirill Prazdnikov]

Do you have performance measurements ? 
Did the performance better for 2.7 ?  
Did you measured real transfer traffic (web server supports real-time GZ 
compression over HTTP) ?

Thanks

On Thursday, November 24, 2016 at 3:46:49 PM UTC+3, Óscar Frías Barranco 
wrote:
>
> Hi.
>
> We are trying to move our website from GWT 2.7 to 2.8 but we have found 
> that GWT 2.8 generates code which is significantly heavier.
>
> For example, these are the sizes for one of the permutations:
> GWT 2.7 + Closure Compiler:  590 KB
> GWT 2.7 without Closure Compiler:  664 KB
> GWT 2.8 (no Closure Compiler available):  674 KB
>
> So the difference between 2.7 and 2.8 is +14% code size.
>
> We would like to keep our site up to date with the last version of GWT but 
> we don't like increasing our website code in this manner because it means 
> higher downloads, higher waiting times, worse user experience, etc.
>
> Do you plan to bring Closure Compiler (-XenableClosureCompiler option) 
> back to GWT? It was very useful for us.
>
> Kind regards,
> Oscar
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 generates code 14% bigger than GWT 2.7

[Jens]

> Do you plan to bring Closure Compiler (-XenableClosureCompiler option) 
> back to GWT? It was very useful for us.
>

No. It was experimental and had some rough edges that haven't been fully 
implemented.

You would need to execute it manually using the GWT output as input to 
Closure Compiler (and provide an extern file to protect special GWT 
variables). Alternatively try build your own GWT SDK and rollback the 
commit that removed closure compiler from GWT.

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT 2.8 generates code 14% bigger than GWT 2.7

[Óscar Frías Barranco]

Hi.

We are trying to move our website from GWT 2.7 to 2.8 but we have found 
that GWT 2.8 generates code which is significantly heavier.

For example, these are the sizes for one of the permutations:
GWT 2.7 + Closure Compiler:  590 KB
GWT 2.7 without Closure Compiler:  664 KB
GWT 2.8 (no Closure Compiler available):  674 KB

So the difference between 2.7 and 2.8 is +14% code size.

We would like to keep our site up to date with the last version of GWT but 
we don't like increasing our website code in this manner because it means 
higher downloads, higher waiting times, worse user experience, etc.

Do you plan to bring Closure Compiler (-XenableClosureCompiler option) back 
to GWT? It was very useful for us.

Kind regards,
Oscar

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.