It's become fashionable to hate on rails, and honestly I understand the motivation--it isn't cool and cutting edge anymore. It's slow. It doesn't do concurrency well. Ruby is nice for what it is, but it lacks the power and stability of functional languages, and lacks the performance of go or javascript on v8.
But rails is just doing what it's always done: trying to optimize developer productivity for front end web dev and routine web tasks. In this it's far ahead of the pack, and for many businesses, both small and large, this is exactly the right thing to optimize. Say what you want about github, but they push a lot of features and push them fast.
Rails is not for crafting algorithms, but when you need to crank out 6 new pages with various complex crud views and forms by Friday, and by the way can it be exportable to cvs and oh can you also do paypal and oauth integration and user avatars with thumbnails, and keep it all reasonably readable and organized... the sad fact is that for all of rails' heft and lack of cs cred, trying the above with any other framework after you know rails will drive you insane, because despite how great the language is or how many connections your server can handle, you are again and again spending days on things that take an hour in rails.
Ultimately, I don't think the way forward from rails is to search for a partial reimplementation of rails in some other language. Rails is the best we've got for rapid front end and shallow back end work. So use it for what it does well. For what it doesn't do well, use something else. Personally, I think it's silly to have an ORM written in ruby. ActiveRecord is for the most part a lovely api, but its guts should be a separate service written in go or something. Building a complex recommendation engine or game AI? Write clojure or haskell services. But when the data comes back and you need to dice it up and lay it out as html, with a hundred little ohs and ifs and buts, it's not a fun time without rails.
>>It's become fashionable to hate on rails, and honestly I understand the motivation
Well, they were pretty vocal about calling everybody, in no uncertain terms, for using frameworks other than Rub/Rails, an idiot. There is plenty of bad will that they've been accumulating because of that and this is simply the backlash.
If you really think you are the best there is no need to insult developers who do not use your frameworks. Unfortunately that is exactly what they did. People have long memories.
And in my opinion they deserve every bit of it.
The comment below by user mhartl demonstrates the attitude of pretending everybody else is shit.
>>Ah, so following Greenspun's tenth rule [1], perhaps we
>>have this:
>> Any sufficiently complicated web application contains
>> an ad hoc, informally specified, bug-ridden, slow
The nerve to call other frameworks bug-ridden as if their shit didn't stink. Specially in light of all the security problems with Ruby/Rails that have come to light recently.
Well, the magic is what enables the big productivity boost. It's a higher risk, higher reward approach. In some domains that added risk is unacceptable, but for many applications it's a very worthwhile tradeoff.
I think often when people say "I hate rails", they are really saying, "I hate building the types of apps that rails excels at". Which is fine, and makes sense, because rails excels at making apps that can be very cool and innovative on the product side, but are usually pretty boring on the engineering side--it doesn't really get interesting for the engineers until it's time to start replacing the lower level tiers of rails with something else. And while secure best practices are certainly stressed (and included as defaults), conservatism isn't seen as a valid reason to hold up progress. So you get both the speed and the occasionally bumpy ride that strategy entails.
That has nothing to do with it whatsoever. They specified why they hate about rails, the magic. Personally, I simply cannot stand magic in frameworks I use. That's because I don't become truly productive when using a framework until I fully understand how everything works.
It is not enough that it does work, I have to understand how it does. Otherwise, I'm constantly bogged down when implementing every single feature thinking about possible security and performance issues down the line. The performance thing might be premature optimisation in some cases, but the security definitely is not.
That's why I hate when frameworks or IDEs have so much magic -- I'm looking at you Xcode, I can't count the times I was wondering if a particular statement would cause a memory leak or not before I finally understood most of the related magic Xcode and the toolchain for iOS dev do.
For me at least, magic saps my productivity, it doesn't boost it. It also offers a steeper learning curve to proper mastery to get to that point where I'm actually productive. So yes, I haven't tried ruby on rails but I can definitely see myself hating it if it has too much magic.
Have you taken a look at the play framework? Yes it is inspired by rails, nearly as productive and very little magic.
I don't get why you think I must secretly hate what rails is used for -- I don't, at all. And yes when rails was written the productivity was so much better than its competitors, rails was the choice.
Today, not so much. Don't get me wrong if it is an internal wiki or other system then rails makes sense, since if you get hacked you can always find the guilty person.
As for conservatism? Dude I write HTML5 games for a living and I am not arguing for JSPs here, just Play or Django or Sinatra (Ruby is great, don't get me wrong) but Magic is going to bite you at some point.
I haven't personally looked at the play framework, though a former colleague who is steeped in both rails and scala did a pretty thorough comparison a few months back. He is definitely not a rails partisan, and much prefers scala to ruby as a language, but his conclusion was that while play has a solid core and does many things right (including some things better than rails), it comes up short on convenience and utility functions, templating, and ecosystem.
I think the ecosystem in particular is an area where rails magic makes it possible for the community to create very powerful gems that just work, and is probably where the most time is saved vs. other frameworks that have more of an explicit bent. I understand the skepticism towards the implicit approach--it has certainly bitten me before, and I try to minimize magic in my own rails code wherever possible--but again, if you're optimizing for productivity, it can be a worthwhile tradeoff.
Take devise as an example. Despite using all kinds of implicit and convoluted magic underneath, it can save huge amounts of time, especially early in a project, and is well tested and proven in the community. I'm not aware of a lib in any other framework that can handle so many boring authentication issues (sessions, roles, encryption, email confirmation, lockouts, remember me, forgot password flow, session expiration, redirect flows, etc. etc.) with such minimal code and configuration.
Sorry if I put words in your mouth. I do think a framework like play has more conservatism in its blood, which is great. It's good that there are other options for when security, stability, and scalability are at more of a premium than developer productivity .
But seriously, maybe your friend just wasn't all that well versed in Scala. I'm no pro (yet), but on the topic of Utility functions, I haven't run across any big holes. The Collections API is very Fluent (in the Martin Fowler terminology describing Ruby's Array), so it's hard to fault that. In fact, it goes quite a bit farther.
You have Option, Try, Either to use FP in a way Ruby-only programmers probably won't ever grasp. I certainly didn't. I've never seen any real Ruby code that comes close to a foldMap (foldLeft(Tuple2[Accumulator, Map])), or a Try pattern match, or (you could go on and on...).
Templating I don't get unless you're wed to HAML maybe. There are similar libraries for Scala, but it's hard for me to imagine someone being able to compare Twirl (Play's templating) to ERb and declaring ERb superior on any metric. Twirl is arguably simpler, definitely far faster, has no identifiable magic, and Scala+Twirl makes it silly easy to avoid a whole class of common problems with branching logic (hello id=4 my old friend!).
Play has First Class Forms. Rails doesn't. I'm sure Rails will some day. Declarative data binding is simply better. Safer, simpler, provable correctness.
I'd give Play a second look. :-)
To be fair, the one gap I've come across is in String manipulation. A few minutes of googling and a little tweaking and I've got a quick slugging function though: https://gist.github.com/sam/5213151
And then there's stuff like writing:
10 seconds
Which makes me giggle a little inside every time I write it. :-D
On the other end of the spectrum, there's all the things Play gives you Rails doesn't: Futures. Actors. Async. Chunked Responses (which maybe Rails 5 will have?). WebSockets. Awesome XML (it's nice to use a lib that does not suck if you have to deal with it). Better JSON support. Functional Programming. Pattern Matching. Performance. Built in (Memory) Cache Concurrency. Functional Testing with Selenium. A built-in production ready web-server. Continuous Testing. Deployment Packaging. Bootstrap. LESS compilation. SBT: A single tool that provides file system watchers, Tasks, compilation, packaging, dependencies (including Git). All the JARs a Jar Jar could Jar if a Jar Jar could Jar Jars.
The only significant downsides I've run into are:
1. Sharing your code as a package is harder. Much harder. Nexus isn't nearly as low friction as rubygems.org.
2. Binary Compatibility concerns means sometimes your best option is a source dependency.
Git dependencies have been a good solution to #1 for me so far, but I know the day will come when I'll have to figure out hosting on Maven Central.
What makes you think RoR was built by people with no understanding of security? Rails was one of the first frameworks to do things right (CSRF protection comes to mind).
Rails changed the default to safe output about three years ago. 3.0 escaped output out of the gate, and 2.3 switched the default in the 2.3.6 neighborhood.
Prior before that, the standard way to sanitize html output was to write <%= h foo %> instead of <%= foo %> in your templates.
Their (abuse) of the Yaml parser. It is one thing to use a potentially dangerous parser on a file that you aren't going to let anybody touch either (your database config); it is downright stupid to use a dangerous parser on untrused user input (json) a format it shouldn't even parse to begin with.
And as of late tons of similar bugs have been found. CSRF and database parameterization was well known issues when Rails was written, so yeah props for that. It is just not enough anymore.
Would be nice to see some side by side code of Rails and Java/Spring doing roughly the same things, both written by people experienced in those technology stacks. These debates aren't very useful without code to look at.
But rails is just doing what it's always done: trying to optimize developer productivity for front end web dev and routine web tasks. In this it's far ahead of the pack, and for many businesses, both small and large, this is exactly the right thing to optimize. Say what you want about github, but they push a lot of features and push them fast.
Rails is not for crafting algorithms, but when you need to crank out 6 new pages with various complex crud views and forms by Friday, and by the way can it be exportable to cvs and oh can you also do paypal and oauth integration and user avatars with thumbnails, and keep it all reasonably readable and organized... the sad fact is that for all of rails' heft and lack of cs cred, trying the above with any other framework after you know rails will drive you insane, because despite how great the language is or how many connections your server can handle, you are again and again spending days on things that take an hour in rails.
Ultimately, I don't think the way forward from rails is to search for a partial reimplementation of rails in some other language. Rails is the best we've got for rapid front end and shallow back end work. So use it for what it does well. For what it doesn't do well, use something else. Personally, I think it's silly to have an ORM written in ruby. ActiveRecord is for the most part a lovely api, but its guts should be a separate service written in go or something. Building a complex recommendation engine or game AI? Write clojure or haskell services. But when the data comes back and you need to dice it up and lay it out as html, with a hundred little ohs and ifs and buts, it's not a fun time without rails.