Isaac Z. Schlueter, the man who’s driving npm (you should know and thank him for this), wrote a reply to TJ Holowaychuk’s blog post on components - a kind of package management similiar to npm. While npm is focused on Node.js and JavaScript only (you can use it for other stuff, but I heavily dislike that), component explicitly includes templates (HTML), stylesheets (CSS) and assets. It’s intended for server- and clientside use. Just read through TJ’s post and you’ll get the gist.
Component is a replacement of some tasks that you would have accomplished with npm before, which of course puts up some fights, but it goes even further. Anyways the “little war” started in this GitHub issue. And in the end Isaac himself wrote his mindset on component and npm, as well as an expansive blog article.
For the most part, I agree with Isaac. But there are some things that aren’t really true.
The classic battle between DOM manipulation libraries such as jQuery and MooTools serve as an obvious example of fragmentation. Even if one is more popular than the other this doesn’t mean we don’t have a problem. Have you ever seen a great jQuery plugin and thought to yourself “damn! I’m using MooTools!” or perhaps the other way around? That highlights the problem right there, we should have no “jQuery plugins”, no “Dojo modules”, just simply “components” that we can all consume.
To a certain extent, this is inescapable. Even if we say, “Use AMD” or “Use CommonJS require()” or whatever else, there’s always going to be some level of segmentation. Hell, even within node there are modules that only work with Express, and so on.
Yes, but no. There are and should be some express-specific, jQuery-specific and MooTools-specific plugins, because they extend a unique function of the module. For instance, it wouldn’t make sense trying to extend an express app.router, without having one in the module. But in theory, even that would be possible, because express uses the app.use() scheme. You have to use some sort of standardized plugin implementation pattern.
Components could have a “component.json” much like the commonjs package.json, or we can simply extend package.json. This would of course act as the package manifest, letting the world know if it has stylesheets, templates, scripts, images and so on. I believe we should avoid the minimal gains of magical auto-globbing of files, we can just simply list these and avoid unnecessary complexity and I/O.
It should be package.json. I think “styles” should be spelled “css” and “templates” should be spelled “html”. Otherwise I think we’d soon see stylus and less files in “styles”, and mustache and jade and markdown in “templates”. Maybe that’s ok. It’s a bikeshed we can paint later.
Nope, it should be component.json. Otherwise components will be published to npm, which TJ and the whole component community does not want. npm is great for Node frameworks and helper functions, but bad for real components or browser stuff. Express goes with npm, jQuery with component.
I don’t understand either, why TJ called it styles and templates on the one hand, but on the other hand doesn’t want to use jade files in components. I think this is a real issue the community needs to talk about, since it’s very useful at some points.
The unnecessary complexity of globbing is not such a big deal, really, but it should be left out of any “spec” that we try to get people to use. npm does this for a few things, and it’s pretty easy. It can be a step that’s performed at publish-time for convenience relatively easily, so that the data is ready at install-time.
That’s true. But to seperate templates and styles etc. we should force a specific directory structure, so that every file goes in the specific folder.
Delivering components…
I disagree with TJ here, and think that using the npm registry is actually the best way to go.
- Any other system will have to run into and solve the same exact problems that the npm registry already has to solve.
- User management, package ownership, and namespace collisions are already taken care of.
- It’s pretty fast, since you’re just fetching content, not the full history.
- There’s a lot of reusable code for interacting with it programmatically, and as npm matures and pieces are factored out of it, this will only get better. Node is the obvious choice for a tool to fetch and build client-side components.
Isaac has some good points, but of course he wants to defend his little child (I would too). TJ takes a good approach with component. People who don’t see the advantages will take our components and republish them to npm/ender/bower/whatever. So what? It doesn’t destroy component. We can (and will) still use it.
Thank you, Isaac, for the awesome npm. Thank you, TJ, for the awesome component manager.
(via izs)
