Bower may be dying!

[bitcrazed]

Looks like Bower may well becoming a victim of its success!

I stumbled across this after following a twitter comment, but it looks as though there are few/no active core members in the Bower project!

Original comment by @mjackson): reduxjs/redux#944 (comment).

Refers to following discussion with last active bower core member (@sheerun): bower/bower#1748 (comment)

Could taking a dependency on Bower become a problem for ASP.NET 5+?

[Eilon]

@DamianEdwards @rustd @madskristensen ?

[nkpz]

There is some information about this in 1748 that seems to contradict that bower has completely stopped development (as claimed in the popular tweet), but I think a brief statement from the creator for all the knee-jerk responses would be helpful, because understanding the situation requires reading a few paragraphs right now.

TLDR unofficial assessment of the situation until that happens: bower is currently maintained by one unpaid individual and this is a real problem, but the project is seeking funding, which may keep things active.

[mjackson]

Just wanted to chime in here and say that I have zero skin in this game. I
gain nothing if bower dies, except perhaps the freedom from having to
support such a poorly conceived tool in the open source work that I do.

If you guys are looking for a package manager for JavaScript, I'd suggest
either using npm or jspm.

On Fri, Nov 13, 2015 at 1:36 PM Nick Perez [email protected] wrote:

There is some information about this in 1748 that seems to contradict that
bower has completely stopped development (as claimed in the popular tweet),
but I think a brief statement for all the knee-jerk responses would be
helpful, because understanding the situation requires reading a few
paragraphs right now.

TLDR unofficial assessment of the situation: bower is currently maintained
by one unpaid individual and this is a real problem, but the project is
seeking funding, which may keep things active.

—
Reply to this email directly or view it on GitHub
#1074 (comment).

[poke]

Could taking a dependency on Bower become a problem for ASP.NET 5+?

I don’t see a dependency on Bower in ASP.NET 5. Yes, the default web template comes with some Bower stuff, but that’s about it. You can absolutely set up projects without ever touching Bower. As an example, the project I’m currently working on has a custom build process that takes JavaScript dependencies via npm, has user code in TypeScript, and builds everything using gulp.

[sheerun]

Thank you for your concern, but Bower is not dying. It is stable software, and we've got extra volunteers.

Bower has no Creator, it's a community effort.

Of course there are people who would "donate money to help remove bower from the js community" as someone recently said to me. Maybe little help with making it even more stable, and easing the transition?

If you think you can implement Bower in NPM, do it. I'd be really happy to get a drop-in solution. Really.

[atrauzzi]

I've seen an increasing move away from Bower over the last year to just using NPM to manage packages for the front-end side of things.

I'd suggest using either JSPM, or WebPack+NPM. They seem to be where the community is focusing right now. The advantage of both is that if ASP.NET scaffolds it correclty, you can bundle TypeScript support in every new ASP.NET project!

[atrauzzi]

Worthwhile read, ca. 2014: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

[Eilon]

BTW as others have mentioned here, ASP.NET itself has no dependency on any JavaScript thing at all. It has some built-in providers for jQuery (that can be swapped out) and that's it.

ASP.NET project templates use Bower, and Grunt or Gulp (depending on how old a build you're using) but that's all just for convenience. No actual tie-in.

[tsvetomir]

Don't forget that the default project template is the reference point for many developers. Not all of them are going to come here and read this discussion.

[atrauzzi]

Yes, I think it's fairly important that people not be given bad advice. People tend to rally around defaults and asp.net could inadvertently create a pocket of developers using tools that are falling out of favour.

I must admit, bundling a front end stack seems like a battle you will always lose. Why not make it optional during scaffolding?

[pgrudzien12]

@Eilon It's not only templates but also build in support for Bower in VS (which in my opinion should be optional and designed as separate extension).

It was also my first impression that I should use Bower and that you recommend using it. I think that 90% of people, if not more, will use VS to develop ASP.NET applications so having "Manage Bower Packages" option somehow ties you to Bower whether you want it or not. I think that it's hard to distinguish between tooling and ASP.NET - see for example number of problems people had updating DNX version and but not knowing that they should update tooling (eg. http://stackoverflow.com/questions/33156090/getting-the-correct-dependencies-for-net-web-api-for-the-latest-net-core/33158692#comment54127039_33158692). Providing of course that you do not spend significant amount of your time on github.com/aspnet :)

[sheerun]

I also think built-in support is too much :)

[Eilon]

Ping @DamianEdwards

[bitcrazed]

ASP.NET itself has no dependency on any JavaScript thing at all

Perhaps not, but the meta-point raised by many here is that the default experience for dev's coming to ASP.NET 5 is that Bower is built-in to the initial templates and tooling experience.

I don't have a dog in this race, but am concerned that while Bower has provided some great features in the last few years, if the community is moving toward node instead, perhaps consolidating around node-based templates and tools may be a better option.

@atrauzzi summed it up nicely (emphasis mine):

I think it's fairly important that people not be given bad advice. People tend to rally around defaults and asp.net could inadvertently create a pocket of developers using tools that are falling out of favour.

[poke]

that Bower is built-in to the initial templates and tooling experience

Note that NPM is also built into it as a first citizen. And I doubt that anyone doing serious front end development will just use whatever the default template gives you. Since no web framework is built to work inside ASP.NET, no framework will have instructions to use it inside there, so I think it’s a lot more likely to expect that front end developers just start how they always started: In the command line, setting up their front end development process. And that then happens to integrate nicely into ASP.NET and VS without extra work.

[joshburgess]

Add another +1 for moving away from Bower in favor of npm. I'd also like to see default templates utilizing Webpack. It's been a bit difficult to figure out how to integrate Webpack & React in an ASP.NET Core project which serves up the index page via a single MVC HomeController... and pretty much everyone who uses React is using Webpack.

[atrauzzi]

@joshburgess - Webpack is a safe bet now, but things like JSPM which feature dependency management (not just building) are starting to shift things as well. It'll be bower all over again soon enough.

I think anything beyond shipping a package.json is probably risky. People should integrate their front end as they see fit.

[joshburgess]

Yes, I know SystemJS & JSPM are also popular with the Angular 2 / Aurelia crowds. Browserify is still fairly popular with a lot of people as well. Bower, however, is not really used by many people at all anymore.

If they offer any templates utilizing modern client-side dev tools, they should try to make them current... I'm hoping that a few different templates are made available showing how to best integrate with the most commonly used tools.

[ranbuch]

Looking forward for "ASP.NET Core Universal Starter repo" to get npm instead of bower . . .

[Eilon]

Closing because no further action is planned for this issue.