[xwiki-devs] [PROPOSAL] Include require.js in XWiki by default and make jQuery available through require.js.
Hi, I'd like to add require.js to XWiki to be included in every page just before prototype.js. I would also like to add jQuery to our resources directory but only make it available to scripts which "pull it in" using require(). I have come to the conclusion that jQuery is a de-facto standard and even if we don't port to it, we should make it available to our users. Require.js is an implementation of the Asynchronous Module Definition standard which will allow us to use both jQuery and prototype relatively harmoniously. I think it's obvious that if javascript rich webapps are going to scale, they need modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD will provide the user with better page load time by asynchronously loading modules according to a dependency tree while CommonJS blocks on each call to require(). I would like to see us move away from prototype but it provides more functionality than jQuery including an OOP framework and while there are other libraries which show promise, I don't feel right proposing a best practice without first porting some code to it to see what issues arise so IMO we should begin using require.js but accept that prototype still has it's place. So I propose: Include require in the header vm. Include jQuery but only if a script "require()'s" it. Establish a best practice of using require() and define() instead of global variables but accept that prototype.js still has it's place. WDYT? Caleb miscellany: ------------------------------ require.js vital statistics: Dual licensed BSD and MIT. Latest Release: 2.1.2 1,993 lines before minification 24,621 lines in every .js file in the /tests/ directory. Used by: https://github.com/adobe/brackets/ https://github.com/ajaxorg/cloud9 (https://c9.io/) http://browserquest.mozilla.org/ http://www.bbc.co.uk/frameworks/barlesque/examples/global/requirejs http://www.officejs.org/ ----------------------------- Optimization: require.js comes with a tool for linting, compiling (using Closure Compiler), and linking AMD modules together based on their dependencies. Complex projects with many js files can be can be compiled into a single "statically linked" js file. It supports Rhino so it could be included in the maven build. ----------------------------- My experimentation with require.js: I use the require.js legacy shim to make jquery.sheet function as a require.js module without making any direct changes to jquery.sheet. I was able to move the code from XWiki to the filesystem (file:///) a total change of the directory structure and only needed to change the main example.html file. I was able to include the content in an iframe simply by defining a require.js plugin see: http://requirejs.org/docs/plugins.html for loading through an iframe and changing the require() call to require the iframe'd sheet. https://github.com/cjdelisle/jquery-sheet-amd
On 11/30/2012 01:41 PM, Caleb James DeLisle wrote:
Hi,
I'd like to add require.js to XWiki to be included in every page just before prototype.js. I would also like to add jQuery to our resources directory but only make it available to scripts which "pull it in" using require().
I have come to the conclusion that jQuery is a de-facto standard and even if we don't port to it, we should make it available to our users. Require.js is an implementation of the Asynchronous Module Definition standard which will allow us to use both jQuery and prototype relatively harmoniously.
I think it's obvious that if javascript rich webapps are going to scale, they need modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD will provide the user with better page load time by asynchronously loading modules according to a dependency tree while CommonJS blocks on each call to require().
I would like to see us move away from prototype but it provides more functionality than jQuery including an OOP framework and while there are other libraries which show promise, I don't feel right proposing a best practice without first porting some code to it to see what issues arise so IMO we should begin using require.js but accept that prototype still has it's place.
So I propose:
Include require in the header vm.
+1
Include jQuery but only if a script "require()'s" it.
+1
Establish a best practice of using require() and define() instead of global variables but accept that prototype.js still has it's place.
+1 However, consider these as precursory +1s for the idea in general. We should first try and see how this work in real code.
WDYT?
Caleb
miscellany: ------------------------------
require.js vital statistics:
Dual licensed BSD and MIT. Latest Release: 2.1.2 1,993 lines before minification 24,621 lines in every .js file in the /tests/ directory. Used by: https://github.com/adobe/brackets/ https://github.com/ajaxorg/cloud9 (https://c9.io/) http://browserquest.mozilla.org/ http://www.bbc.co.uk/frameworks/barlesque/examples/global/requirejs http://www.officejs.org/
-----------------------------
Optimization:
require.js comes with a tool for linting, compiling (using Closure Compiler), and linking AMD modules together based on their dependencies. Complex projects with many js files can be can be compiled into a single "statically linked" js file.
It supports Rhino so it could be included in the maven build.
-----------------------------
My experimentation with require.js:
I use the require.js legacy shim to make jquery.sheet function as a require.js module without making any direct changes to jquery.sheet.
I was able to move the code from XWiki to the filesystem (file:///) a total change of the directory structure and only needed to change the main example.html file.
I was able to include the content in an iframe simply by defining a require.js plugin see: http://requirejs.org/docs/plugins.html for loading through an iframe and changing the require() call to require the iframe'd sheet.
-- Sergiu Dumitriu http://purl.org/net/sergiu
+1 as well. Thanks, Marius On Fri, Nov 30, 2012 at 9:55 PM, Sergiu Dumitriu <[email protected]> wrote:
On 11/30/2012 01:41 PM, Caleb James DeLisle wrote:
Hi,
I'd like to add require.js to XWiki to be included in every page just before prototype.js. I would also like to add jQuery to our resources directory but only make it available to scripts which "pull it in" using require().
I have come to the conclusion that jQuery is a de-facto standard and even if we don't port to it, we should make it available to our users. Require.js is an implementation of the Asynchronous Module Definition standard which will allow us to use both jQuery and prototype relatively harmoniously.
I think it's obvious that if javascript rich webapps are going to scale, they need modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD will provide the user with better page load time by asynchronously loading modules according to a dependency tree while CommonJS blocks on each call to require().
I would like to see us move away from prototype but it provides more functionality than jQuery including an OOP framework and while there are other libraries which show promise, I don't feel right proposing a best practice without first porting some code to it to see what issues arise so IMO we should begin using require.js but accept that prototype still has it's place.
So I propose:
Include require in the header vm.
+1
Include jQuery but only if a script "require()'s" it.
+1
Establish a best practice of using require() and define() instead of global variables but accept that prototype.js still has it's place.
+1
However, consider these as precursory +1s for the idea in general. We should first try and see how this work in real code.
WDYT?
Caleb
miscellany: ------------------------------
require.js vital statistics:
Dual licensed BSD and MIT. Latest Release: 2.1.2 1,993 lines before minification 24,621 lines in every .js file in the /tests/ directory. Used by: https://github.com/adobe/brackets/ https://github.com/ajaxorg/cloud9 (https://c9.io/) http://browserquest.mozilla.org/ http://www.bbc.co.uk/frameworks/barlesque/examples/global/requirejs http://www.officejs.org/
-----------------------------
Optimization:
require.js comes with a tool for linting, compiling (using Closure Compiler), and linking AMD modules together based on their dependencies. Complex projects with many js files can be can be compiled into a single "statically linked" js file.
It supports Rhino so it could be included in the maven build.
-----------------------------
My experimentation with require.js:
I use the require.js legacy shim to make jquery.sheet function as a require.js module without making any direct changes to jquery.sheet.
I was able to move the code from XWiki to the filesystem (file:///) a total change of the directory structure and only needed to change the main example.html file.
I was able to include the content in an iframe simply by defining a require.js plugin see: http://requirejs.org/docs/plugins.html for loading through an iframe and changing the require() call to require the iframe'd sheet.
-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Dec 3, 2012, at 10:30 AM, Marius Dumitru Florea <[email protected]> wrote:
+1 as well.
Thanks, Marius
On Fri, Nov 30, 2012 at 9:55 PM, Sergiu Dumitriu <[email protected]> wrote:
On 11/30/2012 01:41 PM, Caleb James DeLisle wrote:
Hi,
I'd like to add require.js to XWiki to be included in every page just before prototype.js.
+1
I would also like to add jQuery to our resources directory but only make it available to scripts which "pull it in" using require().
+1 I'd personally even go further (this requires a new email thread) and propose to deprecate the prototype technology and to move slowly to jquery instead. jquery has won. period. See JV's email in this thread about this too.
I have come to the conclusion that jQuery is a de-facto standard and even if we don't port to it, we should make it available to our users.
+1
Require.js is an implementation of the Asynchronous Module Definition standard which will allow us to use both jQuery and prototype relatively harmoniously.
I think it's obvious that if javascript rich webapps are going to scale, they need modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD will provide the user with better page load time by asynchronously loading modules according to a dependency tree while CommonJS blocks on each call to require().
I would like to see us move away from prototype but it provides more functionality than jQuery including an OOP framework and while there are other libraries which show promise, I don't feel right proposing a best practice without first porting some code to it to see what issues arise so IMO we should begin using require.js but accept that prototype still has it's place.
Sounds good.
So I propose:
Include require in the header vm.
+1
Include jQuery but only if a script "require()'s" it.
+1
Establish a best practice of using require() and define() instead of global variables but accept that prototype.js still has it's place.
+1
+1 to all those. 5.0 (more generally 5.x) sounds a good time to do all this. Thanks -Vincent
However, consider these as precursory +1s for the idea in general. We should first try and see how this work in real code.
WDYT?
Caleb
miscellany: ------------------------------
require.js vital statistics:
Dual licensed BSD and MIT. Latest Release: 2.1.2 1,993 lines before minification 24,621 lines in every .js file in the /tests/ directory. Used by: https://github.com/adobe/brackets/ https://github.com/ajaxorg/cloud9 (https://c9.io/) http://browserquest.mozilla.org/ http://www.bbc.co.uk/frameworks/barlesque/examples/global/requirejs http://www.officejs.org/
-----------------------------
Optimization:
require.js comes with a tool for linting, compiling (using Closure Compiler), and linking AMD modules together based on their dependencies. Complex projects with many js files can be can be compiled into a single "statically linked" js file.
It supports Rhino so it could be included in the maven build.
-----------------------------
My experimentation with require.js:
I use the require.js legacy shim to make jquery.sheet function as a require.js module without making any direct changes to jquery.sheet.
I was able to move the code from XWiki to the filesystem (file:///) a total change of the directory structure and only needed to change the main example.html file.
I was able to include the content in an iframe simply by defining a require.js plugin see: http://requirejs.org/docs/plugins.html for loading through an iframe and changing the require() call to require the iframe'd sheet.
On Fri, Nov 30, 2012 at 7:41 PM, Caleb James DeLisle <[email protected]> wrote:
Hi,
I'd like to add require.js to XWiki to be included in every page just before prototype.js. I would also like to add jQuery to our resources directory but only make it available to scripts which "pull it in" using require().
I have come to the conclusion that jQuery is a de-facto standard and even if we don't port to it, we should make it available to our users. Require.js is an implementation of the Asynchronous Module Definition standard which will allow us to use both jQuery and prototype relatively harmoniously.
I think it's obvious that if javascript rich webapps are going to scale, they need modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD will provide the user with better page load time by asynchronously loading modules according to a dependency tree while CommonJS blocks on each call to require().
I would like to see us move away from prototype but it provides more functionality than jQuery including an OOP framework and while there are other libraries which show promise, I don't feel right proposing a best practice without first porting some code to it to see what issues arise so IMO we should begin using require.js but accept that prototype still has it's place.
About moving away from prototype, I stumbled upon a recent article on its founder's blog: http://sstephenson.us/posts/you-are-not-your-code JV.
participants (5)
-
Caleb James DeLisle -
Jean-Vincent Drean -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol