New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider deprecating Bower. #2298

Closed
trusktr opened this Issue Jun 1, 2016 · 136 comments

Comments

Projects
None yet
@trusktr

trusktr commented Jun 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Jun 1, 2016

Member

@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.

Member

calidion commented Jun 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cmmata

cmmata Jun 1, 2016

@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.

cmmata commented Jun 1, 2016

@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.

@thinkxl

This comment has been minimized.

Show comment
Hide comment
@thinkxl

thinkxl Jun 1, 2016

Member

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.

Member

thinkxl commented Jun 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Jun 1, 2016

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.

trusktr commented Jun 1, 2016

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.

@trusktr trusktr closed this Jun 1, 2016

@sheerun sheerun reopened this Jun 1, 2016

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Jun 1, 2016

Contributor

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

Contributor

sheerun commented Jun 1, 2016

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

@thinkxl

This comment has been minimized.

Show comment
Hide comment
@thinkxl

thinkxl Jun 1, 2016

Member

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.

Member

thinkxl commented Jun 1, 2016

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.

@AElouai AElouai closed this Jun 2, 2016

@sheerun sheerun reopened this Jun 2, 2016

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Jun 2, 2016

Contributor

@happy-ali Please don't close issues

Contributor

sheerun commented Jun 2, 2016

@happy-ali Please don't close issues

@SoundBot

This comment has been minimized.

Show comment
Hide comment
@SoundBot

SoundBot Jun 8, 2016

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.

SoundBot commented Jun 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@olegberman

olegberman Jun 8, 2016

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.

olegberman commented Jun 8, 2016

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.

@thinkxl

This comment has been minimized.

Show comment
Hide comment
@thinkxl

thinkxl Jun 8, 2016

Member

@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.

Member

thinkxl commented Jun 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 9, 2016

@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.

justinfagnani commented Jun 9, 2016

@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.

@mmmeff

This comment has been minimized.

Show comment
Hide comment
@mmmeff

mmmeff Jun 9, 2016

Yeah, bower is great at being a simple front-end package manager for smaller projects where globals are acceptable.

Yeah, npm is a mess when it comes to project setup and building, even though many new best practices are being generated from that side of the fence.

Why not spend your efforts bringing Bower's simplicity to npm instead of maintaining Bower for all eternity? I'm all for giving people options, but most would agree that the javascript community is in dire need of some defragmentation.

mmmeff commented Jun 9, 2016

Yeah, bower is great at being a simple front-end package manager for smaller projects where globals are acceptable.

Yeah, npm is a mess when it comes to project setup and building, even though many new best practices are being generated from that side of the fence.

Why not spend your efforts bringing Bower's simplicity to npm instead of maintaining Bower for all eternity? I'm all for giving people options, but most would agree that the javascript community is in dire need of some defragmentation.

@schneidmaster

This comment has been minimized.

Show comment
Hide comment
@schneidmaster

schneidmaster Jun 9, 2016

Keep in mind that it's not just about JS projects. Bower is also very useful for asset systems that need prebuilt source files but want to handle concatenation and minification themselves, such as Rails (slash rails-assets). I've encountered a not-insignificant number of npm packages that don't even include built + babel-ified assets because they assume that if you're using npm you'll do it yourself.

schneidmaster commented Jun 9, 2016

Keep in mind that it's not just about JS projects. Bower is also very useful for asset systems that need prebuilt source files but want to handle concatenation and minification themselves, such as Rails (slash rails-assets). I've encountered a not-insignificant number of npm packages that don't even include built + babel-ified assets because they assume that if you're using npm you'll do it yourself.

@vance

This comment has been minimized.

Show comment
Hide comment
@vance

vance Jun 9, 2016

Agree with mmmeff... I'd rather go back to basics and have NPM be more configurable (consistently configurable) instead of three to five inconsistent ways of doing the same thing. It's all ultimately toward the same end: module management and runtime injection, version resolution, backend, frontend and compiling/packaging/minifying/generating... I don't see C# devs using more than one package manager or compiler and don't see them running around complaining about lack of choices... Maybe I'm hanging out with the wrong devs?

vance commented Jun 9, 2016

Agree with mmmeff... I'd rather go back to basics and have NPM be more configurable (consistently configurable) instead of three to five inconsistent ways of doing the same thing. It's all ultimately toward the same end: module management and runtime injection, version resolution, backend, frontend and compiling/packaging/minifying/generating... I don't see C# devs using more than one package manager or compiler and don't see them running around complaining about lack of choices... Maybe I'm hanging out with the wrong devs?

@justinfagnani

This comment has been minimized.

Show comment
Hide comment
@justinfagnani

justinfagnani Jun 9, 2016

@mmmeff what does bower have to do with globals? Bower packages can use web compatible module systems like AMD, System JS and soon native ES6 modules.

justinfagnani commented Jun 9, 2016

@mmmeff what does bower have to do with globals? Bower packages can use web compatible module systems like AMD, System JS and soon native ES6 modules.

@ansuz

This comment has been minimized.

Show comment
Hide comment
@ansuz

ansuz Jun 9, 2016

Since we're all here why don't we also rewrite bower in Rust?

trollface

ansuz commented Jun 9, 2016

Since we're all here why don't we also rewrite bower in Rust?

trollface

@kornelski

This comment has been minimized.

Show comment
Hide comment
@kornelski

kornelski Jun 9, 2016

Contributor

edit: yarn install --flat does exactly what I need, so I don't have a reason to user Bower any more.


npm3 + browserify lacks the feature of showing an error when incompatible modules are used together.

At FT we have many components that are at different levels of maturity and maintenance and have a complex matrix of dependencies. We use semver and rely on Bower to automatically enforce that only a minimal and coherent set of dependencies is used in each project.

We have components for some inherently global things such as page's main font, color palette and nav header style, and we like that Bower will refuse to install incompatible set of components.

Please note that for us it's not a technical limitation of being unable to bundle multiple versions of a global component, but a business requirement. Nothing stops us from using modules/namespaces that enable use of last year's button design in this year's form design, but from product quality point of view such mixing is a bug, not a feature. We rely on bower saying "nope, those things don't work together, your page will look like a ransom note, please use consistent set of components". We don't want to ship more than one set of webfonts, even if npm and clever bundling would make it possible.

Contributor

kornelski commented Jun 9, 2016

edit: yarn install --flat does exactly what I need, so I don't have a reason to user Bower any more.


npm3 + browserify lacks the feature of showing an error when incompatible modules are used together.

At FT we have many components that are at different levels of maturity and maintenance and have a complex matrix of dependencies. We use semver and rely on Bower to automatically enforce that only a minimal and coherent set of dependencies is used in each project.

We have components for some inherently global things such as page's main font, color palette and nav header style, and we like that Bower will refuse to install incompatible set of components.

Please note that for us it's not a technical limitation of being unable to bundle multiple versions of a global component, but a business requirement. Nothing stops us from using modules/namespaces that enable use of last year's button design in this year's form design, but from product quality point of view such mixing is a bug, not a feature. We rely on bower saying "nope, those things don't work together, your page will look like a ransom note, please use consistent set of components". We don't want to ship more than one set of webfonts, even if npm and clever bundling would make it possible.

@kornelski

This comment has been minimized.

Show comment
Hide comment
@kornelski

kornelski Jun 9, 2016

Contributor

edit: yarn is even faster.


I used to favor npm over Bower, but npm 3 for me is such a massive step backwards in terms of reliability and speed, that now Bower seems quite stable and fast in comparison.

Contributor

kornelski commented Jun 9, 2016

edit: yarn is even faster.


I used to favor npm over Bower, but npm 3 for me is such a massive step backwards in terms of reliability and speed, that now Bower seems quite stable and fast in comparison.

@capaj

This comment has been minimized.

Show comment
Hide comment
@capaj

capaj Jun 9, 2016

Having modules and namespaces that make it easy to use last year's button design in this year's form design is a bug to us, not a feature.

@pornel I wish I had these kinds of bugs more often in my codebase.

capaj commented Jun 9, 2016

Having modules and namespaces that make it easy to use last year's button design in this year's form design is a bug to us, not a feature.

@pornel I wish I had these kinds of bugs more often in my codebase.

@Olical

This comment has been minimized.

Show comment
Hide comment
@Olical

Olical Jun 9, 2016

Dear Bram Moolenaar, I know you've been working on Vim for 28 years, but Neovim has more features than Vim now. So stop working on Vim, please.

Let's apply this logic to Linux distributions, JavaScript UI libraries or web frameworks in any language. Why on Earth would a project deprecate themselves because someone on the internet prefers an alternative?

Just don't use it if you don't want to. I'm surprised this issue is open.

Not everyone uses your exact webpack + npm + babel + standard + "whatever else has been released this week" stack. Bower is okay for some people. I use npm but it is far from perfect.

Olical commented Jun 9, 2016

Dear Bram Moolenaar, I know you've been working on Vim for 28 years, but Neovim has more features than Vim now. So stop working on Vim, please.

Let's apply this logic to Linux distributions, JavaScript UI libraries or web frameworks in any language. Why on Earth would a project deprecate themselves because someone on the internet prefers an alternative?

Just don't use it if you don't want to. I'm surprised this issue is open.

Not everyone uses your exact webpack + npm + babel + standard + "whatever else has been released this week" stack. Bower is okay for some people. I use npm but it is far from perfect.

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders Jun 9, 2016

Webpack, babel, etc aside, Bower installs packages. That's it. It does not do anything npm doesn't do. Instead of doing <script src="bower_components/angular/dist/angular.min.js"></script> do <script src="node_modules/angular/dist/angular.min.js"></script>.

Bower truly is irrelevant and an inferior product. Not to mention you need to use npm to install bower already, so why not skip the extra dependency and headache?

joshmanders commented Jun 9, 2016

Webpack, babel, etc aside, Bower installs packages. That's it. It does not do anything npm doesn't do. Instead of doing <script src="bower_components/angular/dist/angular.min.js"></script> do <script src="node_modules/angular/dist/angular.min.js"></script>.

Bower truly is irrelevant and an inferior product. Not to mention you need to use npm to install bower already, so why not skip the extra dependency and headache?

@Pierstoval

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval Jun 9, 2016

  1. Deprecate bower, re-think NPM
  2. Force it to resolve dependencies properly like Composer does
  3. Break all projects using NPM
  4. Break the web
  5. Endure frontend/nodejs devs committing suicide in groups
  6. Enjoy a good Javascript workflow

Pierstoval commented Jun 9, 2016

  1. Deprecate bower, re-think NPM
  2. Force it to resolve dependencies properly like Composer does
  3. Break all projects using NPM
  4. Break the web
  5. Endure frontend/nodejs devs committing suicide in groups
  6. Enjoy a good Javascript workflow
@ashclarke

This comment has been minimized.

Show comment
Hide comment
@ashclarke

ashclarke Jun 9, 2016

Now:

NPM is 'newer' and 'better', you should use that. Everyone on the old package manager should upgrade.

In 3 4 months:

New Awesome Package Manager is 'newer' and 'better'; you should use that. Everyone on the old package manager should upgrade.

Welcome to JS development. It's safer here.

Edit: Reflect recent events.

ashclarke commented Jun 9, 2016

Now:

NPM is 'newer' and 'better', you should use that. Everyone on the old package manager should upgrade.

In 3 4 months:

New Awesome Package Manager is 'newer' and 'better'; you should use that. Everyone on the old package manager should upgrade.

Welcome to JS development. It's safer here.

Edit: Reflect recent events.

@ashclarke

This comment has been minimized.

Show comment
Hide comment
@ashclarke

ashclarke Jun 9, 2016

Also, this is the worst reason for a deprecation.

for the greater good of the Web/JavaScript community as a whole.

There are many companies and users, using bower, who are quite happy with their workflow. The web and the JavaScript community are not affected by this. Why force your "superior" workflow on others if they are happy with what they have?

ashclarke commented Jun 9, 2016

Also, this is the worst reason for a deprecation.

for the greater good of the Web/JavaScript community as a whole.

There are many companies and users, using bower, who are quite happy with their workflow. The web and the JavaScript community are not affected by this. Why force your "superior" workflow on others if they are happy with what they have?

@Mparaiso

This comment has been minimized.

Show comment
Hide comment
@Mparaiso

Mparaiso Jun 9, 2016

Bower user here , I strongly disagree with the author of this issue. I don't want to use NPM/Webpack whatever to manage my front-end dependencies. I'm happy with Bower and I'll stick to that. Imagine someone going on Grunt issue tracker and tell the Grunt team "Consider deprecating Grunt in favor of Gulp". That would be extremely arrogant ,and that's how the OP's message feels like. arrogant.

Mparaiso commented Jun 9, 2016

Bower user here , I strongly disagree with the author of this issue. I don't want to use NPM/Webpack whatever to manage my front-end dependencies. I'm happy with Bower and I'll stick to that. Imagine someone going on Grunt issue tracker and tell the Grunt team "Consider deprecating Grunt in favor of Gulp". That would be extremely arrogant ,and that's how the OP's message feels like. arrogant.

@ansuz

This comment has been minimized.

Show comment
Hide comment
@ansuz

ansuz Jun 9, 2016

troll OP is trolling.

everybody stop now.

go outside and enjoy the sun.

plz.

ansuz commented Jun 9, 2016

troll OP is trolling.

everybody stop now.

go outside and enjoy the sun.

plz.

@Pierstoval

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval Mar 29, 2017

@pedrosanta After more than half a year of this topic, I think everyone have been moving to webpack or something similar 😆

Pierstoval commented Mar 29, 2017

@pedrosanta After more than half a year of this topic, I think everyone have been moving to webpack or something similar 😆

@DaSchTour

This comment has been minimized.

Show comment
Hide comment
@DaSchTour

DaSchTour Mar 29, 2017

@Pierstoval just a matter of time and webpack will have a "Consider deprecating webpack" issue 🤣
But I really wonder who this everyone is. I'm quite sure there is a silent crowd of developers that don't care about this meta discussion and just use what's best for their current project needs.

DaSchTour commented Mar 29, 2017

@Pierstoval just a matter of time and webpack will have a "Consider deprecating webpack" issue 🤣
But I really wonder who this everyone is. I'm quite sure there is a silent crowd of developers that don't care about this meta discussion and just use what's best for their current project needs.

@Pierstoval

This comment has been minimized.

Show comment
Hide comment
@Pierstoval

Pierstoval Mar 29, 2017

I agree, I personally prefer to be stuck with gulp for classic projects, and gulp + browserify when dealing with ES6 browser-side, and everyone has its own preferences

Pierstoval commented Mar 29, 2017

I agree, I personally prefer to be stuck with gulp for classic projects, and gulp + browserify when dealing with ES6 browser-side, and everyone has its own preferences

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders Mar 29, 2017

How does one move from Bower to Webpack? I can't find the "Install modules" section in Webpack docs.

joshmanders commented Mar 29, 2017

How does one move from Bower to Webpack? I can't find the "Install modules" section in Webpack docs.

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert Mar 29, 2017

Contributor

@joshmanders try to stay on topic please

Contributor

graingert commented Mar 29, 2017

@joshmanders try to stay on topic please

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders Mar 29, 2017

@graingert how am I not on topic? I'm asking a question regarding why people actually think that moving from Bower to Webpack is feasible... They're two separate things. It's like saying "Most people have moved from eating grapes to throwing balloons at squirrels." when talking about what food to eat.

joshmanders commented Mar 29, 2017

@graingert how am I not on topic? I'm asking a question regarding why people actually think that moving from Bower to Webpack is feasible... They're two separate things. It's like saying "Most people have moved from eating grapes to throwing balloons at squirrels." when talking about what food to eat.

@graingert

This comment has been minimized.

Show comment
Hide comment
Contributor

graingert commented Mar 29, 2017

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders Mar 29, 2017

You cannot move from Bower to Gulp, or Webpack. Bower is a package manager. Gulp is a task runner. Webpack is a bundler. All 3 are wildly different things and do different things. You can move from Bower to npm. You can move from Bower to Yarn. But you cannot install packages with Webpack or Gulp.

joshmanders commented Mar 29, 2017

You cannot move from Bower to Gulp, or Webpack. Bower is a package manager. Gulp is a task runner. Webpack is a bundler. All 3 are wildly different things and do different things. You can move from Bower to npm. You can move from Bower to Yarn. But you cannot install packages with Webpack or Gulp.

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders Mar 29, 2017

@graingert Show me in those docs where you can install say express framework using webpack itself. I'll wait here.

joshmanders commented Mar 29, 2017

@graingert Show me in those docs where you can install say express framework using webpack itself. I'll wait here.

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert Mar 29, 2017

Contributor

Bower is built as a small step up from pasting URLs from cdns directly into your html, as @pedrosanta bemoans :

Really enjoyed the simplicity of bower and its focus on front-end and on off the shelf, ready to use JS/libs

@Piestoval's reply:

After more than half a year of this topic, I think everyone have been moving to webpack or something similar 😆

This is framing webpack not as a solution for simple off the shelf packaging, but as a tool to go beyond the need for prebuilt libraries

Contributor

graingert commented Mar 29, 2017

Bower is built as a small step up from pasting URLs from cdns directly into your html, as @pedrosanta bemoans :

Really enjoyed the simplicity of bower and its focus on front-end and on off the shelf, ready to use JS/libs

@Piestoval's reply:

After more than half a year of this topic, I think everyone have been moving to webpack or something similar 😆

This is framing webpack not as a solution for simple off the shelf packaging, but as a tool to go beyond the need for prebuilt libraries

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders Mar 29, 2017

@graingert try to stay on topic please

joshmanders commented Mar 29, 2017

@graingert try to stay on topic please

@calidion

This comment has been minimized.

Show comment
Hide comment
@calidion

calidion Mar 29, 2017

Member

I think this topic should be locked now.
It is meanless to argue if someone should choose one thing from another or force someone to obey someone else's choice.
At least, we are free to choose.

@sheerun

Member

calidion commented Mar 29, 2017

I think this topic should be locked now.
It is meanless to argue if someone should choose one thing from another or force someone to obey someone else's choice.
At least, we are free to choose.

@sheerun

@ashclarke

This comment has been minimized.

Show comment
Hide comment
@ashclarke

ashclarke Mar 29, 2017

@calidion - Completely agree. Just because individual user x uses npm, yarn, webpack, or whatever other tool, doesn't mean there aren't other users and companies that have invested in the use of bower.

ashclarke commented Mar 29, 2017

@calidion - Completely agree. Just because individual user x uses npm, yarn, webpack, or whatever other tool, doesn't mean there aren't other users and companies that have invested in the use of bower.

@pedrosanta

This comment has been minimized.

Show comment
Hide comment
@pedrosanta

pedrosanta Mar 29, 2017

@Pierstoval cool. I think I'll go with http://duojs.org. Their heart seems to be in the right place. Cheers!

pedrosanta commented Mar 29, 2017

@Pierstoval cool. I think I'll go with http://duojs.org. Their heart seems to be in the right place. Cheers!

@hardhub

This comment has been minimized.

Show comment
Hide comment
@hardhub

hardhub May 11, 2017

What is about not node developers? For example .net world? VS supports bower packages out of box...

hardhub commented May 11, 2017

What is about not node developers? For example .net world? VS supports bower packages out of box...

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders May 11, 2017

Pretty sure it supports npm too.

joshmanders commented May 11, 2017

Pretty sure it supports npm too.

@hardhub

This comment has been minimized.

Show comment
Hide comment
@hardhub

hardhub May 11, 2017

@joshmanders

Pretty sure not of out box... For example in my VS it is absent... It is VS2017 with all latest updates.
What I am doing wrong?

hardhub commented May 11, 2017

@joshmanders

Pretty sure not of out box... For example in my VS it is absent... It is VS2017 with all latest updates.
What I am doing wrong?

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders commented May 11, 2017

@hardhub Using Bower.

@cosmin-nicula

This comment has been minimized.

Show comment
Hide comment
@cosmin-nicula

cosmin-nicula May 19, 2017

Guys, what is this suppose to mean on your first page "...psst! While Bower is maintained, we recommend yarn and webpack for new front-end projects!" ?

bower-yarn-webpack

cosmin-nicula commented May 19, 2017

Guys, what is this suppose to mean on your first page "...psst! While Bower is maintained, we recommend yarn and webpack for new front-end projects!" ?

bower-yarn-webpack

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert May 19, 2017

Contributor

@trusktr looks like it's time to close this issue!

Contributor

graingert commented May 19, 2017

@trusktr looks like it's time to close this issue!

@capaj

This comment has been minimized.

Show comment
Hide comment
@capaj

capaj May 19, 2017

@graingert I would expect for bower to be deprecated on npm as well using https://docs.npmjs.com/cli/deprecate so that any one who installs it gets the warning too.

capaj commented May 19, 2017

@graingert I would expect for bower to be deprecated on npm as well using https://docs.npmjs.com/cli/deprecate so that any one who installs it gets the warning too.

graingert added a commit to graingert/bower that referenced this issue May 19, 2017

@graingert

This comment has been minimized.

Show comment
Hide comment
@graingert

graingert May 19, 2017

Contributor

@capaj yeah added a PR with that recommendation

Contributor

graingert commented May 19, 2017

@capaj yeah added a PR with that recommendation

@joshmanders

This comment has been minimized.

Show comment
Hide comment
@joshmanders

joshmanders commented May 19, 2017

@pedrosanta

This comment has been minimized.

Show comment
Hide comment
@pedrosanta

pedrosanta May 19, 2017

Still feel like bower leaves a certain void.

So that's it, the project is done for?

pedrosanta commented May 19, 2017

Still feel like bower leaves a certain void.

So that's it, the project is done for?

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun May 19, 2017

Contributor

@capaj Good idea, I've included the notice in both readme and npm deprecate

I think I'll close this issue now. Please keep in mind that even I don't have much free time, I'll maintain and keep Bower alive, so all current projects that use Bower, will continue to work.

Not to say I'd block anyone if she/he wanted to to take some extra responsibility for Bower's future (i.e. maintaining/developing it). If you feel like so, please e-mail me at: sheerun@sher.pl

If you'd like to discuss something else publicly, please open another issue, this one is a mess.

Contributor

sheerun commented May 19, 2017

@capaj Good idea, I've included the notice in both readme and npm deprecate

I think I'll close this issue now. Please keep in mind that even I don't have much free time, I'll maintain and keep Bower alive, so all current projects that use Bower, will continue to work.

Not to say I'd block anyone if she/he wanted to to take some extra responsibility for Bower's future (i.e. maintaining/developing it). If you feel like so, please e-mail me at: sheerun@sher.pl

If you'd like to discuss something else publicly, please open another issue, this one is a mess.

@sheerun sheerun closed this May 19, 2017

@bower bower locked and limited conversation to collaborators May 19, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.