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.
- Currently npm’s only issues are package delivery and namespacing, which is and will stay bad.
- No, they aren’t. When you want to register a package named rsa, but there’s already one, you’re simply not allowed to. You have to give it bullshit names like simple-node-rsa-string-converter-openssl-binding. That’s no taking care of problems.
Component brilliantly solves this issue by using GitHub as the registry. - Pfft. Speedtest shows, that component is 30% faster. Component doesn’t download a full history either. It just grabs the current master breach via HTTP. Super fast.
- “Node is the obvious choice for a tool to fetch and build client-side components.” Yup, however npm isn’t.
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)
-
pazguille hat diesen Eintrag von tjholowaychuk gerebloggt
-
von markvigeant als Favorit markiert
-
von timsamoff als Favorit markiert
-
von sathvikp als Favorit markiert
-
danielsitek hat diesen Eintrag von tjholowaychuk gerebloggt und das hinzugefügt:
really good points in there
-
von danielsitek als Favorit markiert
-
von yolkyolk als Favorit markiert
-
von wilmoore als Favorit markiert
-
von pazguille als Favorit markiert
-
nickleefly hat diesen Eintrag von tjholowaychuk gerebloggt
-
von sintaga als Favorit markiert
-
in1blog hat diesen Eintrag von tjholowaychuk gerebloggt
-
von kanzakikikuchi als Favorit markiert
-
von travedoc als Favorit markiert
-
von bjornstar als Favorit markiert
-
douggdev hat diesen Eintrag von tjholowaychuk gerebloggt
-
von nek als Favorit markiert
-
von jenius als Favorit markiert
-
gobengo hat diesen Eintrag von tjholowaychuk gerebloggt und das hinzugefügt:
a gem
-
von design-themes als Favorit markiert
-
silvinci hat diesen Eintrag von izs gerebloggt und das hinzugefügt:
Isaac Z. Schlueter,...man who’s driving npm (you should know and thank him for this),...
-
kmt7 hat diesen Eintrag von tjholowaychuk gerebloggt
-
mohamedmansour hat diesen Eintrag von tjholowaychuk gerebloggt und das hinzugefügt:
Eliminate AMD, Eliminate jQuery, Eliminate
-
von mohamedmansour als Favorit markiert
-
snbartell hat diesen Eintrag von izs gerebloggt
-
gabrieljoshua hat diesen Eintrag von izs gerebloggt
-
von gabrieljoshua als Favorit markiert
-
von frozzare als Favorit markiert
-
von julionc als Favorit markiert
-
von business-ides als Favorit markiert
-
von underscore-keithnorm als Favorit markiert
-
von smagch als Favorit markiert
-
von samshull als Favorit markiert
-
von vicapow als Favorit markiert
-
von pocotumblr als Favorit markiert
-
von damonoehlman als Favorit markiert
-
webfront hat diesen Eintrag von tjholowaychuk gerebloggt
-
juliangruber hat diesen Eintrag von tjholowaychuk gerebloggt
-
von toxley als Favorit markiert
-
von outatime als Favorit markiert
-
von poopyd4 als Favorit markiert
-
von ferlores als Favorit markiert
-
von dshaw als Favorit markiert
-
von euforic als Favorit markiert
-
niccai hat diesen Eintrag von tjholowaychuk gerebloggt
-
von geddski als Favorit markiert
-
von juanignacioiglesias als Favorit markiert
-
von oivoodoo als Favorit markiert
-
bernaulli hat diesen Eintrag von tjholowaychuk gerebloggt
- Mehr Anmerkungen anzeigen
