The yui library has an interesting concept of cleint-side modules. They were able to consolidate a lot of their widget code during the rewrite of yui2 to yui3.
I'm also excited to see what the Meteor team comes up with for their v1.0 release. They already have reusable packages for the client and server but currently it's only designed for those using the core meteor framework. Would be interesting to see if what they make could be usable by other clients.
I'm on the YUI team - we'll be doing a lot more work in the module space coming up in the future. We have a few goals coming up - mainly to make each YUI component interoperable with different module systems, so that developers can use each individual YUI module whether they're using AMD, CommonJS, just plain YUI modules, or even ES6 modules.
Our goal is to play better with other libraries, so that we don't have the idea of a "walled garden", and that people can use whatever other libraries they want together with YUI, which has been a bit more difficult in the past.
Eric Ferraiuolo gave a good talk on this last week at YUIConf. Unfortunately, the full videos for the talks aren't out yet, but his slides are right here:
Keep posted - we definitely think that smaller, more reusable modules are the better way to go for front-end development in the future, and we'll have some interesting projects soon that anyone - even if you're not using YUI - can use.
Good writeup, thanks. As someone recently shifting focus from backend to frontend this was a good overview of the state of things.
If you're hankering for future blog articles, I'd love to see your take on the tradeoffs b/t using require.js vs Browserify. Or more generally a followup article on your whole FUD section would be useful.
While I think OP's link is quite informative, I think it suffers from the same oversight as most others on this topic has - confusing JS modules with Web components.
The JS world is split in 2 right now - client and server - for good reason because they are 2 very different domains with very different requirements. While a node package will work just fine by itself on the server, reusable code written for the browser usually doesn't work on its own. Some will require the window/document/location/whatever host object to be present, while others, mostly UI components, have to rely on other things like CSS and some minimal markup to work. Guess what? Most reusable browser code is NOT a JS module, they are Web components. As such, no pure JS solution with solve the dependency management problem on the browser. A proper solution must be able to package up different kinds of resources that constitute a whole Web component nicely for consumption. Having the One True Way to manage JS dependency is just a small part of it, in which any solution will do (tho I agree with the article OP linked to suggests, CommonJS style is the more tasteful choice for now before ES6 lands).
As far as I know, Browserify, Ender and Bower fail at the above totally, utterly, completely. Only Component and Volo seem to be on the right track as the moment I think.
Highly, highly, highly recommend Component. We've been using it for everything we do at Segment.io for the past year and it's completely changed the way we think about and write Javascript in the best way possible. (Need to write a few more blog posts about this soon since it's never explained well in these comparison articles.)
It treats CSS and HTML as first-class filetypes right alongside Javascript so you aren't stuck inlining CSS or templates as strings which becomes incredibly unmanageable quickly. It's build step is modular too so if you really want to do custom things you can do them very easily. It's got it own's registry so you don't have to wade through junky npm modules figuring out what's supported in the browser and what isn't. It's written by TJ, so you know the API is extremely clean. It's based on GitHub's structure, so forking and tweaking is literally a one-line change instead of having to re-publish and maintain your own fork. There are so many benefits I'm forgetting too.
More than that though, I guarantee if you start using Component for a couple months you will emerge a 5x better Javascript programmer. All of the existing components are very high quality, and their source is always very small, making them trivial to read through. It actually blows my mind now to think about the kind of code we were writing pre-component and how much it has changed. We probably open-source like 5-10 new components a week nowadays, I think we have something like over 200 components between the org account and all of us combined [1][2].
Disclaimer: I seriously love component, and really just want more people to discover how awesome it is.
Um I took a look at some of the repositories. What is the point of this? onEscape? onLoad? Really? An entire "component" just to add a handler for the ESC key? WHY
I completely agree and recommend component for all the reasons Ian mentions. It is shocking how little-known it is in javascript land. Don't be put off by lack of documentation and examples, it is seriously awesome. In fact I can't imagine doing client-side dev without it.
Just curious, have you guys given bower a chance, and if so why did you guys end up going with component. Component seems to be slightly more opinionated, less adopted, but really nice.
I've had success with npm and browserify. There are still script tag dependencies I haven't gotten around to cleaning up, but the whole system is working well.
I'm absolutely in love with the npm system though. It's so simple, easy to use, and powerful. It's absolutely a killer reason to use node.js in general. I've never use a framework where installing a project was as easy as `npm install`.
Also, in the non-perl world, i see a lot of web frameworks that likes to provide an all in one solution. That leads the developers and applications to tie themselves onto those frameworks(which is bad). ie: someone using webframeworkX that provides ormY builds all his site using that stack... and that is not good, because to use the ormY they will need the webframeworkX.
That sucks. because if i need to use cron for that app, i will need to load the webframework because the app is tied onto it... bah.
The best solution is to have ormY separated from the webframeworkX. So you can build your app with ormY, and use any webframeworkX Y or Z (only on the web facing part of your app). And no need to use orm at all (from the framework)
Both awesome libraries, but I think including lodash and jquery in the list of small modules is a bit of a joke. Both are big old fashioned utility belts.
Please don't use Require.js, it overwrites how require is actually suppose to be used. Try using something that doesn't break instead, like HTTP://github.com/amark/theory (disclosure: this is my library, you should check out my tech talks).
Yeah, it's available in the browser. I'm not even trying to slam JavaScript--I sort of like it for all of its foot-guns, but this is literally the only reason worth considering for its success.
Edit: I like several things about JS. Certainly if it didn't have first class functions, or easy object literals, that would be a pain. Likewise, if it didn't have insane implicit conversions and painful APIs, that would be great. But the good features didn't make JavaScript successful, just like the terrible features didn't kill it.
And Node was a function of JavaScript's ubiquity, not a cause. Having a server side platform will help keep momentum behind the language, but it really happened because JavaScript was already so big.
We already have CommonJS. It rocks. Use it. Whether your code runs in node or the browser is exactly what the "engines" property of the "package.json" file is for.
why not add a real module and dependency system to js at the language/runtime level? Considering how important JavaScript has become, isn't it completely amazing that this discussion is even happening now?
[+] [-] alanning|12 years ago|reply
I'm also excited to see what the Meteor team comes up with for their v1.0 release. They already have reusable packages for the client and server but currently it's only designed for those using the core meteor framework. Would be interesting to see if what they make could be usable by other clients.
1. http://yuilibrary.com 2. http://meteor.com
[+] [-] clarle|12 years ago|reply
Our goal is to play better with other libraries, so that we don't have the idea of a "walled garden", and that people can use whatever other libraries they want together with YUI, which has been a bit more difficult in the past.
Eric Ferraiuolo gave a good talk on this last week at YUIConf. Unfortunately, the full videos for the talks aren't out yet, but his slides are right here:
https://speakerdeck.com/ericf/yui-and-the-future
Keep posted - we definitely think that smaller, more reusable modules are the better way to go for front-end development in the future, and we'll have some interesting projects soon that anyone - even if you're not using YUI - can use.
[+] [-] SkyMarshal|12 years ago|reply
If you're hankering for future blog articles, I'd love to see your take on the tradeoffs b/t using require.js vs Browserify. Or more generally a followup article on your whole FUD section would be useful.
PS - amusing typo, it's CPAN, not CSPAN :)
[+] [-] bwindels|12 years ago|reply
[+] [-] wyuenho|12 years ago|reply
https://medium.com/what-i-learned-building/5a31feb15e2
While I think OP's link is quite informative, I think it suffers from the same oversight as most others on this topic has - confusing JS modules with Web components.
The JS world is split in 2 right now - client and server - for good reason because they are 2 very different domains with very different requirements. While a node package will work just fine by itself on the server, reusable code written for the browser usually doesn't work on its own. Some will require the window/document/location/whatever host object to be present, while others, mostly UI components, have to rely on other things like CSS and some minimal markup to work. Guess what? Most reusable browser code is NOT a JS module, they are Web components. As such, no pure JS solution with solve the dependency management problem on the browser. A proper solution must be able to package up different kinds of resources that constitute a whole Web component nicely for consumption. Having the One True Way to manage JS dependency is just a small part of it, in which any solution will do (tho I agree with the article OP linked to suggests, CommonJS style is the more tasteful choice for now before ES6 lands).
As far as I know, Browserify, Ender and Bower fail at the above totally, utterly, completely. Only Component and Volo seem to be on the right track as the moment I think.
[+] [-] Bockit|12 years ago|reply
[1]: E.g., https://npmjs.org/package/browserify-jade
[2]: E.g., https://npmjs.org/package/stylify
[+] [-] fragmede|12 years ago|reply
What about Meteor?
[+] [-] ianstormtaylor|12 years ago|reply
It treats CSS and HTML as first-class filetypes right alongside Javascript so you aren't stuck inlining CSS or templates as strings which becomes incredibly unmanageable quickly. It's build step is modular too so if you really want to do custom things you can do them very easily. It's got it own's registry so you don't have to wade through junky npm modules figuring out what's supported in the browser and what isn't. It's written by TJ, so you know the API is extremely clean. It's based on GitHub's structure, so forking and tweaking is literally a one-line change instead of having to re-publish and maintain your own fork. There are so many benefits I'm forgetting too.
More than that though, I guarantee if you start using Component for a couple months you will emerge a 5x better Javascript programmer. All of the existing components are very high quality, and their source is always very small, making them trivial to read through. It actually blows my mind now to think about the kind of code we were writing pre-component and how much it has changed. We probably open-source like 5-10 new components a week nowadays, I think we have something like over 200 components between the org account and all of us combined [1][2].
Disclaimer: I seriously love component, and really just want more people to discover how awesome it is.
[1]: https://github.com/segmentio [2]: https://github.com/ianstormtaylor?tab=repositories
[+] [-] EGreg|12 years ago|reply
[+] [-] ericgj|12 years ago|reply
[+] [-] paultannenbaum|12 years ago|reply
[+] [-] etler|12 years ago|reply
I'm absolutely in love with the npm system though. It's so simple, easy to use, and powerful. It's absolutely a killer reason to use node.js in general. I've never use a framework where installing a project was as easy as `npm install`.
[+] [-] hernan604|12 years ago|reply
You can download the JSAN Server, and upload modules. And it takes cares of dependencies.
Check it out, and if you like, contribute there and dont reinvent the wheel.
I too belive we need a more modular javascript.
Plus, you can use JOOSE-js to create modular modules. I recommend JOOSE-js. Its great and works in all browsers, also with node (backend) and frontend
[+] [-] hernan604|12 years ago|reply
That sucks. because if i need to use cron for that app, i will need to load the webframework because the app is tied onto it... bah.
The best solution is to have ormY separated from the webframeworkX. So you can build your app with ormY, and use any webframeworkX Y or Z (only on the web facing part of your app). And no need to use orm at all (from the framework)
[+] [-] _mayo|12 years ago|reply
[+] [-] hackula1|12 years ago|reply
This
https://github.com/lodash/lodash/blob/master/lodash.js
is hardly the ~200 LOC module being described.
[+] [-] jdd|12 years ago|reply
FWIW you're linking to the pre-build dev source.
Lo-Dash is available as modules for AMD, ES6, CommonJS, Node.js, and npm packages per method.
https://npmjs.org/package/lodash-amd
https://github.com/lodash/lodash-es6
https://npmjs.org/package/lodash-node
https://npmjs.org/browse/keyword/lodash-modularized
Also, jQuery is using AMD internally and allows custom builds.
There is even a project to convert it to something more easily consumed by browserify:
https://github.com/kirbysayshi/node-ddd-jquery#rationale
[+] [-] marknadal|12 years ago|reply
[+] [-] ben336|12 years ago|reply
According to whom? RequireJS is an implementation of the AMD spec.
[+] [-] JohnDotAwesome|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] jsmcgd|12 years ago|reply
For all of JS quirks it is clearly getting something(s) very right.
[+] [-] hyperpape|12 years ago|reply
Edit: I like several things about JS. Certainly if it didn't have first class functions, or easy object literals, that would be a pain. Likewise, if it didn't have insane implicit conversions and painful APIs, that would be great. But the good features didn't make JavaScript successful, just like the terrible features didn't kill it.
And Node was a function of JavaScript's ubiquity, not a cause. Having a server side platform will help keep momentum behind the language, but it really happened because JavaScript was already so big.
[+] [-] pekk|12 years ago|reply
[+] [-] dreamdu5t|12 years ago|reply
[+] [-] IlPeach|12 years ago|reply
[+] [-] fiatjaf|12 years ago|reply
[+] [-] alkonaut|12 years ago|reply
[+] [-] camus2|12 years ago|reply
[+] [-] shire|12 years ago|reply
[+] [-] puppetmaster3|12 years ago|reply
[+] [-] remotesynth|12 years ago|reply
[+] [-] dictum|12 years ago|reply