Bower is not dying: http://bower.io/blog/

I've already proposed a solution, but we'd need a sponsor or a crowdfunding campaign for it (Monterail has no resources): Create a gem that works like rails-assets, but allows to fetch files directly from GitHub.

As discussed before, we don't really see a bright future for rails-assets as the perfect solution to assets management in rails apps. As @jandudulski said, there are now much better tools for that.

Monterail will continue to support the current state of rails-assets including migration to new hosting.

Having said that, despite rails-assets was started by me and others (@sheerun, @porada) who were then part of Monterail's team, neither the company nor I claim to be the ultimate decision makers here. rails-assets is still an open source project and we are open to ideas and contributions from the community.

To put things straight:

• we (Monterail) want to support current functionality until the end of 2016
• we want to support some kind of read-only mode since the end of 2016
• we do not believe creating serverless rails-assets gem is the good way to go
• instead, we want to provide as many resources as possible for everyone to migrate to other tools

we do not believe creating serverless rails-assets gem is the good way to go

Could you please elaborate more on that? Why is it a bad idea?

To me, it is so convenient to use only one tool(bundler) to manage all dependencies. I probably would like to have a rake task gem for converting an asset to a gem.

If you take a look at https://github.com/rails-assets/rails-assets/tree/master/app/models/build you can see it is quite complex processing.
Then, here https://rails-assets.org/status you can see the various error that are not yet handler properly.
This is all due to fact that bower packages are extremely inconsistent.

The front-end stack has changed a lot in the last few years, we now finally have standard access to proper modules and code isolation in the browsers. In the same time, sprockets is (and probably will) be a simple tool for joining files together.

Tools like sprockets or rails-assets will always be a bit behind the JS world.

In our opinion rails-assets did it's job over the last 2,5 years, but it won't be needed soon since tools like npm/webpack are already doing a great job and there is no need for additional layers.

Hi,

I used rails-assets solution for 1 year. I'm agree with you it's not the perfect solution. Rails assets deals with javascript library and it's not an easy task. For me it's also the best solution I have found to get :

• packages up to date
• one package installer bundler
• not ask 30 owner of repositories to make an update of javascript libraries in the gem.

Perhaps the future is npm/webpack tools but they introduce also a new complexity in rails application.

If you guys think the Bower landscape is somehow bad try to install modules from NPM. Most of the time the module isn't even available on NPM. Not being on NPM means it doesn't use UMD, and you have to shim your shim so you can shim while you shim. It's a terrible place out their for front end devs. I was doing it full time for a year. Half the time you just do

window.$ = require('jquery')
require('jquery-ui/wtf-am-i-even-doing')

Or just copying javascript from a repo and plopping it in your project.

Gulp/Browserify/Webpack is cool for those just getting into programming and want to do everything manual. They want to sit around and engineer solutions just to engineer them. That's cool when you're 10 but when you grow up and get a real job you may have to do things. While most people are sitting around comparing their Gulp buildscript sizes, I'm trying to build stuff.

Rails assets solved a huge problem. We had those stupid ass wrapper gems, and it replaced them. It's a shame that the over engineered world of the front end has leaked over into this project.

I don't want to roll my own asset pipeline with Gulp because I like my free time.

I do think there is room for a browserify-rails which is a decent replacement for rails assets, since you use NPM. It's slow as molasses, but hey whatever can make a front end devs life harder, they'll be up for it.

All joking aside, I think work should go into Browserify rails to make it faster and detect file changes on save instead of browser reload. I don't think the future is to replace the entire asset pipeline. That means image/font management. Just replace the javascript piece.

Just to show how over engineering has reached new heights on the front end. Take a look at this.

https://www.airbnb.com/rooms/259576

Using react for static content on that page. Provides no interaction to user. It's just static.

This brand asset page for Uber.

http://brand.uber.com/

Probably have 1000 engineers twiddling their thumbs, so they create the most over engineered brand asset page of all time.

I don't have much to add in terms of substantive discussion here, but I wanted to drop in on the conversation in order to give some massive gratitude and ❤️ ❤️ ❤️ to everyone who's worked on rails-assets.

I know that the world of frontend development moves fast, and some of you might feel that rails-assets has been surpassed by npm, webpack, gulp, or whatever the latest and greatest is.

However, I'll just add that our team is extremely happy with rails-assets, and assuming that it stays online (or that we can stand up our own server), we'll be planning to use it well into 2016 and beyond.

I sometimes call myself "full-stack" but I'd consider myself as a 0.75-stack (0.5 backend, 0.25 frontend). Or, the projects I'm working on are not frontend-heavy. Hence I have less time to apply every new frontend tech I've heard of to the project at hand. Instead I find peace in moderate solutions like Rails Assets which, a) doesn't have the disadvantage of wrapper gems, and b) doesn't have the complexity of full-blown solutions like Gulp, Webpack etc.

So until the time new frontend mechanisms get really widespread, Rails Assets fills an important gap for me and I'd appreciate it if it continues to do so for the foreseeable future.

Totally agree with @halilim . Yeah, JS world moving fast, but for simple apps, which depend on simple, non-fancy-js-includes-requires libraries, this is a better way then old 'asset gems' like 'blablabla-rails'.

Maybe it's not ideal solution, but it's definitely filled the gap for us. So it's sad it may be closed.

@teamon, @sheerun, and/or @jandudulski, was there any resolution to this? Based on the lack of activity on the repo and this issue, it appears that this is on pace to fade away in March? Is that an accurate assessment?

@colbywhite Currently we are arranging a new hosting. As previously stated we will support the current state at least until the end of this year.

I'm not sure a lot of people know it's going to shut down. Seems to be quite a few people using it. I really love this service.

As @drewhamlett said I think this news could be more spread. A ticket in github is very specific, why not communicate on the front end services to get more reactions from end user : https://rails-assets.org/.

It might help to post something on the home page. Someone might be able to step in and offer hosting. What are the hosting needs?

I'm also a happy user of Rails assets. I haven't found the other solutions compelling enough to want to switch.

I would say that rails-assets fills an important niche, esp. in light of react-rails deciding to stay sprockets instead of using webpack, browserifying, etc. For better or worse, so long as rails stays on sprockets as default, gem based assets are going to be a thing long into the future.

What help can the community give?

I've been giving quit a bit of thought to the front end ecosystem lately. I think people are frustrated with the NPM ecosystem leaking into the Rails. It's pretty much the anti thesis of the Rails way. A lot of the .NET guys are feeling the same too. A new Web MVC project brings in NPM for all assets.

I think NPM is the future of front end but I think we can work with it. There are a lot of good projects coming out. React, Webpack, Babel, but the Rails community has made the configuration hell easier. For example react-rails. You can get Babel and ismorphic React setup in a few lines of code.

If we could manage NPM assets with the Gemfile as you do with rails-assets(bower), we would get locked dependencies by default. Another instance is changing sprockets to support require(or import). There's a lot of fragmentation going on in the JS world because developers just start a new projects instead of fixing the older stuff. I think in the Rails community we have a decent track record on rallying behind one project.

@drewhamlett, are you suggesting that the rails community should go away from bower and focus on integrating with npm? As in making an equivalent of this project, but one that focuses on npm?

@hut8 works - you can check if the payment has been processed frm me ;)

rails-assets is one of my most important tools, I surely will miss it. Personally i don't like get my hands dirty with tools like bower or npm ( which is the worst piece of software i ever seen ). Managing front end dependencies using bundler is a brilliant idea. I think rails-assets can continue its work and I love to see this happen.

Hey there @lxsameer . You don't need to miss it! I'm not sure if you read the entire thread since it's so long but rails-assets is definitely not going anywhere. It's sponsored by DigitalOcean, and myself and @joshjordan plan on supporting it indefinitely, certainly past the end of 2016. Feedback for our mirror at https://rails-assets.tenex.tech would be greatly appreciated.

@hut8 awesome. I'm very happy right now, Kudos to you guys.

Should this issue be closed with a recap comment? It appears that the new mirror will be the answer.

@colbywhite I believe this should be closed with a proper annotation about support option.

@teamon Can you comment about the domain? Are you satisfied with Tenex taking things from here?

Sorry for the radio silence!

About the domain - yes, definitely. Plus I think we can close this thread now.

I've created another issue #312 to track what's left to be done before March 31.

You should probably add message on rails-assets.org that people should use rails-assets.tenex.tech instead and not having to read this huge thread :)

Please edit the issue to include updated information on the top of the big thread

Another shout out for rails-assets. This worked today for this newbie. I hadn't been able to push to Heroku for a few weeks and decided I had to get it done. Read discussions about asset managers. Tried some things and decided to give rails-assets a go even though I may to make adjustments soon. It worked for me. Thanks and keep up the good work.

Used to have high hopes for https://github.com/half-pipe/half-pipe but I don't know what happened.

cc: @joefiorini

@dt1973 Thanks for the mention. I started the project but left the company where we were using it and went to a Python shop that obviously didn't have much need for it. I've also stopped using Grunt in favor of Webpack and other tools made for being a build solution. I'm happy to hand it off to someone if anyone wants to dust off the cobwebs and bring it into the modern age.

Webpack is the future boys

You know the future?!

The problem is, we haven't reached that future yet and we need a hassle-free asset management solution right now which doesn't change every six months :)

And when you are back from the future you enjoy using rails-assets which is awesome :)

https://rails-assets.org/ is down? :(
http://www.downforeveryoneorjustme.com/rails-assets.org

Down for me too

Webpack looks good, similar to a lot of others like babel etc. Will be
interesting to see if a single package manager is adopted

On Tue, May 10, 2016 at 9:47 AM, Roma Milushov notifications@github.com
wrote:

https://rails-assets.org/ is down? :(
http://www.downforeveryoneorjustme.com/rails-assets.org

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#291 (comment)

https://rails-assets.tenex.tech/ is down as well. Maybe they're doing the transfer they talked about ?

Or Maybe rails-assets.tenex.tech is suddenly being hit with a lots of requests!

If you have urgent deployments to do, you can vendor the gems:

bundle package

That way you'll have a vendor/cache folder created with every gem. You can commit / push that. Later on think of removing this commit (not just revert) as it grows your git repository a lot.

@ssaunier both URI point to the same server, see #329 (comment)

rails-assets.org is BACK!

@milushov @richpeck @kofronpi @ssaunier @sjauld thanks for the heads up. No transfer in progress - rails-assets.org is here to stay and shouldn't require any extra effort on your part. We weren't taking any more traffic than usual last night, and syslog isn't showing anything useful. Looks like we went hard down at 3:41AM. I'm following up with our hosting provider to get more info. Right now, we appear to be up and stable.