Rails isn't the fastest or the smartest framework. It has weird choices, confusing aspects and some downright terrible defaults, but for me at least, it is the best framework and it has been for years for one simple reason: DOCUMENTATION!
Every few years or so, a bunch of these articles come out shouting from the roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise some new framework, like Hanami, as the answer to all our woes, but they never seem to address documentation.
In my opinion, documentation is where Rails blows every other framework away. I have never been forced to read Rails' source code to understand how something works (I have read some of the source, but for fun, not out of need), and I can't say that about any of the other framework I've worked with. There's always some obscure method or class somewhere in them that does something unintuitive that I always have to look up. In Rails, finding the documentation on that method is as simple as a Google search, but in django, expressjs, or any of the others I've encountered, that documentation usually doesn't even exist at all.
Efficiency, scalability and reliability are all great, but when I'm starting a web app from scratch, they're really not that important. I can worry about those things once I have funding. In the meantime, I only need them to be good enough, and Rails defaults are usually good enough.
What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded. Once I'm funded, then I can think about implementing JRuby or splitting code out into microservices or rewriting with another framework, but by then, I'll have the money to take my time. Until then, Rails is the perfect framework for me and I'll keep using it until it's not.
Elixir and Phoenix is what you're looking for. Most of the goodness of Rails for productivity, without the long term bad decisions that come with it to force eventual rewrites when the funding comes. There's a reason Rails core guys have put so much time into it.
It gets every...single...dang...decision...right. I may never use another language unless forced because it's what I've spent years trying to find.
Nope. It doesn't. I've spent two years working with it. And "gets every single dang decision right" is a matter of opinion. Chris and José are incredibly wonderful people, but they are just as opinionated as the people behind Rails.
So "gets decisions right" sounds good as long as you agree with those decisions.
I happen to love working with Elixir and Phoenix. I find working with Ecto frustrating not because of the code, but because of the opinions the framework creators have made about where things go. They have good solid reasons for their opinions. And they are not wrong.
I just don't agree with them. And that's totally ok.
Depends on the decisions, but in my experience the way they've setup to do things encourages the proper balance of productivity, separation of concerns, maintainability and data integrity.
The balance on the database side of things has been most impressive because I didn't expect it at all coming from several years of Rails. In my experience to this point, the idea of letting your database enforce the integrity of your data was generally viewed as heresy. You could do it and the Rails team itself provided all of the tools to do it properly, but it seemed as if the community in general was totally opposed to it. The community shift towards embracing PostgreSQL so heavily has seemed to slowly be steering that trend away but there's still a lot of opposition. I've seen some tragic consequences because of those decisions in the last few years.
The balance encouraged in Programming Phoenix sets an excellent standard for a growing community.
The view + template layer has been a breath of fresh air.
Of course, to each his own.
Phoenix has me more excited about work than I've been in years though and I'm that guy that doesn't shut up about things that he loves. :-)
If you discover a hot new language/framework that solves all of your problems, then here is what you've actually learned: you didn't have any hard problems.
No tool is perfect for every situation, and if you find one that is perfect for every situation that you encounter, then that says a lot more about you than about the tool.
He's right though, Elixir and Phoenix are amazing. It promises the productivity of Rails, while being blazingly fast and scalable. You'll never, ever need to rewrite your backend, even if you're handling traffic at the scale of Whatsapp.
I would be hard-pressed to find a case where you'd want to write your web or mobile backend in anything else. So yeah, I'd claim that it's perfect for every web or mobile backend.
Also, no framework is ever going to solve all of your "hard problems", and he didn't claim that at all. It's simply a much better base than Rails.
It's about balance and this has the right one for about 95% of what I do everyday in terms of client-server-database work, productivity, concurrency, stability, performance and scalability. That's where I spend most of my time on the web.
Short of complex calculations or extreme niche scenarios...it does handle pretty much everything in terms of "around web" work. For niche scenarios use what's appropriate but for the space that Rails has occupied in the general purpose realm it's wonderful.
Why does someone come to promote Elixir and Phoenix in every Ruby/Rails article? The first times was nice to see someone showing an alternative, now is almost like SPAM.
Because the Elixir/Phoenix community is largely spawned from the Ruby/Rails community. They are more likely to be continuing to follow what is going on with Rails, even living in both worlds. There are many shared values and experience. That historical affinity is probably why it shows up so much in the same context. The Elixir/Phoenix community is more likely to respect and understand what Rails is and isn't as opposed to the vast majority of pretenders who say they are creating a framework inspired by, or to rival Rails, but really have no clue and proceed to put up something nowhere near the breadth or depth of Rails. Nobody who knows anything is going to come and put up an advocacy post for a PHP framework as an alternative to Rails. They know the Rails community has no interest in going that way. Elixir/Phoenix on the other hand can say with a straight face: we understand Rails and why it is successful and put forward Elixir/Phoenix as a legitimate way forward for those who want to move to a more functional paradigm and the inherent scalability advantages of a Erlang/OTA based foundation.
More seriously, the community just needs to be a lot bigger before it's on par with the Ruby ecosystem. For example, there's currently no Elixir library that will inline CSS in emails before sending.
I completely agree, I really enjoy H whatever Lotus.rb is called these days and especially like Trailblazer. So you could say that in general I agree with this sentiment, just, it would never cross my mind to be as hard to Rails as some of commenters are.
I haven't seen any about Rails being dead, just people ready to move on from Rails and how it's not for them any longer. If it makes sense for a particular shop, they should continue using it. I say this as a non Rails user but believer in the right tool for the right job.
Just looked at the rails documentation for the first time in years. It's drastically improved.
My experience with earlier versions was that you kinda had to piece it together yourself. Learning Play Framework was 10X easier for me since the docs were already there: https://www.playframework.com/documentation/2.5.x/Home
So I think maybe you're just not considering non-Ruby options. Which is totally your prerogative. Just saying it's not my experience. It may be the best Ruby framework. But that's a different argument.
> What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded.
Aside from syntax, I don't see any reason anyone would be faster with Rails. It's certainly not my experience. I worked with Ruby for 8 years. I've seen some very talented and very enthusiastic Rails developers. I've never seen one that could build an app faster than even an ASP.NET developer from years ago, and I certainly don't see any advantage over Play, which is generally more stable, much faster, projects generally have fewer dependencies.
The performance advantage of other platforms is underappreciated IMO. The fastest code is no code. If I can do something in Scala through brute that would be impractical to do within the request/response cycle in a Rails Action, that's a development speed advantage. If I never need to consider using some sort of background job service like Resque or message queue because I can just say `Future(someComplexOperation)`, that's a development speed advantage. If I don't need to tune my app or worry about my caching strategies because it's just that fast... You get the point I'm trying to make I'm sure.
Outside of performance, deployment (far simpler with Play), language syntax, and ActiveRecord (I'd just use the simpler, faster Lightbend Slick library) they're basically the same framework. Play doesn't chart much new territory. Sure WebSockets integration with Actors is lightyears ahead. But many won't ever touch it. There's some JSON stuff with validations that's very powerful, but embedding the equivalent of a JSON schema in your Action is verbose beyond trivial examples. I'm not sure how much use it gets.
I found Play much easier to learn than Rails (again, this was years ago) and much more consistent. Given the other advantages, all things being equal (familiar with both Scala and Ruby), it's tough to imagine many developers choosing Rails unless they were worried about externalities like building a team or something.
It'd be interesting to hear the thought process of such developers though if they're out there.
Every few years or so, a bunch of these articles come out shouting from the roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise some new framework, like Hanami, as the answer to all our woes, but they never seem to address documentation.
In my opinion, documentation is where Rails blows every other framework away. I have never been forced to read Rails' source code to understand how something works (I have read some of the source, but for fun, not out of need), and I can't say that about any of the other framework I've worked with. There's always some obscure method or class somewhere in them that does something unintuitive that I always have to look up. In Rails, finding the documentation on that method is as simple as a Google search, but in django, expressjs, or any of the others I've encountered, that documentation usually doesn't even exist at all.
Efficiency, scalability and reliability are all great, but when I'm starting a web app from scratch, they're really not that important. I can worry about those things once I have funding. In the meantime, I only need them to be good enough, and Rails defaults are usually good enough.
What I really need when I'm starting a new project and I'm working on a shoestring budget, is speed. I need to build something fast so I can get funded. Once I'm funded, then I can think about implementing JRuby or splitting code out into microservices or rewriting with another framework, but by then, I'll have the money to take my time. Until then, Rails is the perfect framework for me and I'll keep using it until it's not.