Sure if you need jQuery and maybe another plug in that's fine, you're at 3 files to be loaded then. 2 from cdn, the jquery and plugin, plus one from your server.
For a web application however it's likely to contain many many more resources, backbone, marionette, jquery, handlebars. Those aren't great examples because NPM handles those just fine, and the discussion is concerning bower.
NPM billed itself as javascript primarily and never tried to sell itself to front end developers. Not terribly hard, it was definitely for node development. It was almost literally a branding issue. I think another big problem was the continued separation of concerns employed by most node developers. They tend to keep their front end/client side code in one directory bunched up together such as `/assets` or `/client` and then use the the rest of the project structure for their models directory, controllers, etc.
A real back end system requires this complex set up while there has been a long trend of front end being as light weight as possible while providing as interactive an experience as possible.
With the continued rise of SPA's though the front end is now easily as complex as the back end, and in fact shares a lot of the same logic. With build tools like GulpJS it's possible to fix this structural issue and now keep your code more logically grouped by function, group all of your users files, all of your messages files together and then concatenate and minify your client into a single file for production.
Anyways, so for a SPA you'll end up with a ton more dependencies, both css and js files. Bower billed itself for this purpose. Their branding and singular purpose made thing far easier.
I also prefer bower because it has a significantly better search and sort method in comparison to npm.
Sure if you need jQuery and maybe another plug in that's fine, you're at 3 files to be loaded then. 2 from cdn, the jquery and plugin, plus one from your server.
For a web application however it's likely to contain many many more resources, backbone, marionette, jquery, handlebars. Those aren't great examples because NPM handles those just fine, and the discussion is concerning bower.
NPM billed itself as javascript primarily and never tried to sell itself to front end developers. Not terribly hard, it was definitely for node development. It was almost literally a branding issue. I think another big problem was the continued separation of concerns employed by most node developers. They tend to keep their front end/client side code in one directory bunched up together such as `/assets` or `/client` and then use the the rest of the project structure for their models directory, controllers, etc.
A real back end system requires this complex set up while there has been a long trend of front end being as light weight as possible while providing as interactive an experience as possible.
With the continued rise of SPA's though the front end is now easily as complex as the back end, and in fact shares a lot of the same logic. With build tools like GulpJS it's possible to fix this structural issue and now keep your code more logically grouped by function, group all of your users files, all of your messages files together and then concatenate and minify your client into a single file for production.
Anyways, so for a SPA you'll end up with a ton more dependencies, both css and js files. Bower billed itself for this purpose. Their branding and singular purpose made thing far easier.
I also prefer bower because it has a significantly better search and sort method in comparison to npm.