[shimonamit]

An interesting tweet by Sam Saffron:

"@dhh this is just a bit too much https://github.com/rails/rails/blob/master/rails.gemspec#L28 … now every Rails install requires redis, eventmacine, celluloid and faye"

https://twitter.com/samsaffron/status/678701348297158657

[inopinatus]

Rails 5 is a bloat too far for my liking as well. ActionCable's dependency on redis is too fat a pill to swallow, especially given that some of the existing ActiveRecord backends have pub/sub capabilities.

The result is that I'm learning Elixir/Phoenix and having the same reaction Dave Thomas describes in his new book, that is, finding anew the joy of programming.

[FooBarWidget]

I'm going to disagree with you there. First, apart from the ActionCable dependencies, Rails is already very modular. Starting from version 3 you can cherry-pick exactly what you want and don't want. For example, I have a couple of Rails apps that don't use the database, so they don't load ActiveRecord. See also nateberkopec's comment on disabling ActionCable.

Second, I find Rails to still be the most productive web framework. Removing every last bit of redundancy is nice, but it isn't going to save me that much. Maybe it'll save me a couple tens of MBs of disk space, and a couple of MBs of RAM per process. But if that costs me a few hours of work, it isn't worth it. Disk space costs next to nothing and RAM is cheap. Maybe optimizing that makes sense if you're Facebook, but most people are not.

Every time I use Node.js, Sinatra, etc I find myself wasting time around the most basic things, e.g. directory structures, database migrations, logging, etc.

[gurkendoktor]

> Removing every last bit of redundancy is nice, but it isn't going to save me that much. Maybe it'll save me a couple tens of MBs of disk space, and a couple of MBs of RAM per process. But if that costs me a few hours of work, it isn't worth it.

I don't care about the disk space and RAM at all, but every additional C extension (like EventMachine) means one more dependency that can break when I update a) my OS or compiler, b) Ruby, c) Rubygems, d) Bundler or e) Rails. Most of these updates have to be installed immediately for security reasons. I absolutely love Ruby as a language, but with Rails I feel I spend half my time in the terminal, trying to fix `gem install` incantations just to keep things running :(

[dasil003]

I guess it depends on how active development is on your project. My feeling is Rails is only suitable for actively developed projects, if you are building a small project and then handing off to a client without a budget for maintenance than Rails is worse than probably anything else (except arguably Node) in terms of long-term stability. But if your project is actively developed the gem upgrade dance is not too bad.

[bryanlarsen]

What are the alternatives?

- actively developed framework -> upgrade fun

- not actively developed framework -> security issues, trouble hiring devs, missing features, et cetera

- no framework, (also known as roll your own) -> much harder for new team to come up to speed on the code base

I contend that the first is the best of the bad choices.

[dasil003]

I agree, if you're not capable of ongoing maintenance then you are doomed with all custom software. However I expect a PHP or Java framework to generally require less maintenance.

[tim333]

web2py is quite good. Still runs stuff from many years ago, almost no security issues, does a lot out of the box. Bit of a job to make it work with websockets I'll give you.

[burrox]

Seriously? Cause I had this small 'hand in' kind of project in my hands and saw it as a good opportunity to teach myself Rails. My daily job involves .NET development but that's not very exciting and learning something new was probably the most motivating thing when I accepted the offer. So your comment makes me feel kind of worried about my decision to go with Rails.

[saryant]

If you end up more than a version behind in Rails and your project is sizable, you're in for a special version of hell. Especially if you develop on Mac OS X, the dependency issues with things like libxml2 are especially painful.

[dasil003]

See my reply to bryanlarsen... If there is no plan for skilled maintenance down the line then I always refer clients to hosted services like wordpress.com or squarespace. I used to do a lot of custom sites a decade ago with a mix of raw PHP, Drupal, Wordpress and Rails. Honestly it's all turned into a maintenance nightmare for people who didn't have "a guy" to call (I couldn't be this guy anymore after I joined my current startup). If you were determined to go down the custom route then I don't necessarily think Rails was wrong, but just that your client needs to understand up front that this will run for some amount of time and then inevitably need maintenance.

[gonyea]

What? This is the least understandable gripe. Every time I launch a new version of ANYTHING you listed above, it comes in the form of a brand new server that swaps into the load balancer. Broken Ops isn't someone else's fault.

[gurkendoktor]

Before you can throw another server into the load balancer pool, you still have to get everything to compile & run on it - and on your development machine, if they aren't running the same OS.

I am not talking about `bundle update` on a production server :)

[rhapsodyv]

I cannot agree more with you. For me, Rails is a way to get things done fast. If you can follow all rails goodies, there aren't any other framework comparable. The way things just works is the main point for me.

But of course it doesn't fit everyone needs.

[enraged_camel]

Yep, I'm in full agreement. I had to use ASP.NET MVC 5 for a project last month, and it was incredible how... coarse it was. I felt like I took five steps backward and found myself struggling with the most basic things.

For instance, there is no Devise equivalent. No modular authentication package that you can just plug in and configure in 15 mins. Horrible.

[dsp1234]

No modular authentication package that you can just plug in and configure in 15 mins.

http://www.asp.net/identity

https://github.com/brockallen/BrockAllen.MembershipReboot

[nemild]

In general, if "bloat" is an issue for you, I'd highly recommend languages/frameworks where the philosophy is more Unix-like. Rails has always been opinionated about less configuration at the risk of more bloat - and this has advantages for certain teams and certain projects.

For example, Node/NPM/Express/etc. all have a philosophy the opposite of Rails bloat, but often require more configuration, and solid knowledge of the underlying middleware.

The tradeoff between these two approaches is one many engineers need to make (e.g., the more recent Gulp vs WebPack has some similarities to this debate), and this is a common debate that will likely continue for years in the future. Pick whatever works best for your philosophy, your team, and the given project.

[laut]

Phoenix also has little configuration - without being bloated. With Phoenix you do not have to make that trade-off.

[gkop]

Apples and oranges - Phoenix is too new to compare with Rails as far as bloat. I am optimistic Phoenix can do a great job of fighting bloat because of the community's learnings from Rails. But at the same time I would not be surprised if in 10 years Phoenix has order of magnitude same amount of bloat as Rails 5. Phoenix's promise (last time I heard José speak) is "productivity of Rails, plus high performance"; the high performance mostly comes from the Elixir-based architecture, not from less bloat.

The whole issue of bloat in Rails is overblown because Rails has been quite modular since version 3.

[josevalim]

I would actually be surprised if that happened. :)

I don't think Phoenix would be as bloated as Rails in 10 years because the platform we are using is just a better platform for the web and for building distributed systems (which Action Cable with Redis plus client-server effectively is).

As an exercise, compare the implementation of channels in Phoenix and Rails. The Phoenix implementation is less lines of code (without counting the dependencies Rails brings in) while being more modular: the PubSub system is pluggable and we support multiple transports between client and server (WebSockets and LongPolling officially, embedded stuff coming soon™). Plus every Phoenix channel is concurrent and isolated. In the screencast, DHH says to avoid work on the channel to avoid blocking, in Phoenix you don't have to worry about it, at all. In this particular scenario, we do much more with much less.

The most interesting of all is that not along ago I had similar expectations as you when it comes to certain parts of Phoenix like "Phoenix.HTML". I was concerned that Phoenix.HTML would be more verbose than the Rails counterpart, both in implementation and usage. I was very pleasantly surprised when it was not the case. For example, check how we support different inputs in Phoenix (https://github.com/phoenixframework/phoenix_html/blob/master...) and in Rails (https://github.com/rails/rails/tree/master/actionview/lib/ac...). In Phoenix, a new input is a simple function, in Rails it is a class with inheritance on its own file.

Those are just some examples from the top of my head and while I am still learning as I go, I have gathered enough mileage and evidence to expect things to be much simpler in the long term. :)

[gkop]

Great, I have set a reminder to investigate bloat in Phoenix on December 21, 2025, and hold you accountable per this message :P

Seriously, I'm not worried about Phoenix, but then I don't mind the bloat in Rails, since it is modular (as is Phoenix). I would be sad though if Phoenix went explicitly away from Rails in the direction of Nodejs (composing apps with lots of smaller independent libraries, requiring more configuration) because "Rails is bloated, bloat is bad".

And to grandparent `laut, thanks for provoking this discussion! :)

[davidw]

> the high performance mostly comes from the Elixir-based architecture, not from less bloat.

Well, Erlang architecture, but yeah. With Erlang you basically obviate the need for Redis, Eventmachine, Celluloid and that whole web socket handling stack because all of that is built in to Erlang/OTP.

[gkop]

Agreed totally in this instance. I was moreso responding to the overall "Rails is bloated" argument.

[nthj]

I imagine that ActionCable will support a variety [1] of pub-subs sooner than later, similar to how ActiveRecord supports multiple databases. I almost took a stab at working PostgreSQL support in a couple of weeks ago, but Tubesock [2] was just too darn simple to pass up for my very minimal needs.

[1a] https://github.com/rails/actioncable/pull/28

[1b] https://github.com/rails/actioncable/pull/29

[2] https://github.com/ngauthier/tubesock

[xutopia]

I can't imagine running rails at scale without using Redis to cache views. To me it's a non issue.

[hackercomplex]

If you were running rails inside of Torquebox you could make use of the Infinispan Data Grid (http://infinispan.org/) to cache your views. It's underlying linear scalability mechanism is far more mature than Redis Cluster, and it's deployment story is quite nice. You won't get all of the data structures that Redis provides of course, but if all you need is a great cache, and you're already on JRuby then this could be a better fit for your loads.

[gkop]

At the very beginning, Rails made a big deal about aspiring to database agnosticism, and to this day ActiveRecord supports a number of SQL databases out of the box.

The backend for ActiveSupport::Cache::Store is similarly interchangeable (memcached, disk, etc.)

I can see why adding a Redis dependency makes opinionated programmers grumpy, and I predict ActionCable supports other backends than Redis eventually.

[desireco42]

On more serious note, we can always specify which gems we want to use. This will just bring a lot of negative energy into a fairly positive rails community, it will be a little like MongoDB, it has a use case you should not use it for, but everyone keeps bringing it up. I think it will be similar with rails, with all the ignoramuses will bring this up as a case against rails, where in reality it is not any more bloated then it is now, once you start using it, you would probably add way more gems.

[mbrain]

Do you see a future in Elixer/Phoenix? And how do you like it?

[chippy]

I often do a word count of languages and technologies in the monthly "Who's hiring" posts here. Elixir/Phoenix gets less mentions than Erlang - often there would be at least one position that says they use Elixir, sometimes none.

[awinder]

Small point: this is how all popular languages once started. Much like the stock market, there's value in being balanced on the forefront of a technology along with a solid footing in an established technology. Having no balance in either direction is the only "risky" career move.

[davidw]

I once ran a language popularity site thing, and I think jobs are something of a trailing indicator. It takes a while for people to hire for whatever hot new thing is out.

[thibaut_barrere]

I've beeen learning Elixir in the past few months and I can tell I'm definitely confident it's a good investment. Will use it fairly soon in production, first to implement ETL / streaming / batch processing of data (without Phoenix) then later for APIs (with Phoenix).

[Xixi]

Another way to look at it is that Erlang has been there for a long time (longer than both Python and Ruby), and it is not going away soon.

Elixir and Phoenix may or may not last, that I don't know, but they are a joy to work with.

[cookiecaper]

Now that the JavaScript trend is transitioning from "cool hipster language" to "a language that Wal-Mart uses", room is being made for a new language fad. Elixir/Phoenix seems like it may be a good candidate.

[hackercomplex]

Why not learn to use Erlang instead of trying to make Erlang "feel kind of like Ruby" ?

As far as LFE goes.. implementing a LISP-1 on top of erlang seems like a perfectly reasonable thing to do, but why invent some new funky syntax (elixer) ?

[piotrnowak]

If you think Elixir is about syntax or about making Erlang look like Ruby, you should really watch this talk: https://www.youtube.com/watch?v=Lqo9-pQuRKE

Syntax is the first thing José Valim discards on the talk, he then goes on to talk about polymorphism, collections, tooling and so on.

Also, both Elixir and LFE have two namespaces, so none of them would be equivalent to a LISP-1.

[hackercomplex]

I'm much more excited about LFE personally. (http://lfe.io/)

[desireco42]

And I thought I was original and unique for learning and planning to use Elixir (and) Phoenix. With or without Dave Thomas.

Microseconds I say, microseconds! :) in development!

[matthewrudy]

DHH did suggest it would become a runtime check, vs a gem dependency last week.

But it seems to have made it into the beta as a gem dependency.

https://github.com/rails/rails/pull/22585#discussion_r475154...

[why-el]

Knowing how responsive the community usually is this will be optional in no time. I think the team prioritized a launch by the deadline they set over issues like this.

[nateberkopec]

While you may disagree with DHH's reasons, you don't have to install or use ActionCable in Rails 5.

Here's a few ways to avoid it: https://gist.github.com/nateberkopec/1184c81a92c10d84d779

[regularfry]

You still get redis as a dependency if you `--skip-action-cable`. Seems... odd.

[spoiler]

Not to mention, I don't really see all the fuss about EventMachine. I worked with it a few years ago, and it had some very subtle bugs that caused me hours upon hours of headache; it would deadlock under more stressful workloads, or it would simply ignore some packets (even though the proxy server I wrote for debugging it received them just fine and forwarded them).

I just hope that they resolved some of them. And Rails has always been a dependency soup, so I am not too surprised to see stuff piled onto the ever-growing list (I have nothing against Rails, I even use it, I'm just not too happy about the bloatyness).

[hackercomplex]

I would have rather seen Celluloid::IO being used personally but even that has it's quirks.

[regularfry]

Now we've got a dependency on both EM and Celluloid. Yay.

[VeejayRampay]

I don't think there's even been a point in Rails history where you've been forced to install something. I think those are all ActionCable dependencies, which I'm pretty sure you can deactivate (not every app requires the capability it offers).

[cristianbica]

The only way to deactivate it is from your app's Gemfile (remove gem "rails" and add all the active/action gems individually). For new apps there's a flag "--skip-action-cable". In the future probably the faye/redis will probably be made adapter based (similar to ActiveRecord and ActiveJob) and exctracted in a gem. So if you want actioncable you'll have to add a "actioncable-faye-adapter" gem to your Gemfile.

[doomslice]

Minor note -- it doesn't appear like it requires faye, but rather faye-websocket, which is just a particularly amazing websocket wrapper that sprung out of the faye project.

[fbernier]

Just a small correction to this tweet, it doesn't use faye but faye-websocket which is just a websocket client/server which represents a tiny part of the Faye messaging system.

[jguimont]

You just need to comment the line in the Gemfile and you are done, no more dependencies. What is the big deal really.

[nwjsmith]

That isn't the case for ActionCable, which will become a dependency of the 'rails' gem [1]. You'll have to unbundle the rails gem in your Gemfile, then require the frameworks you want one-by-one in application.rb

[1]: https://github.com/rails/rails/blob/master/rails.gemspec#L28

[nateberkopec]

You can just add each Rails framework to your Gemfile and be done. `require "rails/all"` catches load errors, so you don't need to require the frameworks manually in application.rb.

https://gist.github.com/nateberkopec/1184c81a92c10d84d779

[aaronem]

Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s

[aikah]

> Eventmachine and Celluloid required by default? Huh. I suppose that's preferable to just installing node.js directly, although I confess I can't see how. /s

AFAIK nodejs is already an optionial rails dependency for the asset pipeline.

[Rafert]

It is through ExecJS[1] which allows different Javascript backends.

[1]: https://github.com/rails/execjs