> > That's why, when writing a function in GWT, I expect it to compile out > to something that doesn't exceed the size of handwritten JS for the > same purposes.
Compiling Java to Javascript has some overheads which you cannot get rid off easily. These overheads are not much if you are building a web-application; but it could prove expensive if you are building a general purpose js library. *Overhead 1 : IFrame Bootstrap loader* As lineman78 suggests, you could use the built-in SingleScriptLinker, or you could write a custom linker (not too difficult). But this isn't the bulk of the overhead. *Overhead 2 : Java emulation in javascript* GWT has to emulate java.lang and java.util packages for you in javascript. Every class that you write will typically have the following four methods - getClass(), toString(), equals() and hashcode() in javascript - even if you don't actually invoke those methods. Besides, there are overheads with the collections emulation. You cannot write a linker to overcome this overhead. I believe GWT team is working on a simpler collections emulation, and that would reduce the overheads - but till then I am afraid you don't have an option. The only thing I can suggest is -*XdisableClassMetadata *flag to reduce some of the overheads. --Sri On 27 July 2010 22:02, lineman78 <linema...@gmail.com> wrote: > Once the GWT compile completes, it is up to the linker to decide how > to package it. The single script linker should behave how you would > like, but you will have to make sure that deferred binding is never > used in your code unless only one permutation is possible. The > default linker is an iframe linker, which is the bootloader you are > talking about. Google knew some people wouldn't like this and would > like to do exactly what you are saying, which is why they maintain the > SingleScriptLinker. If it doesn't behave exactly as you would like > you may have to pull the source down and modify it to fit your needs. > There needs to be exactly one primary linker, therefore there is no > disable bootloader compile option because a linker must be provided in > order for GWT to know how to distribute and load the code. > > > http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/core/linker/SingleScriptLinker.html > > On Jul 26, 4:54 pm, S Rabin <scottra...@gmail.com> wrote: > > I see. So when the only thing in my loadModule function is an export > > call, and I export the method (via Ray Cromwell's gwt-exporter > > library, which I was already using): > > > > public void HelloTest(String id){ > > DOM.getElementById(id).setInnerHTML("Hello World"); > > > > } > > > > it should compile to 25kb plus a bootloader? I'm not arguing that a > > bootloader is a bad idea for larger code, but I was really just hoping > > for a --disable bootloader compile option. > > > > To address your concern that there is 'no possible way for the code > > size to grow', and that the GWT compiler aggressively prunes dead > > code, yes, I'm fully aware that it is designed to do that. That's > > why, when writing a function in GWT, I expect it to compile out to > > something that doesn't exceed the size of handwritten JS for the same > > purposes. There are two options here: one, I'm missing some checkbox > > (and it's not the OBFuscated option), or two, GWT is including a lot > > more crap it thinks I need that I'm not aware of, hence why I'm asking > > how to fix it. > > > > As for whether I know better than Google when it comes to the > > bootloader... yes, in this case, I do. I anticipate this library to > > be approximately 10kb of handwritten javascript, and I'm not doing > > anything that should warrant more than 1 permutation beyond browser > > specific speed optimizations. Therefore, distributing the library as > > a .js file instead of a bootloader plus 4 different permutations seems > > like a better idea. > > > > Is my only option here really to write my own linker to output one .js > > file, no bootloader, no browser-specific optimizations? > > > > On Jul 26, 12:42 pm, lineman78 <linema...@gmail.com> wrote: > > > > > First, let me start by saying that people are already writing > > > javascript libraries using GWT and have been for some time. Ray > > > Cromwell created the GWT exporter library for this exact purpose for > > > his own usage and open sourced it. While bootloaders seem expensive > > > it is the only way to deliver the most efficient code to the client. > > > There is no possible way for code size to grow when compiled because > > > if you go far enough every method will eventually make it to a JSNI > > > method, so what you are missing in your calculations is all the code > > > supplied by google and the small overhead code involved with the > > > bootloader. However, there is a linker available to create only one > > > output, but in order for this to work the compilation must result in > > > only one permutation, which is almost impossible unless you know the > > > browser your client will be using. You asked: "Is there a way to crop > > > out all the unnecessary cruft GWT seems to think I need?". You can > > > write your own linker if you feel that you know better than google > > > when it comes to the bootloader, but as far as the compiled code > > > itself; the GWT compiler has very aggressive dead code elimination, so > > > any output code will be used at some point. > > > > > On Jul 26, 9:21 am, S Rabin <scottra...@gmail.com> wrote: > > > > > > I've done quite a bit of searching to find any information about > this, > > > > but it seems that people are more concerned with writing GWT > libraries > > > > to keep in GWT before compilation. > > > > > > I would like to write the libraries I frequently use in my projects > in > > > > GWT, then compile and expose them to hand-written Javascript. I have > > > > several issues with the way GWT seems to handle what I want to do: > > > > > > 1) Bootstrapping. I understand that the iframe loading method is > > > > highly efficient for large codebases so as to make the page non- > > > > blocking, but for a small library bootstrapping is overkill. To > test, > > > > I tried writing my TableGenerator library (a 7kb handwritten non- > > > > minified library) in GWT. The result was a 6 kb deferred binding > > > > loader file (table.nocache.js) and 4 permutations of compiled JS > > > > weighing in at 20-30kb each. Which brings me to issue #2 > > > > > > 2) For compiling the code, GWT seems to produce LARGER codebases. > > > > Fast, yes, but how does 3-5kb of source result in 20-30kb of compiled > > > > javascript? Is there a way to crop out all the unnecessary cruft GWT > > > > seems to think I need? > > > > > > 3) I would prefer to not have a bootloader - I anticipate the > compiled > > > > form of my code is going to be smaller than the bootstrap code and > > > > would rather it just be loaded. Is there a compilation option to > > > > disable permutations and output (obviously more to handle different > > > > implementations) code that works in all browsers? > > > > > > Sincerely, > > > > Scott Rabin > > -- > 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-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- 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-tool...@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.
