Concerns about the size of GWT complied code has been raised several times in this forum, but a typical response was "Relax, dude!" with slight variations like "It can be cached" and "Don't forget about gzip". I am still concerned, though, that even the most simple GWT app easily tops 150kB in compile size.
I started looking at the compile reports, and I noticed some interesting things. (1) I imported java.util.Comparator in one place in the app, and it immediately added a ton of Java classes to the compiled code, including Java.util.Date, java.lang.Float, java.lang.Double, and so on. I don't use this classes anywhere in the app, and the compile report traces them all to java.util.Comparator. I did not measure precisely, but I've got around a 10kB bump in the compiled app size after using comparator once (and I use it to compare String properties of two objects). (2) I don't use dates or time anywhere on the client side. I have one server-side method which uses dates by adding a timestamp to an Appengine Datastore. So I was very surprised to see java.sql.Timestamp, java.sql.Date, and java.sql.Time, in my compile report. These classes are not big, but why they were included? I don't send date or time over the wire (and I don't use sql), but I see them traced to com.google.gwt.user.client.rpc.core.java.sql.Time_CustomFieldSerializer::instantiate. (3) In my app many classes are traced exclusively to DockLayoutPanel, including java.util.AbstractHashMap, java.util.HashSet, and the like. Is there an assessment anywhere of how heavy each widget is in terms of its impact on the compile size? It's very hard to figure out as each widget has a different impact based on which other widgets are already present, and some widgets have no real alternative anyway (CellTable is very heavy, for example, but I have to use it regardless), but any tips/guidance would be appreciated. (4) I never used anything touch-related in the app, but com.google.gwt.touch.client is present in the compile report. All of its subclasses trace back to ScrollPanel. I guess it may be useful in some use cases, but I would like to have a way to turn it off when I offer a separate GWT file for mobile devices. (5) I replaced RPC calls with RequestFactory, and the compile size ballooned by 150kB (the app had only two RPC calls at that stage). The benefits of RequestFactory quickly paled in my eyes. Did I do something wrong, or other people had similar results? I understand that as the app gets bigger and bigger (and the Internet faster), these issues will be comparatively less and less important. I do have, however, customers with slower connections / in remote locations / on expensive mobile data plans, for whom initial download size matters. Not to mention extra bandwidth costs which grow in line with the number of customers (Isn't that the reason Gmail, YouTube, and Google+ are not written in GWT?). I would be grateful if the experts on this forum share their tips on reducing the compile size of the app. -- 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-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
