Hi, Reminder: since we will start using more and more require.js, we need a solution for optimizing [1] the requireJS javascript code because otherwise we will end up with way too many HTTP requests for each individual requireJS module.
Thanks, Eduard ---------- [1] http://requirejs.org/docs/optimization.html On Sun, Aug 2, 2015 at 1:55 PM, [email protected] <[email protected]> wrote: > Hi Thomas, > > On 2 Aug 2015 at 12:15:37, Thomas Mortagne ([email protected] > (mailto:[email protected])) wrote: > > > On Sat, Aug 1, 2015 at 11:08 PM, [email protected] wrote: > > > Hi devs, > > > > > > I’d like to propose the following official future organization for our > javascript/CSS code. > > [snip] > > > > WDYT? > > > > I agree this looks better from runtime/extension point of view. > > However it will make working on these resources a lot more painful > > (right now you modify it and just refresh). > > That’s a good point. BTW I have a similar problem today: for example we > provide two versions of xwiki.js, one xwiki-min.js and one xwiki.js. > However both versions are minified. We should provide a non minified one > for when we pass minify=false in the query string. > > We could do something like: > * Bundle 2 versions in the JAR: a minified one and a non-minified one. > * At runtime, somehow group all js files located in all webjars into a > single minified js file (yuicompressor). We’re doing this for JSX so we > should be able to implement this for webjars too. Something like a JVM JIT > for JS files. > * When the WebJarsResourceReferenceHandler is used to access a webjar > resource, if minify=false is specified in the URL, copy the non-minified > resource somewhere on the filesystem (probably in the data dir for now) and > return it. If the resource already exists on the FS, serve it from there > and don’t extract it from the JAR. This would allow devs to make changes to > that version and see the result, and also to debug easily JS in the browser. > > [snip] > > Thanks > -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
