What is Reddit's opinion of Bower?

From 3.5 billion Reddit comments

My suggestion - don't install front-end packages with composer. Use Bower. It's not very difficult to learn and you can install packages directly into the folder you specify.

This video tutorial is useful if you want to get started - http://www.youtube.com/watch?v=Vs2wduoN9Ws.

There's been a lot of fud about bower recently. I'm undecided about this but it's good to talk about.

Bower isn't dead. http://bower.io/blog/2015/bower-alive-looking-contributors/. Something was published recently that said the project was dead, but it's not.

I have concerns about only using npm and I think it boils down to two issues, mainly.

First, in the server I don't like the idea of mixing my node modules with my web modules. npm does a good job with "npm list" about identifying unused dependencies by tracking modules that haven't been required. Unless I'm mistaken, dropping web components into package.json is going I show them as extraneous. This is going to make it very messy to know when/if a module is being used or not.

Second, I'm really against the idea of bundling all the js into a single file. I'm not too concerned about multiple copies of big files, but rather the lack of control. A well architected app should be pretty modular. Part of that includes only loading the resources you need when they're needed. A modern web app can potentially use hundreds of kb of javascript. But if my mobile users are on a slow connection, they only need to get the minimal js initially to start the page. If they have to download 300kb first, that might be 5-10 seconds before they can use the app. That's just unexceptable. With gulp or other build system, I am able to package up my js and deliver it as needed.

Two things I really want to see in place with using npm are:

1) Have a web_modules path along with node_modules. That way everything uses npm, but there's a clear separation of concerns.

2) Using browserify, webpack, or whatever, retain control over how things are packaged for delivery to the browser. This may already be possible but I haven't looked at it yet.

for css dependencies i'd recommend bower. its become preferred and most popular pkg manager for clientside assets in most web environments.

http://bower.io/ - typically, tracking 3rd party assets in git is not preferred and instead streamlined into a custom deploy process.

using a package manager like bower would be an excellent way to make sure you had the correct or locked version of your css framework at any point in deployment process and alleviate it from your git flow which should be used to track code revisions (not asset installs though some could argue this point)

Not that I know of. You can check http://bower.io/search for a package-manager style list.

Let me touch on something else, though. Any developer worth their salt will have tools and components that they likely already know and use. If you're non-tech, leave some choices to the developer and don't try to dictate every single choice they make. Developing to someone else's spec often leads to problems when they try to make too many choices.

By all means, if you have preferences such as bootstrap, mention that when you're hiring the person. Creating an app is not as simple as just finding components and having a developer 'piece it together'. Development isn't some magic process, it takes a lot of problem solving, decision making, and good ol' hard work to develop stuff. Good luck!

TL;DR Let the developer choose which components best fit.

The closest thing people have mentioned so far is Bower, but I'm just starting to look at it. It seems like a language package manager at first glance (like npm or pip), but under the covers it can do a lot of generic fetching.

There's also repo and gclient both from Google, but I get the impression that folks who have to use those don't like them very much.

Have you tried using Bower? it is a package manager and it uses git to retrieve the code, it won't write the .git folder so you're not cloning a repo.

You can also ignore folders or files from the repo you're getting the package from. Usually it installs to bower_components folder, but you can change that.

Here you can get a repo via bower (downloads it directly, no subfolder)

bower install :MYUSERNAME/MYREPO.git --config.directory=./

A potential drawback is that bower won't work with https, you can try a solution like this or you can stay with the git protocol.

If you do a great boilerplate you should package it as a proper bower package.

Whatever you choose you'll need a bower.json file.

Check the docs here -> http://bower.io/docs/creating-packages/

Cool! I'll look through the source and see if there are any super un idiomatic js things

Might want to look into publishing it to npm's registry. It's basically the go-to package manager for JS libraries.

Also bower http://bower.io/

Not entirely sure what you want, but perhaps you want bower, which can be integrated into a rails project with bower-rails

I have not used bower with rails myself.

Bower is a package manager http://bower.io/

Which means it helps automate the process of installing scripts/libraries/frameworks.

Projects thing is straight forward sub domains. If you have a CPanel host, it should be under the domains section.

Yeah, google does some checking of the file, you might be screwed on that one.

http://stackoverflow.com/questions/9512919/getting-around-chromes-malicious-file-warning

From that page :

>The solution I found was to sign up to Google Webmaster Tools and add my site. It took several days for Google to crawl my site, and fill in any information, but I went back today and finally found loads of information there.

I love the plugin. I was just searching for a notification library to use on a project. It'd be great if you registered iGrowl with bower once it's released so we can get nice, easy installs.

My simple setup around bower in the js file is

// file .bowerrc

{

"directory": "lib"

}

// file bower.json

{

"name": "yourproject",

"version": "0.0.0",

"authors": [

"Your Name <>"

],

"description": "js dependency management for django-classic ui",

"dependencies": { }

}

then you just install new libraries with

bower install jquery --save

(don't forget the --save)

and bower will automatically take care about the dependencies

> and it'll find any new version of all your installed libraries, downloads and installs the latest ones for you. You can even install Haxe libraries from their git repos!

You should look into Bower it does a similar thing, but can be used for a lot of different kinds of libraries on GitHub. You can also specify a version or version range to ensure that updates to the API don't break your project (ie: 1.2.3 or 1.2.*).

That depends entirely on what kind of assets you mean? For PHP libraries there is Composer, for node modules and Javascript libraries there is npm, for front-end assets (such as Bootstrap) there is Bower. Each language tends to have one or two popular package management programs accompanying it.

npm: benefit is that if you're already using it then you only need to have one package manager to worry about.

jspm: benefit is that it integrates with systemjs which is built on top of the es6 module loader polyfill, which is staying on top of how ECMAScript is going to do module loading. Another benefit is that it can load modules from npm's registry or github.

bower: no benefit really at this point that I can see. Maybe you can expand on that. One downside is it seems like development has been a little troubled lately http://bower.io/blog/2015/bower-alive-looking-contributors/

Bower. Its stated purpose is to be for the frontend what npm is for the backend.

I really don't understand where all this hate for it is coming from. It is - today - the recommended package manager for jQuery, React, Angular - pretty much every popular front-end package.

Where did you see this? I looked at http://bower.io/ but there is nothing there about Bower no longer being actively developed.

Looking at twitter: https://twitter.com/bower, the last tweet was five days ago about the docs being updated.

And nothing on https://github.com/bower/bower about it no longer being developed. The last commit was one months ago but that doesn't mean it's not being developed.

Where did the devs say to just use npm instead? I want to know as I am proposing dropping bower entirely for a group of projects we are working on.

> Just like the title says. I see all of these different methods but have no idea what they all mean. I did the download but don't know where to put the un-zipped folder. Does it just go in my project/site folder? Or can I just use the CDN references? I'm not sure which would suit me best.

You could use the CDN, you could use the .zip file, or you could use bower to install it. Here's a breakdown:

• CDN: You link to the off-server stylesheet. This costs time/resources to download and render, however should always be the latest build of the framework. Best for testing and small sites. (That's my own understanding; I'm somewhat new to the more technical aspects of webdev)

• UnZipped Folder: The latest compiled build of Bootstrap; it's basically a static version of the framework. Less timestamp on downloading, but more or less same render time. Use a <link> with the relative path as the href attribute to successfully link the stylesheet.

• Bower: Probably the best method for staying up-to-date and keeping resources local. Simple install, you keep the Bootstrap files local, all in your bower_components folder; this way you just have to run $ bower update in your CLI to keep things fresh. (If you don't have/know about Bower, check it out here)

> I plan on customizing the style of the different elements in CSS but would that still be possible using the CDN method?

It is! Just make sure you manage your CSS specificity and, more importantly, ensure your own stylesheet is loaded after the Bootstrap file. The only difference between a CDN and local CSS doc is that you don't get to actually change the individual code in the files. (still allows you to override said styles.)

Hope this helps!

for front-end libraries you could use bower: http://bower.io/

there is a plugin called "main-bower-files" https://github.com/ck86/main-bower-files that let you get the main files from the library... (you can use it with gulp)

npm i -g bower bower install semantic-ui

you can change bower's directory by creating a file called: .bowerrc at the folder where you're going to run bower from, and specify a path like: { "directory": "public/lib" }

bower init is similar to npm init, it will create a bower.json file and if you use "--save" on the cmdline it will save your libraries on that file.

so your jade file could be like: lib/semantic-ui/dist/semantic.css

Thank you. I had something like this in mind as well. Eventually I realized a tool to help me writing PHP in Jade would be more useful in the project I was working on, so I built another little tool called gum. Tiger was a reminder I didn't want to throw away so I gave it nicer clothes and put it out there. I published the project in bower too.

If these are all client-side assets (css, js, images) here's two options that might help.

Firstly, you could make a separate site (e.g. static.mydomain.edu) that hosts these files and have all of your microsites reference them. You change one asset file, you change all of the sites. A secondary benefit is that users keep the files cached in their browser across sites (rather than redownloading for each site). This is fairly simple (easy to put them into a repo, a bit of effort in editing each site to point to the new location).

Secondly, you could use a depencency tool like Bower. This is basically like Composer for front-end assets (if you've used that). This is a bit more involved - you create your assets repo and add a bower.json file that describes the package. Then you have to host it somewhere - like how Composer fetches packages from Packagist, Bower needs a repository too. You probably won't want to use the public repository (it sort of implies that your organisation's assets are available to use, perhaps they are?) so you'll need to setup a private repository. This blog lists a few options. Then, in each of your sites, create a bower.json file that references your assets package. When you update your assets package, you will have to update the assets in each of your sites (bower update or something).

The second option is far more involved, but if you use other components (Bootstrap, jQuery plugins) it's definitely helpful. However this might be a huge step if your organisation isn't used to VCSes. Personally, I would implement the first solution, get everyone used to VCS and then try to introduce the second.