Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

An unopinionated approach like Bower is probably what the (client-side) JavaScript ecosystem needs, but all the same, what's lacking here is a philosophy.

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: