|
|
|
|
|
|
by gkop
3832 days ago
|
|
|
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 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. :)