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.
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.
> 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 :(
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.
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.
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.
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.
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.
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.
Yeah I'm in a similar situation as in I can be 'the guy' for now but eventually they'll need to find another developer to maintain the app. But what could have been a decent alternative for a webapp + db setup? I don't think wordpress is suitable for that kind of project.
Wordpress I consider to be the worst of the worst because A) it's a constant target of attacks and B) the hosted version at wordpress.com is much less headache (if you don't need heavy customizations).
The good news is that Rails is now mature, so the upgrade path tends to be easier than it was in the early days.
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.
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 :)
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.
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.
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.
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.
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. :)
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! :)
> 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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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) ?
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.