
Towards a More Modular Future for JavaScript Libraries - remotesynth
http://flippinawesome.org/2013/11/11/towards-a-more-modular-future-for-javascript-libraries/
======
alanning
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
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.

------
SkyMarshal
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 :)

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

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

~~~
Bockit
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
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.

~~~
Bockit
That's a pretty fair point about the CSS url rewriting, it's possibly the kind
of thing you can fix with a browserify transform, but iffy and as you say
component is doing it already.

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

~~~
paultannenbaum
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.

~~~
ericgj
I haven't tried bower, but I always get a little confused when it gets
compared to component. Bower seems like a downloader with some 'dependency
management'. But its 'dependencies' are disconnected from a module/build
system. Great if you have a separate tool to do your build, but frankly most
of them out there are awful, and it would be a nightmare even with the best to
wire them up to all the conventions of all the libraries you pull in.

As Ian said, component's opinions encourage more modular, better code, and
allow you to do what Web Components only now are promising within the DOM
itself: bundle together templates, css, code, data, etc. And it does this
without imposing a framework. For instance, if you have a pure javascript
library, it is extremely easy to package for both component and NPM. Most of
the UI components are framework-independent and that is encouraged. The
component ecosystem and community is fantastic. And it's not sponsored by a
corporation on the NYSE :) These were the main reasons I was attracted to
component. The learning curve is a bit steep, but getting better all the time.

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

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

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

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

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

~~~
ben336
"it overwrites how require is actually supposed to be used"

According to whom? RequireJS is an implementation of the AMD spec.

~~~
marknadal
According to NodeJS, which given its dominance is rather important.

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

~~~
davedx
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
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.

~~~
taybin
All the cool programmers use CoffeeFuck.

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

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

------
fiatjaf
Check lit [http://www.corslit.com/](http://www.corslit.com/)

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

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

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

~~~
remotesynth
Site is back up. Sorry about the issues.

