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