Bower

» see bower.io as it lived, on the wayback machine

~ the eulogy ~

bower was in my project setup around 2014. i had a bower.json file alongside the package.json. the bower one tracked jquery and a few small css libraries i had pulled off github. the npm one tracked node tools. that split made sense for about eighteen months. then it stopped making sense.

bower was developed at twitter and released as 1.0 on september 21 2012. it was designed to do one thing well, install front-end javascript and css libraries into your project from git or a registry. it shipped with a flat dependency tree. that flat-tree decision was the technical bet, because front-end code does not tolerate two versions of jquery living next to each other the way two versions of a node module can. bower made the user resolve version conflicts. for a couple of years that felt clean.

the bower team posted a deprecation hint inside the npm warning when you installed bower 1.8.0 on june 5 2017. the official "use yarn and webpack instead" message went up on bower.io in october 2017. the project is still maintained in a minimal sense. nobody recommends it, and nobody starts a new project with it.

~ the dossier ~

~ what it actually did ~

you ran bower install jquery, and bower would clone the jquery github repo into a bower_components folder. it added the version to your bower.json. you committed bower.json to git. anyone cloning the project ran bower install and got the same dependencies pinned at the same versions. that was the whole pitch. it worked.

the part that aged badly was that bower had no real build step. you got the files into your project and then you still had to figure out how to concat and minify them. people used grunt for that. some used gulp or hand-written shell scripts instead. the workflow had bower for fetch and grunt for build, with the seams between them being the friction.

~ what killed it ~

npm decided to be a front-end package manager too. webpack arrived in 2012, the same year as bower, and over the next four years pulled the build-tool job into a single workflow that worked from package.json. yarn arrived in october 2016 as facebook's response to npm's slow install times. by mid-2017 the package.json plus webpack stack handled every job bower had been doing, with one config file instead of two. the bower team looked at this and made the honest call.

~ the inheritance ~

bower's actual legacy is the flat dependency tree convention for front-end packages. yarn shipped a flat-mode resolver and pnpm has one too. even npm eventually added overrides for collapsing duplicate transitive deps. the second legacy is the simple committable manifest format with semver ranges, which package.json had earlier but bower normalized for the css-and-html side of the stack. by the time bower was deprecated those ideas had been absorbed everywhere. that is what successful tools look like when they die well.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »