Future of rails-assets

[jandudulski]

Hi all,

as you probably know rails-assets.org is currently hosted thanks to courtesy of ShellyCloud team but unfortunately they will shut down on March 31, 2016. There are at least two topics to discuss:

• where should we migrate?
• what should be the future of rails-assets?

  Migration

There is obvious deadline - March 31, 2016. Before that day we have to find hosting platform which would like to become a new home for rails-assets. We are going to contact with most known hosting platforms and ask for support but if you already know any which could help us - please leave a message.

Future

rails-assets was born to fulfill some needs - we didn't want to manually build and maintain gems for vendor libraries with assets. However, world moved forward and there are a lot of solid solutions which allow to get rid of rubygems environment and separate backend and fronted libraries in rails projects.

The last nail in the coffin is current state of bower and generally speaking - community movement from bower to npm based solutions. If you are not aware - rails-assets functionality base on bower packages.

Our current plan and proposal is to migrate rails-assets in its current form to the new platform and support it until end of 2016. After that we would like to migrate existing packages to kind of ftp so existing projects could still bundle but it won't work for packages which has not yet been transformed.

We are open for any comments, help offer and proposals.

[sheerun]

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

[sheerun]

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.

[teamon]

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

[ch1c0t]

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.

[teamon]

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.

[ldonnet]

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.

[drewhamlett]

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.

[drewhamlett]

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.

[ajb]

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 :heart: :heart: :heart: 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.

[halilim]

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.

[Gedrovits]

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.

[colbywhite]

@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?

[teamon]

@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.

[drewhamlett]

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.

[ldonnet]

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/.

[boone]

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.

[hayesgm]

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?

[drewhamlett]

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.

[colbywhite]

@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?

[bbraga]

https://rails-assets.org is down! Houston we have a problem

PS: Due to this I believe other external mirrors for assets would be a very nice to have, in case of catastrophic failure such as today

.

[bsbodden]

I for one hate dealing with NPM and found bower a much better route. Then finding rails assets made it seamless. Why rather than having a full-blown gem source/server we just keep a list of converted bower packages and push/publish them directly to rubygems.org?

[pauloschilling]

And rails-assets.org is down again right now, same as yesterday, "504 Gateway Timeout" from Shelly Cloud.

I truly believe you need to bring the future of rails-assets.org to the table, but what about the present? In the meantime, there's nothing you can do to make the current service more stable and reliable? I know you depend(ed) on Shelly Cloud's courtesy to host everything, but even if they had no plans to shutdown the service you should be considering doing something about it.

Talking about the tool itself, we already removed rails-assets from our most critical project, and now we are going to do the same to the last one. When you have dedicated front-end developers you'll want to avoid such tools, and start using gulp, bower, npm, grunt and so on, like @jandudulski said, and you'll end up with separated frontend and backend dependencies, which is really good.

Please, I really don't want to be rude, I just want to contribute with our thoughts and the internal decisions we have made regarding this.

Oh, and have you ever considered talking to someone behind bigger rails-related projects? Maybe one of them can help you either by offering the resources you need to keep the service online, or even by adopting it to integrate with their main service.

Also, I want to thank you for all the effort you had to make and keep rails-assets running, we really appreciate that!

[bsbodden]

On the meantime folks can use https://github.com/rharriso/bower-rails/, not as convenient but it'll do.

[drewhamlett]

@pauloschilling Using Grunt and Bower right now would be akin to Luke Skywalker Tauntauning a dead corpse to live in. I don't really mind Bower per say, but it seems NPM has won(for better or worse). I personally don't want dedicated front end people working for me. I hire full stack developers who are very good at Javascript. This tends to keep the app balanced, without the over engineering front end parasites(hint: I was one) trying to tackle every problem ever with a gigantic helping of shitty Javascript and flavor of the month frameworks.

Anyway, what I'm getting at, is not everyone has the resources to have dedicated front end engineers. People are fine(and like) using the asset pipeline and Bundler. We just need a good solution. I don't mind using NPM to manage dependencies but I don't want to manage my own asset pipeline. Sure I'd rather use Bundler, but it seems the front end world has leaked everywhere at this point. I really like the project https://github.com/browserify-rails/browserify-rails, it's just too slow for me at this point. Maybe the solution is to iterate on that and make it better.

@colbywhite : I think that's a possibility. It depends on if there's any interest in it. It can't just integrate NPM though. It would need to be an out of the box solution for managing NPM dependencies and wrapping Webpack or Browserify.

[mattbrictson]

I don't mind using NPM to manage dependencies but I don't want to manage my own asset pipeline.

@drewhamlett I agree 100%. Have you tried a little project called Torba? Its creator describes it as "Bundler for Sprockets". Uses NPM rather than Bower.

I just ported a small project from Rails Assets to Torba and it worked on the first try. Definitely promising!

[pauloschilling]

@drewhamlett, I agree with you, but different projects have different needs, and different countries have different people. Here in Brazil a full stack engineer normally don't have neither the knowledge nor the passion to maintain the frontend (read CSS, HTML, part of the JS), so we have to hire people "just" to do that in order to have a good UI/UX.

This is just a parentheses on why we ended up with dedicated frontend engineers, and at least in our case it was not a question of having resources (money) for it, but the real need to do that because people have different abilities here.

Anyway, I don't want to change the main topic, sorry about that, but I think this is also good to better understand what kind of projects and teams can take fully advantage from solutions like rails-assets, and the "full stack" thing probably is the key.

The "X is better or worse than Y" will always exist, and this is good as well, the key again is what is better for you and for projects like yours.

Is pretty clear that rails-assets is most recommended for full stack teams, and I hope they can find the right path to keep it running, no matter if there's a "better" tool or not.

Best,

[ajb]

A couple of thoughts:

• To the maintainers: @dobtco is willing to offer some level of financial sponsorship for hosting. Feel free to contact me via email to chat more about this. (You can find my address in my git logs or on my personal website.)
• To everyone else: hosting another instance of rails-assets shouldn't really be that hard. Maybe someone in the community can step up to offer a Dockerized version of the service that would be easy to deploy and maintain? I recently stood up an instance on my own, and while in some ways it's just a basic Rails app, there do seem to be a few tricks to getting everything running smoothly. Docker would make this part trivial.

[sheerun]

I can setup hosted version of Rails Assets on AWS and support it, if someone is interested.

I need to see it can profitable, so please fill this form: https://docs.google.com/a/sher.pl/forms/d/16EQ1FdInLOuEZ_E9Rt0pFy54QnLzKSw7JCVbDYewCTw/edit?usp=forms_home

[hut8]

@sheerun Google says that form is restricted.

I spent almost an entire night during this outage looking for a better alternative, and my findings were basically that the whole ecosystem of front end assets is somewhat of a mess. I think that this project is actually a really good solution even if it's not perfect. I would be happy to host it as long as I can afford it out of pocket. Can someone familiar with the current hosting please describe the resources used in terms of disk space, bandwidth, memory, etc? I want to price it out and maybe find some areas for optimization. I'm sure I can take this on by mid 2016.

[sheerun]

Currently it's 30 GB SSD, 600 GB traffic/month, but growing. I've updated the form link: https://docs.google.com/a/sher.pl/forms/d/16EQ1FdInLOuEZ_E9Rt0pFy54QnLzKSw7JCVbDYewCTw/edit?usp=forms_home

[rjhancock]

I've sent a message off to DigitalOcean as they work with non-profits and OS projects for either discounted/free hosting. Their $40/mo server should be able to handle it (60G SSD / 3T Bandwidth). I'd offer to pay for it myself but don't have the spare $40/mo right this second.

[hut8]

I just sent an email to @jandudulski offering to have my consultancy host (and more importantly support) it for free. I can definitely have this set up by next week.

[sheerun]

Hosting isn't most expensive part. Support is.

[rjhancock]

Support wise, not much I can do. But if the hosting is taken care of thats one less thing to worry about.

[sheerun]

@hut8 We can't pass hosting that easily, for security reasons. It would give your consultancy a power to change any package's contents. You can setup separate service though, if you want.

[joshjordan]

@sheerun I think @hut8 is offering hosting and support.

Can you explain the difference in security at the current host and the one being proposed?

[sheerun]

It's the same reason npm won't give some random agency a write access to all of their registry.

// or github to all of their public repositories

[joshjordan]

What is that reason, and how is it different for the current ownership?

[bsbodden]

Has anybody approach the Rubygems team directly? I wonder what their take on hosting asset gems is? I mean, nothing prevents somebody from using the Gem generation portion of the rails-assets app and simply publish the generated gems to rubygems. It would be nice if the bower search/request process was backed into RubyGems but of course that opens the door for them to have to do bower, npm, etc.

[themgt]

The way Phoenix (Elixir) uses Brunch.io seems much preferable, but unless/until someone ports similar functionality into Rails, rails-assets.org is will remain hugely useful.

I'd encourage a move to rails-assets.org being community-run and using easily deployable site mirrors - we at @pogodan would be happy to run one.

[stympy]

We at @honeybadger-io would be happy to help with hosting as well

[yannski]

At Scalingo https://scalingo.com/ we can help too.

[teamon]

Hi everyone and thanks for all your comments. I won't be able to answer all of them, but let me tackle at least few points here:

1. We do realize that rails-assets is useful for quite some people (including Monterail itself). We still use it in some of our projects and we do want to support it in the current form at least until the end of this year.
2. As already mentioned there are two topics here: the future (2017) and the present, but both are very tightly connected. Right now we are focusing on arranging new hosting. I'm extremely happy that so many of you offered their support with that - please let me get my head around it and I'll contact you each individually.
3. In terms of ownership - currently few people have access to production machines and that includes Shelly Cloud team, Adam, Jan, me and few other Monterail developers. In theory, we could mess with the packages, but this would be a rather suicidal path for the individuals and Monterail in the ruby on rails community. And it would be the same case with any other company that supports/hosts the project.
4. Before rails-assets was born, we wanted to automate the process of creating assets gems and push them to rubygems.org. One of the reasons we stopped that was to avoid pollution rubygems with all those gems. It could probably solve some of the performance issues, but I think we still can do better than this.
5. We definitely should let people know about the plan, preferably by some announcement on the home page. I'll try to get this done soon. (and I'm definitely willing to accept a PR if someone does this before me :) ) https://github.com/rails-assets/rails-assets/pull/308
6. Finally, I do understand your disappointment with the recent quality of the service and the plans for future. I hope we can sort this out together as a community and prove one of the most important foundations of open source software - one can pick up when the others have left.

[hut8]

I saw that the existing deployment-related stuff is (understandably) tightly coupled to ShellyCloud. I wrote Ansible and Capistrano scripts last night and have actually deployed this application on a subdomain of my own. There are a couple minor issues I haven't fixed yet (externally hosted fonts giving 403s, lack of installation in playbook for Sidekiq Upstart scripts, etc). My deployment also includes Let's Encrypt, which I found was really neat.

I'm also going to write a quick script to try to import the existing converted packages from https://rails-assets.org/components.json, mostly as a test.

[andrewsomething]

Hey all! Looks like you have a lot of good options for hosting; add DigitalOcean to the list of folks willing to pitch in. Reach out to us opensource@digitalocean.com if we can help.

[nhance]

Hey, I may be willing to sponsor this for @railsasaservice. Can you give me a sense of the monthly costs involved?

[hut8]

https://rails-assets.tenex.tech is up now. I'm loading all the components present in https://rails-assets.org/components.json so expect slowness, but I'm eager to hear some feedback.

[lubekpl]

@hut8 Can you provide instructions for deployment?

[justintanner]

First a huge thank you to everybody who worked on and is currently maintaining rails-assets. You have saved me precious development time.

Please consider continuing support for rails-assets beyond 2016. For rails apps that have a handful of javascript deps rails-assets is an elegant solution. The alternatives are very complex and over engineered.

Please reconsider abandoning rails-assets.

[jvanbaarsen]

@jandudulski What are your main concerns at the moment? The lack of contributors? Or the costs of the hosting? For the latter I have seen a lot of suggestions in this topic already (Digitalocean wants to chip in, so is Honeybadger).

If it is about contributors, what are the current pain points that need to be addressed? I'm sure we can come up with a new fresh set of contributors. If needed, I can free some of my time to help out in the transition period.

Would you be open to work with me and others to see if we can keep rails-assets alive and going? I'm sure we can find the community support it needs, without you having to sacrifice all of your freetime.