Re: iframe JS code linker
Hi! Thanks for the answer! I didn't even mention the sandbox environment as that seemed quite obvious at the first sight. But I was kind of thinking to read about some JS codebase size related advantages that could be implied... The caching issues are definitely interesting, but that's not a reason for a separate JS code iframe on its own. Best Regards Standa On Jul 21, 4:13 pm, Thomas Broyer t.bro...@gmail.com wrote: On 20 juil, 17:06, opichals opich...@gmail.com wrote: Hi! Commonly JS frameworks' .js files are simply added to the .html file as script tags. GWT linker by default creates aniframethat contains all the JS code script tags inside kept separate from the rest of the application page markup. I have been searching for the reason that led to having that separateiframefor the generated JavaScript application code and found no answer for on the web. I can imagine it is useful for modularization reasons... basically to simplify the application linker and HTML generation process. I fail to see any other reason for this. Is it just the linker reason or is there some other e.g. performance benefit or something that would be further motivation to have the JS code in a separateiframe? There are two reasons IIRC: -iframegives you a sandbox for free, so you don't mess with other scripts in the web page *and* they don't mess with your script (note that the XS linker uses the module pattern, so it shouldn't a problem either, except maybe when you also use runAsync) - some browsers (particularly those coming from Redmond) won't cache gzipped *.js files coming from SSL/TLS, but will cache *.html (this is from memory, it might be unrelated to gzipping or to SSL/TLS, but it's at least one of those) -- 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.
Re: iframe JS code linker
On 20 juil, 17:06, opichals opich...@gmail.com wrote: Hi! Commonly JS frameworks' .js files are simply added to the .html file as script tags. GWT linker by default creates an iframe that contains all the JS code script tags inside kept separate from the rest of the application page markup. I have been searching for the reason that led to having that separate iframe for the generated JavaScript application code and found no answer for on the web. I can imagine it is useful for modularization reasons... basically to simplify the application linker and HTML generation process. I fail to see any other reason for this. Is it just the linker reason or is there some other e.g. performance benefit or something that would be further motivation to have the JS code in a separate iframe? There are two reasons IIRC: - iframe gives you a sandbox for free, so you don't mess with other scripts in the web page *and* they don't mess with your script (note that the XS linker uses the module pattern, so it shouldn't a problem either, except maybe when you also use runAsync) - some browsers (particularly those coming from Redmond) won't cache gzipped *.js files coming from SSL/TLS, but will cache *.html (this is from memory, it might be unrelated to gzipping or to SSL/TLS, but it's at least one of those) -- 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.
iframe JS code linker
Hi! Commonly JS frameworks' .js files are simply added to the .html file as script tags. GWT linker by default creates an iframe that contains all the JS code script tags inside kept separate from the rest of the application page markup. I have been searching for the reason that led to having that separate iframe for the generated JavaScript application code and found no answer for on the web. I can imagine it is useful for modularization reasons... basically to simplify the application linker and HTML generation process. I fail to see any other reason for this. Is it just the linker reason or is there some other e.g. performance benefit or something that would be further motivation to have the JS code in a separate iframe? Thanks! Standa -- 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.
