6 ms·

Towards a More Modular Future for JavaScript Libraries

101 points by remotesynth 13y ago

deleted 13y ago
[deleted]
_mayo 13y ago
Looks like the site's down, Here's a text only cached version: http://webcache.googleusercontent.com/search?q=cache:http://flippinawesome.org/2013/11/11/towards-a-more-modular-future-for-javascript-libraries/&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...
puppetmaster3 13y ago
Based on the site being down, I think the future is to use a CDN, yes? MaxCDN is $39/year.
- remotesynth 13y ago
  Site is back up. Sorry about the issues.
- dictum 13y ago
  $39/month.
bwindels 13y ago
Couldn't agree more with the article. I use browserify in all my new projects and love having the same module comfort as I do in node.
jsmcgd 13y ago
The graph of library growth is stunning: http://modulecounts.com/ http://modulecounts.com/ For all of JS quirks it is clearly getting something(s) very right.
- hyperpape 13y ago
  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.
  - thenmar 13y ago
    You don't think it has anything to do with Node?
    - SkyMarshal 13y ago
      Node only came about b/c Google wrote V8 for high-performance browser JS. Node has certainly expanded JS's reach in a big way, but wouldn't have existed in the first place if, say, Lua were the lingua franca of all web browsers (or maybe V8 and Node would still exist but target Lua instead).
  - davedx 13y ago
    What about closures and first class functions? Or easy interop (JSON), object and array literals? JavaScript has more going for it than platform ubiquity.
    - knome 13y ago
      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 supporting half of systems in javascript, and all systems in brainfuck, people would begin writing brainfuck-targeting compilers immediately.
alanning 13y ago
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. 1. http://yuilibrary.com http://yuilibrary.com 2. http://meteor.com http://meteor.com
- clarle 13y ago
  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: https://speakerdeck.com/ericf/yui-and-the-future 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.
IlPeach 13y ago
Interesting but I was expecting a bit more insights on the "modularity" approach of these different client-side package managers.
SkyMarshal 13y ago
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. PS - amusing typo, it's CPAN, not CSPAN :)
hernan604 13y ago
See JSAN: http://openjsan.org/ http://openjsan.org/ (without www) 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 13y ago
  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)
shire 13y ago
I mostly work with NPM and Node also Bower. Very powerful tools
marknadal 13y ago
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).
- JohnDotAwesome 13y ago
  WUT
- ben336 13y ago
  "it overwrites how require is actually supposed to be used" According to whom? RequireJS is an implementation of the AMD spec.
  - camus2 13y ago
    spec written by whom? anybody came write something and claim it's a spec. There is no AMD spec.
  - marknadal 13y ago
    According to NodeJS, which given its dominance is rather important.
dreamdu5t 13y ago
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.
wyuenho 13y ago
I've written about JS modules in the past. https://medium.com/what-i-learned-building/5a31feb15e2 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.
- fragmede 13y ago
  > The JS world is split in 2 right now What about Meteor?
- Bockit 13y ago
  What do you think of browserify coupled with transforms providing html templates[1] and css inclusion[2]. [1]: E.g., https://npmjs.org/package/browserify-jade https://npmjs.org/package/browserify-jade [2]: E.g., https://npmjs.org/package/stylify https://npmjs.org/package/stylify
  - wyuenho 13y ago
    package.json doesn't have any place to define the styles and templates your component exports, so browserify can't meaningfully resolve dependencies and build your assets for you. For really good support, you'll need to be able to rewrite the URLs inside CSS too due to different directory structures within each component. Component does that for you.
alkonaut 13y ago
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?
- camus2 13y ago
  TC39 is working on it ,i think they are 10 years late of that matter, and the solution they chosed is not even that good.
hackula1 13y ago
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. This https://github.com/lodash/lodash/blob/master/lodash.js https://github.com/lodash/lodash/blob/master/lodash.js is hardly the ~200 LOC module being described.
- jdd 13y ago
  It may help rereading the post as it does explain why both are on the list. 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://npmjs.org/package/lodash-amd https://github.com/lodash/lodash-es6 https://github.com/lodash/lodash-es6 https://npmjs.org/package/lodash-node https://npmjs.org/package/lodash-node https://npmjs.org/browse/keyword/lodash-modularized 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 https://github.com/kirbysayshi/node-ddd-jquery#rationale
ianstormtaylor 13y ago
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. [1]: https://github.com/segmentio https://github.com/segmentio [2]: https://github.com/ianstormtaylor?tab=repositories https://github.com/ianstormtaylor?tab=repositories
- ericgj 13y ago
  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.
- paultannenbaum 13y ago
  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.
etler 13y ago
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`.
fiatjaf 13y ago
Check lit http://www.corslit.com/ http://www.corslit.com/

101 points by remotesynth 13y ago

deleted 13y ago

[deleted]

_mayo 13y ago

Looks like the site's down, Here's a text only cached version: http://webcache.googleusercontent.com/search?q=cache:http://flippinawesome.org/2013/11/11/towards-a-more-modular-future-for-javascript-libraries/&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...

puppetmaster3 13y ago

Based on the site being down, I think the future is to use a CDN, yes? MaxCDN is $39/year.

remotesynth 13y ago
Site is back up. Sorry about the issues.
dictum 13y ago
$39/month.

bwindels 13y ago

Couldn't agree more with the article. I use browserify in all my new projects and love having the same module comfort as I do in node.

jsmcgd 13y ago

The graph of library growth is stunning: http://modulecounts.com/ http://modulecounts.com/ For all of JS quirks it is clearly getting something(s) very right.

hyperpape 13y ago
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.
- thenmar 13y ago
  You don't think it has anything to do with Node?
  - SkyMarshal 13y ago
    Node only came about b/c Google wrote V8 for high-performance browser JS. Node has certainly expanded JS's reach in a big way, but wouldn't have existed in the first place if, say, Lua were the lingua franca of all web browsers (or maybe V8 and Node would still exist but target Lua instead).
- davedx 13y ago
  What about closures and first class functions? Or easy interop (JSON), object and array literals? JavaScript has more going for it than platform ubiquity.
  - knome 13y ago
    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 supporting half of systems in javascript, and all systems in brainfuck, people would begin writing brainfuck-targeting compilers immediately.

alanning 13y ago

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. 1. http://yuilibrary.com http://yuilibrary.com 2. http://meteor.com http://meteor.com

clarle 13y ago
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: https://speakerdeck.com/ericf/yui-and-the-future 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.

IlPeach 13y ago

Interesting but I was expecting a bit more insights on the "modularity" approach of these different client-side package managers.

SkyMarshal 13y ago

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. PS - amusing typo, it's CPAN, not CSPAN :)

hernan604 13y ago

See JSAN: http://openjsan.org/ http://openjsan.org/ (without www) 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 13y ago
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)

shire 13y ago

I mostly work with NPM and Node also Bower. Very powerful tools

marknadal 13y ago

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).

JohnDotAwesome 13y ago
WUT
ben336 13y ago
"it overwrites how require is actually supposed to be used" According to whom? RequireJS is an implementation of the AMD spec.
- camus2 13y ago
  spec written by whom? anybody came write something and claim it's a spec. There is no AMD spec.
- marknadal 13y ago
  According to NodeJS, which given its dominance is rather important.

dreamdu5t 13y ago

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.

wyuenho 13y ago

I've written about JS modules in the past. https://medium.com/what-i-learned-building/5a31feb15e2 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.

fragmede 13y ago
> The JS world is split in 2 right now What about Meteor?
Bockit 13y ago
What do you think of browserify coupled with transforms providing html templates[1] and css inclusion[2]. [1]: E.g., https://npmjs.org/package/browserify-jade https://npmjs.org/package/browserify-jade [2]: E.g., https://npmjs.org/package/stylify https://npmjs.org/package/stylify
- wyuenho 13y ago
  package.json doesn't have any place to define the styles and templates your component exports, so browserify can't meaningfully resolve dependencies and build your assets for you. For really good support, you'll need to be able to rewrite the URLs inside CSS too due to different directory structures within each component. Component does that for you.

alkonaut 13y ago

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?

camus2 13y ago
TC39 is working on it ,i think they are 10 years late of that matter, and the solution they chosed is not even that good.

hackula1 13y ago

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. This https://github.com/lodash/lodash/blob/master/lodash.js https://github.com/lodash/lodash/blob/master/lodash.js is hardly the ~200 LOC module being described.

jdd 13y ago
It may help rereading the post as it does explain why both are on the list. 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://npmjs.org/package/lodash-amd https://github.com/lodash/lodash-es6 https://github.com/lodash/lodash-es6 https://npmjs.org/package/lodash-node https://npmjs.org/package/lodash-node https://npmjs.org/browse/keyword/lodash-modularized 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 https://github.com/kirbysayshi/node-ddd-jquery#rationale

ianstormtaylor 13y ago

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. [1]: https://github.com/segmentio https://github.com/segmentio [2]: https://github.com/ianstormtaylor?tab=repositories https://github.com/ianstormtaylor?tab=repositories

ericgj 13y ago
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.
paultannenbaum 13y ago
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.

etler 13y ago

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`.

fiatjaf 13y ago

Check lit http://www.corslit.com/ http://www.corslit.com/