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"
"@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"
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.
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.
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 :(
- 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.
The good news is that Rails is now mature, so the upgrade path tends to be easier than it was in the early days.
I am not talking about `bundle update` on a production server :)
But of course it doesn't fit everyone needs.
For instance, there is no Devise equivalent. No modular authentication package that you can just plug in and configure in 15 mins. Horrible.
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.
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. :)
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! :)
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.
[1a] https://github.com/rails/actioncable/pull/28
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.
Elixir and Phoenix may or may not last, that I don't know, but they are a joy to work with.
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) ?
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.
Microseconds I say, microseconds! :) in development!
But it seems to have made it into the beta as a gem dependency.
https://github.com/rails/rails/pull/22585#discussion_r475154...
Here's a few ways to avoid it: https://gist.github.com/nateberkopec/1184c81a92c10d84d779
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).
[1]: https://github.com/rails/rails/blob/master/rails.gemspec#L28
AFAIK nodejs is already an optionial rails dependency for the asset pipeline.