Concern regarding GWT compiled html file size

[Vish Ramineni]

I have been planning to migrate a business application from C#/ASP.Net
to the Java world. After spending a lot of time looking at different
frameworks, I have decided upon GWT. I have put together a layout and
app framework, where I can quickly add pages and interact with JBoss
EJB. With only a fraction of the total work done, the file size is
already 311 KB. Should I be concerned about the size at all? Are there
any guidelines on how to keep the file size under check? At this
point, other than this concern, I'm pretty happy with GWT.

--Vish

[Dan Morrill]

Hi, Vish!

There are several inter-related to answers to your question.

• Browsers will usually compress the JavaScript files over the wire, so a 300KB JavaScript file should be around 60 - 70KB on the wire.  Also, the primary reason why GWT uses HTML files instead of pure JavaScript files is to avoid a corner case where browsers will skip the compression.  i.e. JavaScript code compresses very well, and GWT tries very hard to make sure it truly gets compressed.
• GWT splits up the generated JavaScript so that a given browser doesn't waste time downloading and parsing JavaScript code it doesn't need.  For example, Opera doesn't even download the Firefox-specific code in your application.
• The vast majority of your application's code is cacheable by the browser, meaning that it will take some time to download the first time, but browsers should be able to cache it thereafter.
  

What these points come down to is that while GWT apps can easily get into the 300KB+ range, GWT tries very hard indeed to keep file sizes small.  We frequently compare the output of GWT to the output of hand-written equivalents, and GWT almost always wins.  In cases where it doesn't win, we examine why and try to improve the compiler.

Additionally, in the upcoming 1.4 version, we have several compiler enhancements that will do some incremental improvements to reduce output file size even more.

Essentially: JavaScript as an application platform tends to have large-ish file sizes, and GWT is no exception.  However, GWT is at least as good as any other framework you'll find.


As for tips to minimize your application size, the key thing is just not to turn off JavaScript obfuscation for deployment, and be sure you're judging your download size correctly.  (The total download for a single browser is gwt.js + nocache.html file + a single .cache.html file.  Add up those file sizes to see how much a single browser will download.)  If you truly want to benchmark this, consider installing Firebug which gives you great insight into what your JavaScript code is doing.

I realize this is not a simple topic to get your head around, but I hope that helps!

- Dan Morrill

[Reinier Zwitserloot]

Vish, short answer: Don't worry about it at all.

longer answer: ONLY trust firebug's reports on how much is downloaded;
don't just tally the sizes of all files and call it a day. A lot of
those files are never downloaded at all; there are 4 variants of the
main codebase, one for each browser target, and in any situation, only
one (or zero if caching) of those are sent over the wire.

Also, "Hello World" has a minimum size, but from there the code
doesn't grow by much. So 311kb is not nearly as much as you might
think.

[Vish Ramineni]

Hi Dan & Reinier,

Thank you for your response. 311K I mentioned was for a single
cache.html. Obfuscation is on, I cannot make out anything from the
output file. I'll take your word for it and wil not worry about the
file size now.

--Vish

[Andrés Testi]

I have a question about inline code replacements in GWT: Inlining is
performed only with "final" methods, or it's also performed with
"virtual" methods?
Thank You.

[Reinier Zwitserloot]

Because you can't graft on more code without recompiling the whole go,
'final' should have absolutely no effect whatsoever on inlining.

I think atm no inlining is going on at all, but I read about some low
hanging fruit optimizations including that one in the upcoming 1.4
release.