Hacker News Reader

Comment by painisRelative | Hacker News Reader

why drop bower support damn it!

Lodash dropped bower support in favor of npm because "16% use bower vs. 76% npm for AMD packages": https://twitter.com/jdalton/status/677323442488672257

...according to a twitter poll on a personal account :P

I avoid bower wherever possible, but removing support does smell a bit like an activist move. There may be more to the story, though.

The poll was, should it be dropped, given that fact. The fact was not the poll result.

Given that there were 14825158 downloads of lodash from npm last month, that implies that there were over 3M downloads from bower. That's a lot of people to throw under the bus.

For what was a single 19 line JSON file: https://github.com/lodash/lodash/commit/3b86574b4da0828f6afb...

According to bower stats over the last 7 days lodash was installed 23 times compared to 4 million npm downloads & 181 new npm packages depending on it.

http://bower.io/stats/

http://npm-stat.com/charts.html?package=lodash

https://gist.github.com/anvaka/8e8fa57c7ee1350e3491/revision...

Sounds broken. My team alone would have installed it more times that that.

¯\_(ツ)_/¯

After thinking about it a bit more, the only reasonable conclusion I can come to is the following:

It's the number of times users actually typed

    bower install lodash

i.e. adding it to a project that didn't already have it, as opposed to just running bower install on a package which uses lodash.

Would also explain why despite bower itself being installed 37000 times in the last 7 days, the most installed package is only listed as 100 or so times.

You'd even need multiple busses ;)

Why did you shorten one number but not the other? 14.8M via npm vs 3M via bower

One is exact, one is approximate

Plenty of people don't use AMD packages at all, wtf?

If more major libraries drop support for bower, it might (hopefully) die soon. What does bower do better than NPM?

Well, I haven't used npm for css packages yet, but presumably it's okay with webpack/brunch etc.

Its great with everything. Frontend / backend, etc. When I removed bower from our app last year, adopted Webpack and migrated everything over to NPM it dramatically simplified things.

For Brunch, looks like [initial, probably v buggy] NPM stuff went into master about 10 days ago.

I've been using npm support in Brunch and so far so good.

Ah, that's good to know; I'd been sticking to Bower for Phoenix' front end stuff, might start looking at migrating them to NPM if Brunch support is stable now.

JSPM!

It works a lot like NPM but is specifically intended for use with front-end modules.

Features:

- uses System.js (a polyfill for the future ES6-module-loader spec

- supports CommonJS, AMD, and UMD formats

- has plugins for importing other types (ex css)

- support Typescript/Traceur/Babel out of the box

- uses a flat dependency structure (ie like NPM v3)

- can generate bundles and self-executing bundles (incl tree shaking and minify)

- tracks specific versions of dependencies

Unlike NPM, module installation doesn't depend on packages published to a central registry. It can install versioned modules directly from GitHub and NPM. The registry it uses is nothing but GitHub repo with module-to-repo mappings and compatibility shims.

Here's the link: http://jspm.io/

Lodash is already included in the registry: http://kasperlewau.github.io/registry/#/?q=lodash

Personally I'll stick with RPM for all my JS packaging needs.

What do you use to polyfill the browser to support RPM? :)

yum makes rpm easymode!

Why?

It doesn't cover any of the functionality that JSPM provides and publishing modules as RPM only makes them available to (at most) 1%-2% of users.

JSPM is written in Node and available via NPM. So... it works on pretty much anything out of the box.

npm can install directly from GitHub:

    npm install visionmedia/express

Or any git repo:

    npm install git+https://git@github.com/visionmedia/express.git
    npm install git+ssh://git@github.com/visionmedia/express.git

Oh... Awesome. TIL, I guess.

Thanks for the tip. I wish my comment wasn't locked in already so I could correct the misinformation.

Yeah there is no need to drop bower support. I prefer bower over NPM. I don't understand this. Great work by the way.

I think the thinking behind dropping the support is something like this:

I use browserify/webpack/node and npm is great. I wish more libs that I use were also on npm so that I wouldnt have to fork/shim them. How can I force other people to use npm? Maybe if I drop bower support for my awesome lib that everyone uses, other libs will follow suit, or perhaps the users will see the light and stop using bower because it sucks.

I loved bower and really preferred it in regard with npm for frontend modules. However more and more packages went to npm-only and we completely switched to npm for all.

Looking back, I am glad since it's just a nightmare to deal with dozens of package managers. Because bower was installed via npm, we had npm installed already and just skipped the bower part.

Bower is no longer actively maintained: https://github.com/bower/bower/pull/1748

Bower is very actively being maintained: http://bower.io/blog/2015/bower-alive-looking-contributors/ and just read https://twitter.com/bower or check https://github.com/bower/bower

Although there is a rationale for converging to npm, the tl;dr regarding bower is that it's not cool any more.

Reply on news.ycombinator.com