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.
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.
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 :)
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.
: E.g., https://npmjs.org/package/browserify-jade
: E.g., https://npmjs.org/package/stylify
What about Meteor?
Disclaimer: I seriously love component, and really just want more people to discover how awesome it is.
Yes the "on-escape" component just attaches an escape handler to the document. One of the reasons for it is just to not have to write that code yet another time, since doing that is boring and, more importantly, prone to bugs.
But the other reason is that it turns this:
document.attachEventListener('escape', fn, false);
It's also more performant than attaching tons of different escape handlers, because across all components everyone will share the same event listener. Even for components that somebody else wrote and you're just using.
So yes, there's a component just for onEscape.
There are some components that bundle several components together, e.g. component/dom or component/enumerable. And there are certainly more general components for key handlers. But if you need just one piece of it, you don't have to install the whole bundle. And if you use it just once or a few times or in limited contexts, you're right, you can inline it and skip the dependency altogether. But the point is you have a choice depending on your needs.
2. component doesn't just manage 3rd party packages - it helps manage your internal code/styles/templates as well. see https://github.com/jonathanong/bigpipe-example/tree/master/c.... keeping CSS/JS/HTML for a component of your site in completely separate folders is a thing of the past.
3. it's less adopted because it doesn't have Twitter's marketing and man power. TJ also hasn't had the time to document or market it well. it's also much more difficult to teach (well).
4. i hate requirejs due to its unnecessary callback and defining modules through function arguments. if i weren't using component, i'd use browserify. i have not seen any non-requirejs implementations of a build step, and i'd rather have a single step than two.
5. it's easier to share code between node and the browser. with requirejs, it's a little harder, but it's easiest with browserify.
6. most bower packages are bloated and require other large dependencies like jQuery, and I can't filter through that. component modules, on the other hand, tend to be very small, lightweight, focused, and overall better quality. for example, https://github.com/yields/select is becoming pretty excellent, much better and less bloated than select2.
7. bower packages tend to come with excessive amounts of options (because people request them, ex. select2) and excessive boilerplate code (because people want it to look good right way, ex Font Awesome). component packages tend to be the opposite - minimal, structural styling and very few options.
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`.
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.
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
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)
is hardly the ~200 LOC module being described.
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.
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:
According to whom? RequireJS is an implementation of the AMD spec.
For all of JS quirks it is clearly getting something(s) very right.
Or easy interop (JSON), object and array literals?
Platform ubiquity is so completely important in the determination that all other concerns can be ignored entirely.