1 permutation to rule them all

[dmen]

GWT has a fundamental architecture flaw. It should not be necessary to
compile the whole code base more than exactly once. Deferred binding
is great for implementing algorithms dynamically. For I18N is
obviously wrong IMO. Thankfully that can be avoided. Ideally only a
thin DOM abstraction layer should be different for each browser,
physically separated and loaded from the bootstrap code. Deferred
binding at the widget level should not be have happened!

Just my thoughts.

[Stefano Ciccarelli]

I think you should read this:

https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsDeferred

2012/3/26 dmen <dmen...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Nel mondo esistono 10 categorie di persone, quelle che capiscono il binario e quelle che non lo capiscono.

[Joseph Lust]

Dmen,

It depends what you value. The GWT team values load time over all else, which makes sense given the hit volume their pages face. Simply put, they want to send each user a single permutation. The cost of storing 320 permutations on the server (i.e. 400MB) is far cheaper than packing all of that into a single permutation (i.e. 5MB vs 1MB) given the download and parse time for such a large JS wad. Even downloading a i18n file for each language to the UI is a poor idea given one more server hit and that the UI can't init unit it has words to show.

So that's the flavor of the GWT Kool-Aid.

If the build time is perturbing, just Google for distributed GWT permutation building. That's how Google teams get around that issue.

Sincerely,

Joseph