There is no real ‘build-and-deliver’ safety net that Java apps have in Maven with the central repo.
CDNs and library locations can go down (the npm central registry has gone down like GitHub has). Bower can download web dependencies and npm can download build dependencies, and as unpleasant as it is, checking them in to source control ensures that everyone on the team has exactly the same code.
This also has the advantage that you don’t need to access a CDN when running builds or unit tests.
You may want to use a concatenation tool like browserify or require.js – this concatenates and minifies your code and the frameworks to a tiny little file, but allows you to develop with the fully expanded source.
~/.m2/repository if we want to have more reliable and cleaner builds, and then a server like Nexus/Artifactory to cache those libraries in the enterprise.
or Not To Bower
- A browser can cache libraries across apps
- There’s no third-party clutter in an application’s source code.
If the source map on the CDN doesn’t work, it’s easy enough to flip between minified and expanded CDN URLs when the time comes to debug. And consider how much a project is streamlined — an empty Angular site generated using NPM, Bower, and Angular-Seed or Yeoman puts upwards of 7,000 files into the project directory before a single line of application code is written.
Now there’s some fine print:
- It may be easier to emit a new project with these tools and then go clean up the initial code, replacing local links with CDN links and removing the unneeded source downloads.
- And enterprises may want to run their own “CDN” server with approved versions of various libraries. This can be a simple Web server, but it would be nice if a better tool existed to manage it.
CDNs are fine for small projects or libraries hosted by massive providers. But who wants to tie your uptime to somebody else’s infrastructure? Should it be your responsibility to find out whether some random CDN is stable enough?
Bower keeps the code locally even if you don’t check it into version control. For development a
bower.json file is enough. Bower doesn’t support repeatable build like Maven, so you may want to check in your dependencies for releases. (There are similar issues with Ruby gems, and you may want to check in your CDN dependencies so your tests can run offline.)
You can also run your own Bower server for all the same reasons you’d run Nexus.
There are other benefits to Bower too:
- Bower will download dependencies. (For instance, downloading bootstrap will also download jQuery.)
- Bower can use a manifest of the requirements, so other developers can “
- Bower lets you easily search and install libraries even locking to a specific version. Bower makes it easy to list and update dependencies.
Now unlike Maven, Bower is just a package manager — you still need something like Grunt to build. Grunt is useful for automation, minification etc.
or Not To Bower
The issue with CDN uptime is true. If you don’t feel that CDNs are reliable enough, either you run your own or download and bundle all the files you need.
On Bower, though, it has to be one way or the other. If it’s not reliable and repeatable enough to always give you the same code for the same config, then you can’t just check in your
bower.json because each of your developers and CI boxes may get different library code for that same Bower config file. And if GitHub isn’t reliable enough to be a CDN during a test run, why is it reliable enough for Bower to download code from for a test run?