Consider deprecating Bower.

[trusktr]

And encourage NPM + Webpack/Browserify/etc workflows. I don't intend to introduce hard feelings or anything like that, but those other workflows are superior in many ways, and maybe we should encourage people to move to them for the greater good of the Web/JavaScript community as a whole.

[calidion]

@trusktr

Feel free to use npm as your package management, but don't be bothered with the existence of bower.
npm is good at managing versions and packages.
But I don't think npm is a replacement of bower.

After updating to version 3, npm introduces many problems.
Bower is a much cleaner and easier way for front end project management.
And it can also take advantages from npm.
By using both bower and npm, we can clearly tell from which are tooling packages to which are core packages of front end projects.
It would be very useful and you won't be lost in the package hell which npm3 now has introduced, where even the smallest project will get hundreds of packages installed.

npm 3 is no better in managing node modules than 2.x, let alone front end modules.
npm 3 is somewhat a mass to package management comparing to its previous versions and makes no progress.
npm has also violated the basic Unix principal: do one thing and do it well.

npm should be improved to be the node package management tool.
and
bower should be improved as the front end package management tool.
They may have something in common, but totally two different directions.

[cmmata]

@trusktr That's the same kind of comment as if I say to deprecate grunt because gulp has many improvements. I think it's good to have choices. Maybe in one project you see that gulp is better, but in another one you prefer grunt because of one plugin, or something else.

Npm and Bower both have pros and cons, and can be used together as @calidion says. In my company we use both because of exactly that reason. We use bower for front-end packages and npm for libraries and utilities, and it's much cleaner than one package.json with all of them.

[j0lvera]

I don't think encouraging only one way to do things is good, is not the nature of the web, people want options. Diversity, even in tools, is good.

Also, I wound't encourage "the community" to use NPM + Webpack/Browserify knowing that next year we are going to have "better and cooler" tools to replace at least two of those. What I would encourage is to test, experiment, and find what tools are right for them and use that, take the decision based on what their experience, not follow blindly what people recommend.

I'm not saying that recommendations are bad, but blindly follow some trend is.

[trusktr]

Sorry guys, I was half-way ranting because I find libraries that continue to rely on globals and need to be loaded with <script> tags which makes maintenance more difficult. I suppose I'm just being hard on that method because ES6 Modules are the solution we should be using instead of global scripts, and ES6 modules are on the verge of becoming a native part of browsers, but already exist in Meteor/Webpack/Browserify/JSPM/etc workflows, so it'd just be awesome if we all moved to those workflows and encouraged everyone to move to ES6 (or at least CommonJS) modules. If this were to happen, then even if those libraries ceased to exist in a year or two, at least the code written for them (ES6 Modules) would be ready for the ES6-module future, which is unlike what happens if we continue to write global scripts shipped through Bower, where those global scripts will continue to be a maintenance problem.

even the smallest project will get hundreds of packages installed.

That's the package's fault though, not NPM's. There's packages on NPM with zero dependencies.

I'm not saying that recommendations are bad, but blindly follow some trend is.

That's true, but the trend I'm encouraging by suggesting Webpack, Browserify, or anything similar to those is really more the trend of using ES6 Modules, which is a huge part of the future of JS.

Choosing to use Bower today is similar to ignoring that ES6 modules are arriving, which is fine since those aren't native yet, but I'm being a stickler and just wishing everyone would jump on that train right now so that the ES6-module future can come quicker.

[sheerun]

@trusktr I'm on my way to responding to you. I partly agree, please be patient :)

[j0lvera]

We need to consider that people learning web development may find NPM and similar hard to assimilate at first, bower helps with being simple and useful in this case.

[sheerun]

@happy-ali Please don't close issues

[SoundBot]

We need to consider that people learning web development may find NPM and similar hard to assimilate at first, bower helps with being simple and useful in this case.

@thinkxl so instead of encouraging them to use best practices you propose to use obsolete techniques? Maybe we should all start using Notepad because it is "being simple"?

I understand that you guys cannot be unbiased as bower maintainers, but at least you should to come up with road map, how to update bower to be aligned with current technologies.

[olegberman]

I don't use Bower anymore for core projects that I'm working on (I use NPM and Webpack instead). Although if I were to create a landing page with jQuery, fancy moving things, parallax backgrounds, and a contact form, (you name it)... then Bower is something that I would use to manage countless jQuery plugins, etc.

@trusktr depending on global state is bad only if that slows down your shipping times or brings in problems for other developers. Otherwise if your project is small enough it doesn't appear to be one. We should not create a problem if it doesn't exist.

Choose tools for your project, don't let the tools define your project.

tl;dr Bower should live.

[j0lvera]

@SoundBot if someone wants to start HTML for the first time, yes I would recommend to use Notepad, once he/she understands what is HTML about, then introduce Sublime Text, and so on.

What you refer to best practices, are often opinionated practices, or best practices for your case. In my experience I find Bower useful with WordPress development, and Webpack for JavaScript development. Developers around me are in a similar situation, just because they don't blog, don't have github profiles, don't have social accounts or whatever, it doesn't mean they don't exist, they are busy writing code.

I don't think that the right answer to this is to tell everyone to use Webpack/Browserify just because someone thinks is the best and the only solution, AND, encourage other projects that he thinks are obsolete (because he doesn't use them) to close.

As long as people still find Bower useful, I think it should be maintained.

[justinfagnani]

@trusktr it's important to note that Bower is still much, much better for frontend development 1) in cases where you really can't support duplicate versions of packages, 2) When you can't support the synchronous, disk-optimized, node module resolution algorithm, or 3) don't want to be required to use build tools to translate web-incompatible JS source to web-compatible source.

1. Includes custom elements, polyfills, large packages, and global CSS. I absolutely never want multiple nested versions of packages, and npm3 will still gladly give me that rather than fail on version conflicts.

2. Includes native ES6 modules. Node is going off on their own, against the capabilities of HTML wrt modules, and so node ES6 modules won't be loadedable by browsers. Bower has a hope of hosting an ecosystem of ES6 modules that import each other via URL and working natively. An npm module that imported dependencies via: import * as _ from '../lodash/lodash.js'; would not actually work in node (at least as planned now, with .mjs extensions: it wouldn't parse as a module, and in a top-level project folder would reach out of the folder).

3. Includes every CommonJS module, which are simply not web-compatible as evidenced by the need for build tools like Browserify and Webpack, or runtime translators like SystemJS, to cross-compile them to something similar to AMD, which actually does work on the web.

I'm not sure what the ultimate solution is, but Bower certainly behaves how I want a package manager for the web to, and it's ecosystem is compatible with the web. I hope it sticks around a while longer.