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).
Towards a More Modular Future for JavaScript Libraries
21–30 of 49 posts
Re: Towards a More Modular Future for JavaScript Libraries
#22Please 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).
WUT
Re: Towards a More Modular Future for JavaScript Libraries
#23Earlier quoted context omitted.
What about closures and first class functions? Or easy interop (JSON), object and array literals? JavaScript has more going for it than platform ubiquity.
While it certainly has good points besides platform ubiquity, if you were trying to derive an equivalent of big-O for the popularity of javascript, language level criticisms and acclamations would count as, at best, linear concerns, where platform ubiquity is an exponential concern. Platform ubiquity is so completely important in the determination that all other concerns can be ignored entirely. Given a choice of sup…
All the cool programmers use CoffeeFuck.
Re: Towards a More Modular Future for JavaScript Libraries
#24We 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.
Re: Towards a More Modular Future for JavaScript Libraries
#25Please 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).
"it overwrites how require is actually supposed to be used"
According to whom? RequireJS is an implementation of the AMD spec.
Re: Towards a More Modular Future for JavaScript Libraries
#26I've written about JS modules in the past.
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.
Re: Towards a More Modular Future for JavaScript Libraries
#27why 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?
Re: Towards a More Modular Future for JavaScript Libraries
#28Both 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.
This
https://github.com/lodash/lodash/blob/master/lodash.js
is hardly the ~200 LOC module being described.
Re: Towards a More Modular Future for JavaScript Libraries
#29Highly, 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.
[1]: https://github.com/segmentio [2]: https://github.com/ianstormtaylor?tab=repositories
Re: Towards a More Modular Future for JavaScript Libraries
#30I've written about JS modules in the past. 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…
> The JS world is split in 2 right now
What about Meteor?