Echo JS 0.11.0

<~>

gotofritz 355 days ago. link 2 points
> Many developers consider Bower to be a thing of the past that is superseded by npm. .. But if your webapp is missing this compilation step, using Bower is a big improvement over the traditional methods of managing dependencies.

Except that nowhere in the article it explains what this supposed improvement is.

Quite simply, in 2016 bower is a waste of time.
MaxArt 355 days ago. link 2 points
"Also, you don’t need any other tools to manage dependencies."

That's funny, it's also the main reason why Bower is being replaced by npm.

Even if you don't use a bundler, you can still load scripts from node_modules. If you don't like the folder name, you can use a symlink or switch to Yarn.

"Using Bower separates the front-end dependencies from the others"

Does it even still make sense? And why should I care? Where should I put Lodash, among front-end or back-end dependencies? There's a lot of isomorphic/universal JavaScript around, it's not like it's still Angular here and Express there.
And what if I *do* use a bundler for the front-end? Would I be stuck with debowerify?


No, I don't think Bower is still relevant at all. The only thing I liked is that you can state the type of module you're creating (AMD, ES6, CJS...), but that's pretty much all.

The publishing workflow is quite awkward and too tied to cloud Git hosts like GitHub. You also have to tag your releases. What if I don't want to, or if I use Mercurial, or I don't use *anything at all* - just my bare hard disk?

I've published some of my packages to Bower too - the ones that make sense on the front-end, anyway - the it always felt like a chore to me more than actually giving a solid contribution.