http://news.ycombinator.com/item?id=4487221
Also of note: the algorithm to check URL was already submitted is easily fooled.
11–20 of 45 posts
http://news.ycombinator.com/item?id=4487221
Also of note: the algorithm to check URL was already submitted is easily fooled.
Amazing how timing (and luck?) matters on whether a submission gets to the top or not. http://news.ycombinator.com/item?id=4487221 Also of note: the algorithm to check URL was already submitted is easily fooled.
Does anyone think this can finally be the tool to bring sane package management to client side JavaScript development? I'm hesitant to use any of the existing tools because none of them support all the libraries I use, so I'd end up doing stuff manually anyway, and I don't have any confidence that any of them will keep working in the long term.
The reason why I am skeptical of new entrants into the javascript package management arena is that there is already a package manager with over 14k packages and a vibrant community that is producing packages at a very high rate: npm. npm might not be the best package manager as-is for browser development, but tools like browserify (disclaimer: I wrote browserify), ender, or many others can let your browser code use much of the value that has already been created for npm, even though npm is primarily about node.js packages. A surprising number of modules written for node will just work in tools like browserify.
Any upstart package systems would be wise to have a clear and simple path for unlocking the value created in the node community because there is too much value being created in npm to ignore. Whether that path involves adding fields to the package.json, tools to bridge the gap between package repositories, fancy in-browser trickery or compile steps remains an open question but it would be really pointless to require people to publish their modules that they've already put on npm to buy in to yet another package system, especially since there seems to be a new package manager every month lately.
Does anyone think this can finally be the tool to bring sane package management to client side JavaScript development? I'm hesitant to use any of the existing tools because none of them support all the libraries I use, so I'd end up doing stuff manually anyway, and I don't have any confidence that any of them will keep working in the long term.
Does anyone think this can finally be the tool to bring sane package management to client side JavaScript development? I'm hesitant to use any of the existing tools because none of them support all the libraries I use, so I'd end up doing stuff manually anyway, and I don't have any confidence that any of them will keep working in the long term.
Well, RequireJS is pretty solid for client side package management. With solid config files you can build out large client side applications that grab dependencies asynchronously, and it DOES work with everything.
and it DOES work with everything
... so long as you wrap all the files in the particular variant of define() function that works with requirejs (but not with other competing AMD function signatures). And then you might want to use some modules written for commonjs or node with `exports`, so you'll need a tool to transform those files. And then you'll probably want to compile the application into a single javascript bundle in production for performance.I'm not saying bower is any better in any of these respects, just that everything is terrible.
What I mean: if I'm just using jQuery and two or three other JavaScript libraries, downloading those manually isn't a big ordeal, they're single files, already minified for my convenience, available on a public CDN if I want to use that in production, they usually have no dependencies themselves and I'm only inclined to update them to newer version if something doesn't work, which is hardly ever. All of these things make package management for the server a godsend but package management for the client sort of... meh.
Ender, on the other hand (and for all its flaws) does a good job of explaining how you can use it to approach libraries for the client more like you'd approach them on the server: tiny packages that do one thing well and that don't reinvent the wheel but where applicable build on existing libraries. Now that sounds like something I can get behind.
Similarly, if you read TJ Holowaychuk's ideas on package management in the browser (linked to by kreutz below, or at http://tjholowaychuk.com/post/27984551477/components) then you start to get an idea of, yeah, maybe it'd be cool to have these packages that are little bundles of HTML, CSS and JavaScript and together they make up a single interface element or something of the sort -- included in your project as-needed. Fascinating.
Bower, by comparison, sounds like "a thing that downloads things for me." It might just be the copy (rather than the idea) and maybe it's the tool we need to do what someone like TJ envisions, but it's not clicking for me right now.
https://github.com/component/component
https://github.com/component/spec/wiki
Bower seems like a blatant ripoff. Twitter Engineering doesn't even mention the component project or spec on the Bower page at all...
What's different about this than the official component project? https://github.com/component/component https://github.com/component/spec/wiki Bower seems like a blatant ripoff. Twitter Engineering doesn't even mention the component project or spec on the Bower page at all...