Hey Anthony, 2008/11/12 Anthony Roger Buck <[EMAIL PROTECTED]>: > Is there any major reason why the bootstrap js is in the html file > (both skeleton and generated) and not in an external .js file? The > reason i ask is that i feel it would be rather nice to reduce the size > of the files sent to non-js users as they have no need for the js. By > externalizing the js file they won't download that additional code. In > addition as js users will need the wt.js code anyway would it not make > sense to simply append the bootstrap code to the main wt.js code and > include that as a js-include in the main html page?
Are you referring to the less than 100 lines of JavaScript code in Boot.html ? Since Boot.html is served blindly (it doesn't know yet whether the client will have JavaScript/AJAX support), the JavaScript code there has to bootstrap the AJAX-version of your application (and does not really do anything other than that). The big chunk of JavaScript is in Wt.js, which is only served to clients that support JavaScript and AJAX. So what is then the current situation in terms of code served ? A non-JavaScript client will get a Boot.html file and (using the current non-hybrid procedure), gets forwarded to a plain html file. In that case, there were only 100 lines of unnecessary JavaScript code. A JavaScript/AJAX client will get the same Boot.html file, and then load a single JavaScript file which renders the interface. In that case, there is also a minimum of requests ? > As a separate thought, have the team considered using a js > minimizer for compressing the static js files served? i.e. > http://shrinksafe.dojotoolkit.org/, http://dean.edwards.name/packer/, > http://www.crockford.com/javascript/jsmin.html We did. In fact, this is one of the reasons why the variables that we substitute in the skeletons have changed to _$_VARNAME_$_ instead of ${VARNAME} since the former is actually a valid JavaScript variable name, and thus these skeletons are syntactically correct. And I have been able to use the YUI compressor on it without a problem. > I know that it sounds like a waste of time (what's 30k between > friends?) but for the effort required and the potential improvement for > people on slow networks it's surely more a question of why not? I have played with a number of options (there is a web site where you can submit a chunk of JavaScript code and get compression rates for various compressors and options). The truth is: gzip is quite good, and the extra benefit of additional compression is marginal (< 20% if I recall correctly) compared to gzip only (which is on by default when using the built-in httpd, and you can easily configure any web server to do that when deploying using FastCGI). The main draw-back of such a minifier is that it would be an additional dependency in the Wt build process (for example to use YUI compressor we would then require a java runtime). I would prefer to remove special purpose functionality from Wt.js (such as the drag/drop support) and make that to be loaded on-demand should it become a problem ? Or even have a system with dependencies to load all of the general purpose functions on-demand ? Regards, koen ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
