In the year 2013 it is difficult to remember why Rails was such an explosive breath of fresh air, back when it burst onto the mainstage in 2004/2005. The essay that I think best captured the switch in popularity, from Java (and EJBs and Struts, etc) to Rails, was "The departure of the hyper-enthusiasts" by Bruce Eckel, written in December of 2005. He wrote:
"One of the basic tenets of the Python language has been that code should be simple and clear to express and to read, and Ruby has followed this idea, although not as far as Python has because of the inherited Perlisms. But for someone who has invested Herculean effort to use EJBs just to baby-sit a database, Rails must seem like the essence of simplicity. The understandable reaction for such a person is that everything they did in Java was a waste of time, and that Ruby is the one true path."
The thing that struck me the most at the time was scaffolding. In the original Rails demo they essentially said, "make me a todo list" and poof, there it was. All you had to do was customize two snippets. It really was amazing.
By Rails 2, they were already saying you shouldn't be using scaffolding. I had sort of realized that scaffolding "wouldn't scale," to misuse the expression; by your second or third app you usually didn't bother with it, instead generating a migration and a model and doing the rest by hand.
I wasn't using Java prior to Rails, but I am using Java now and I would say the essentially disparity between the two at the outset was simply maintenance. Rails didn't have a past to worry about back then. My impression is that it still does a lousy job of handling upgrades—though at least with bundler et. al. they have finally achieved a semblance of stability. I suppose I should be able to check out code written 9 months ago and arrive at a working Rails app. There was a time during Rails 1 and 2 when you experienced real fear that running "gem install" might hose something, or that on a new machine the gems you needed might not even be "out there" on the internet to be installed. Java still goes further on these fronts, and probably always will, since "corporate" technologies will always be about retaining as much of the investment as possible.
I know it is not the mode to comment to mention your own up vote.
Rails might have deteriorated in ease of use, but I cannot imagine it being worse than Java EE was in 2004. Modern Java EE is a world of pain, even simple apps are difficult to build. The entire front end stack is antisocial, difficult to extend and anachronistic.
I don't think anyone working with a modern java web stack could read this post about rails 'being like java' without a dark chuckle.
Rails is now like Java EE because it is no longer better than the competition. It's not that Rails got worse. Perhaps in simplicity it did get worse a bit, but overall Rails now is much better than Rails then. The thing is that the competition got a lot better too. The baseline changed.
I don't think the thing that will be to Rails as Rails was to Java EE exists yet though. The competition has merely caught up, perhaps a little ahead on some fronts and a little behind on others. But there is nothing that is clearly much much better. Things like Meteor and Opa are a step in the right direction, but they don't go far enough (yet).
This is not the original Rails video, it's the second one I think, but they're fairly similar (couldn't find the original). Back then when I saw the first Rails video I remember finding it amazing. Now it's just boring.
Surely you don't think that Rails is better than everything else in every single respect? There are plenty of frameworks that are simpler (Flask/Sinatra), faster (Play, etc.), support lightweight concurrency better (node.js based, Play too, etc.), have much better IDE support (ASP.NET MVC), support client/server partitioning (Meteor/Opa), and so forth.
What you just said is very different from the first sentence of the comment I replied to. Let me repeat it, "Rails ... is no longer better than the competition."
I think rails is better than the competition if my goal is to make fairly standard websites. It would be a rare exception where I think something else is more suitable.
"No longer better than the competition" doesn't mean "Worse than the competition for ALL use cases".
The thing is these frameworks have caught up so much on the expressiveness front that their other advantages can easily start to outweigh the small advantage that Rails has there. But if you are building a low traffic CRUD site (like most sites), then yeah use Rails. If you are building say a chat application, I wouldn't use Rails.
The dismissive use of "low traffic" bothers me. We made http://disney.com on rails, it runs off a couple of VMs, is really fast, and serves a significant amount of traffic. Can you quantify what you mean by low traffic?
I didn't mean to imply that building a high traffic site in Rails is not a good idea, merely that low traffic is its sweet spot. If you have high traffic it might make financial sense to forgo some productivity and choose a framework that can run on lower amounts of hardware. This also depends on many other factors. For example if your content is low write high read, i.e. highly cacheable, that can make any difference pretty much disappear.
Let me try to be more specific. If we consider the space of web development, I think you are implying that rails sweet spot is a small portion of that space. I feel strongly that a very large portion of the entire web dev space is within rails sweet spot. I think I can back this up, as I did once already with http://disney.com as an example.
"If you have high traffic it might make financial sense to forgo some productivity and choose a framework that can run on lower amounts of hardware"
I've worked on numerous sites that are in the top 1000 traffic wise according to alexa. I never once felt that it was worth moving them off of rails/ruby. You are probably talking about the top 0.01% of sites or even lower than that.
> I think you are implying that rails sweet spot is a small portion of that space.
No, certainly not! I think Rails is fine for 99% of web sites, and probably the framework that has the highest percentage of sites where it would be my top choice. But Play is also fine for lets say 98% of web sites. Rails even works fine for things like chat applications, but there it would not be my top choice (at least not for the component that serves the messages). That's all I'm saying. Rails is my favorite framework, I just don't think that it is better than everything else in every respect.
You are probably looking at this from a different perspective. Of course it's not worth moving an existing site off Rails if it is already done, or when you'd have to learn a completely new language and framework to do it. But if you are at the start of a project, and you already know e.g. Scala and Play, the situation may be different.
Have you tried Java EE 6 ? JAX-RS in particular is a splendidly designed api for RESTful services. And then you can make single page apps instead of JSF. This method is even going have ide support in Netbeans 7.3 with wizard-driven Backbone/Angular app generation.
JAX-RS is really nice for building APIs and I actually prefer the way it works to Sinatra, especially if using it with Groovy.
But, this isn't Sinatra vs EE6, its Rails vs EE6, so its not a proper comparison.
To compare with Rails you've got to look at other parts of EE6: JSF + CDI + JPA, which is an awful mess. JSF by itself is enough to kill its usability for many modern applications, the amount of state JSF carries around is ridiculous.
The article said Java, not JEE. In Java land, the choice is much broader than JSF or JPA. The main problem that people bashing Java had was always that it offered too many choices. Ruby had Rails while Java had JSF, Struts, Struts 2, Tapestry, Wicket, Play. Rails had ActiveRecord, while Java had JDBC, Hibernate, MyBatis, OJB, EJB 1/2/3, JPA.
JPA is fine, if and only if you've got a framework managing the entity manager lifecycle for you in a reasonable way.
In my opinion if I need an entire separate framework (or container) to manage it, I think its broken. I've switched to Ebean for Java ORM and am vastly happier now.
JPA also gets the award for the worst programmatic query building API I've ever seen. As a result it seems like the majority of people just use JPQL strings which is really annoying as its also SQL but not quite SQL.
The most painful component of Java EE development for me is definitely the JSF side of things. Without building anything substantial with JAX-RX I cant really comment. REST and a rich frontend, JS based would be my choice. The sad truth is that I live in a world where usable is beaten out by sellable.
I think the point is, other systems have now emerged that can reasonably claim to represent the cutting edge of simplicity and ease. Rails held that distinction for several years, it was the reference point people used to criticize or praise other systems. But Rails is no longer the clear leader in ease of use or sophistication of 3rd party libraries. In response to Rails, lots of new languages and frameworks emerged, all of which offer a lot of new ideas about what the cutting edge is in 2013.
Many of them aren't tightly coupled. In fact, I'd say rails is better on this front than anything comparable. Is it easier to use Mongo with Rails or Django? What about couchbase? Rails makes it very easy to make an ORM work well with rails and to replace ActiveRecord with it.
Better yet, what framework do you believe offers all of these things and does a significantly better job at decoupling than rails?
It's been a while since I looked at grails, but it was clearly worse when I looked. Some examples, rendering an action as json, XML, or HTML. Using mongo. Etc.
No, Rails hasn't turned into Java. Rails has matured into a complex ecosystem. Java has also matured into a complex ecosystem.
Frameworks upon frameworks is a recipe for complexity, potential performance problems, bottlenecks, and environmental/context-specific issues regardless of the language that you're using.
Will there ever be a language or simple framework that is popular, solves all problems, and doesn't get more complex as its ecosystem matures? I won't bet on it, but if you figure it out, someone will still eventually compare you to a no-longer-hipster-cool framework as an insult.
I added in a note, I think this is the multi-year result of not having a old, grey-haired standards committee around creating APIs. I made fun of Sun and Oracle for doing things like this for years, but after futzing around with Rails frameworks, integration, and edge-cases. I think I would have preferred to have people sitting around a conference call saying things like, "Hey Devise people, your authentication approach looks like a good standard, why don't we formalize it so we can make this stuff easier to integrate."
I think the nice thing about Rails is that the core committee tries to make the core framework slimmer by removing features and stuffing them into gems. It's nice that Rails keeps features out that might be considered "core" by others, like authentication. It allows new "core-like features" to be adapted by the community.
What would be the point of making it a standard ? It's already one de-facto. I prefer to have other solutions not trying to be devise but rather solving auth problems in their own way. Also, the lack of documentation is often balanced by the great readability of the code (Which is extremely clean / straightforward for devise & omniauth & most of the strategies)
That is fine and true. But if you guys know this why do rails people love to bash on Java and act like rails is the second coming of Jesus. Fine, you love your language but why the unnecessary insults? That always bugged me. A community like that is toxic.
I really don't think that's the case anymore. At the most recent RubyConf in Denver there was nothing but love for the JVM, running Ruby on it, and even utilizing Java itself when the need arose.
To be fair, at the time it was introduced, Rails was, in fact, the 2nd coming of Jesus. I've met DHH in person I can attest to the fact that when he walks, the faint sound of angels fills the air. It's true.
As a Java developer that got in to Rails I have been saying this for years (especially since Rails 3). I'm glad someone else has finally brought the discussion to HN.
I don't get the Java hate. The stuff in Java is not there just to make your life miserable, it's a result of thousands of people spending millions of hours on complex problems finding that certain methods work well when your source code base becomes too large for simplistic methods.
The fact is: Java works, and it works well. Ruby/Rails is getting there, as we see from larger and larger code bases being build on Ruby/Rail and needing more and more of the hated 'Java' features - because they work.
Any language can be used for a small project and work very well - precious few can still continue to work well at scale.
I've found a lot of the HN crowd to be biased in this area. I believe that comes from most of HN working in startups which means less legacy code, smaller code bases, and more focused products with less management bureaucracy and changes. A sizable part of HN is also younger and hasn't yet worked in an environment of sufficient scale to require Java's(c++, advanced RoR, etc) features.
I could be way off here - but if you're knocking this kind of complexity and haven't worked on a massive project - it might simply be your frame of reference and you should stop knocking it.
The whole point of rails is not to build massive projects. If you're building massive projects with thousands of classes on rails then you should be all means switch to J2EE.
This needs to be repeated over and over. We see so many pundits pushing the "right" way to build Rails applications now. Rails was a reaction against large applications. The major use case is to build CRUDs in front of a db. If your application out grows Rails, it's not a condemnation about Rails, or your team, or an earlier choice.
If you're Twitter or Facebook, don’t use Rails out of the box. For the rest of us who want to work on small applications, Rails is still beautiful. And when I say small, I mean applications around the complexity of a Basecamp or Github.
Fully agree, the next boogey man against rails is performance which again is quite a silly argument when you have customers and servers cost $5 / month.
>it's a result of thousands of people spending millions of hours on complex problems finding that certain methods work well when your source code base becomes too large for simplistic methods.
Sure. But how well does it work? I think it's obvious right now that the JVM is a fantastic piece of engineering, and java took us far, but that it's aging and inflexible.
Here's my problem with java explained succinctly in anther thread:
I largely agree with you even though I have written a lot on the superiority in my opinion of (J)Ruby, Clojure, and Scala as JVM languages.
The reason I agree with you is that last year while on a vacation without a computer I spent some time thinking about languages and made a guestimate that if I had stuck with Java and never spent any time learning new languages, then my productivity would have been a bit higher.
However, and for me this is a large issue: I really enjoy learning new languages, and twisting around how I think about programming.
I mostly retired in January except for helping some customers in emergencies, and for my own retirement projects I use Clojure exclusively. In retirement, I am damn glad I am not doing my passion projects in Java :-)
But there was a stretch from around 2005 to maybe 2008 where Rails seemed to defy criticism. It grew and grew, despite the criticism. I tried it for a project in 2006 and I became a fan. The easy use of 3rd party code, via gems, was much easier than anything I had known in Java or PHP.
I do not know a way to say when some of the criticism began to stick, but clearly things have changed. I have my own personal experience: once a fan of Ruby and now a fan of Clojure. And others have moved on -- there was recently the conversation about multi-threaded Ruby apps, and it seemed to me all the smart people agreed that jRuby is the future of Ruby: http://tonyarcieri.com/2012-the-year-rubyists-learned-to-sto...
If I had to pick one moment when some of the criticism against Rails began to take hold, even among those who had once favored Rails, it was Zed Shaw's insane rant:
Even though the tone is insane, he made some points that stuck in people's heads, including mine. This was important to note:
"I believe, if I could point at one thing it’s the following statement on 2007-01-20 to me by David H. creator of Rails:
(15:11:12) DHH: before fastthread we had ~400 restarts/day
(15:11:22) DHH: now we have perhaps 10
(15:11:29) Zed S.: oh nice
(15:11:33) Zed S.: and that's still fastcgi right?
Notice how it took me a few seconds to reply. This one single statement basically means that we all got duped. The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average."
And even now, in 2013, when I have to set up a new server with Rails, even with Nginx and Unicorn and all the other systems to help me, I find Rails annoying to set up, especially compared to the simplicity of PHP running on Apache or a Clojure app bundled up with something like "lein uberjar".
I don't think that's really an accurate picture. That rant is old as hell. IIRC it's about Ruby on Rails 1 — not even the now-venerable Rails 2, but the first version that nobody on earth uses anymore. It predates Rack and Passenger and all the stuff that Rails developers have taken for granted for years now. Surely you'll agree that Rails 2 and Passenger were not late to the party.
I think the biggest thing that made Rails fall from grace (to whatever degree it has) was the way it ground to a halt for what seemed like ages while they worked on Rails 3, and then when 3.0 came out, a lot of people found it unimpressive on its own merits, and even more so when viewed in light of how long it took. (This is largely because a big part of the Rails 3 work was refactoring and trying to make it less monolithic, which are good things, but the kind of good things that get you yelled at by people who don't care about them.)
I'm kind of in a state of disbelief that I'm even reading this. The "Rails is a Ghetto" rant? Everything you cite is from 2007.
> And even now, in 2013, when I have to set up a new server with Rails, even with Nginx and Unicorn and all the other systems to help me, I find Rails annoying to set up, especially compared to the simplicity of PHP running on Apache or a Clojure app bundled up with something like "lein uberjar".
Then don't pick Unicorn. Yes, Unicorn is a fantastic app server, but it requires that you know the app server very well, and as with all stand-alone app servers, the configuration is more complex.
Instead, pick something like Passenger. Passenger runs as an Apache module and is just as easy to get running as PHP.
What saddens me in this comment is a very common overtone that Ruby is a synonym to Rails.
Admittedly, Rails had a major role in Ruby's ascension into the programming glory; however, in the course of this, it overshadowed the language itself. It created a bubble within the community.
But the real tragedy is that by virtue of Rails being most visible and vocal, the whole Ruby community is appraised and influenced by their actions and rhetoric.
He's talking about installing the web server, not deploying the application.
Deploying an application can be done with 1-3 commands in any language, since it has little to do with the language itself. All you need is a build or deployment script, which can be written in Bash or whatever.
I realize, but that too is a constant per platform. It's about the same amount of effort per web server per ecosystem, since in our we case we reverse proxy to the application server.
If we're talking about shared hosting, that's a whole different ball game.
> If I had to pick one moment when some of the criticism against Rails began to take hold, even among those who had once favored Rails, it was Zed Shaw's insane rant:
That's simply not true and not fair. Rails of v1-v2 era were much worse than what we have now. Tooling improved immensely since the rant (bundler, rvm) and the most popular ruby implementation itself improved. Granted, it's somewhat harder to start rails today than it was four years before, still we are much better off.
This is bullshit. I'm no fan boy but you can't blame yourself when you've cornered yourself in an complex case of interdependencies. BREAKING NEWS: OVER-ENGINEERED PIECE OF SOFTWARE IS REVEALED TO BE OVER-ENGINEERED.
I don't use Refinery, Devise, OmniAuth, Unicorn, Rack Rewrite, Fog, AMQP, or Heroku.
I use Passenger with Apache or Nginx, self-host, and write my own core functionality like authentication.
Rails is still great at having an idea and throwing together a proof of concept in one day; running "rails s" still works out of the box. It still allows you to defer the hard choices, until you actually have to make them. If you've cornered yourself by making your stack too complex too early, that's your own damn fault—in Java you have to make those architecture choices day 1.
Dynamic typing: if you treat Rails like Java, it acts like Java.
+1 on keeping things simple and not using a "F"ramework for every concern from the very beginning.
>in Java you have to make those architecture choices day 1.
That's just not true. Very easy and advantageous to start out with say a simple container-less app with in-memory/flat file persistence and build up as you need. It's no different in Java and much more the norm in other JVM languages like Scala/Clojure.
Perhaps the Java bit isn't true... or isn't true anymore; I haven't done much serious development in Java since I started doing Rails consulting in college. I remember it being XML hell where you needed to plan ahead a lot more in terms of choices, but that said I've probably become a much better developer too.
No, what he's saying is that engineering is about tradeoffs. Adding another framework introduces another node in the graph, and n edges. If you don't need fancy authentication and are pretty confident you never will, then don't add devise. If you don't know or understand why you would use some bleeding edge web server or framework, use what is well-understood and has the least moving parts.
Leaning on the code of other people is something you do very deliberately, and it's a mistake to think that it always saves you time.
If you think you're saving yourself from reinventing wheels by adding Yet Another Gem into your gemfile, then you'll quickly find yourself constrained by the code of other people instead of your own code and mental model.
Your app becomes a mat woven of interdependent Things That Almost Do What You Want and you'll spend more time wrestling with other people's code than the time it would've cost you to write and maintain exactly what you needed in the first place and no more.
It's sort of like that time you thought Devise was going to save you all this trouble but soon realized you merely moved the battlefront from (A) a diff'able domain that you control to (B) Google SERPs, Stack Overflow answers, and a Github wiki page of customization boilerplate and copy-and-paste'able incantations that sorta do what you want.
I agree with you that Rails still excels at allowing you to slap together a quick prototype, but I think that the world has caught up with Rails (and possibly bested it at this point).
> Sure, Rails itself is straightforward, but the frameworks you slap on top of it can quickly become burdensome abstractions: RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, not to mention the extra magic that Heroku gems throw into the mix (backups and other fun).
You don't need to use any of these. I once tried to use Devise for a project. I fiddled with it in an attempt to make it work exactly the way I wanted, but eventually I gave up and just rolled my own authentication. It's not hard at all to do in Rails, and you end up with much simpler code. I also tried New Relic, but I didn't see much point to it (maybe it's more useful for apps with a ton of traffic) and they sent me spam until I asked them to stop several times.
This is where I lost a lot of faith in the author. His argument becomes "Rails get's tricky when you frankenstein a bunch of gems and additional frameworks into an app." I'm totally with you, I don't get the Devise obsession. It's easy to roll your own authentication. In the app I'm working on right now one of my co-workers once said "we don't even have a gem for authentication" and I wanted to pull my hair out. Eventually I incorporated Warden into our auth process which moves authentication to middleware and provides some useful test functionalities. And the whole Warden library is readable. Devise is actually built on Warden and you can get a lot of good, simple implementation ideas from reading the Devise code rather than wholesale slapping their entire API into your app to replace what might be a few dozen lines of auth code for a lot of projects.
If you Frankenstein your app together at every chance you're failing to manage complexity because you end up dealing with a dozen APIs (or dozens!) all designed in different styles by different developers. At this point you not only need to know Ruby and Rails but also the API of every framework you have added.
I'm not saying don't use gems but eventually if you don't write any code yourself you're going to have a complex mess you don't understand. And that's not Rails's fault.
But, Devise is one of the better frameworks out there. Along with Omniauth it saved a huge amount of work. I'd reconsider Devise and look at Omniauth, it is a huge time saver.
New Relic is awesome, but expensive and they do have an aggressive marketing automation thing going on with the emails and such. But, you can't blame them for that, they have to pay the bills and more power to them for that.
I think it's a matter of personal taste. Devise is a pretty large library that deeply entrenches itself in your application and expects you to do things in a certain way. I personally don't think it's worth the added complexity, instead I prefer using standard Rails features [1] to build exactly what I want. But then, others may feel it's not worthwhile to even use Rails and instead prefer to use Sinatra or Flask. Every developer seems to have their own comfort zone in terms of how much control they have. For instance, Linus Torvalds won't even use C++ over C [2].
Omniauth looks like something I would use, though.
As for New Relic, I certainly can blame them for spamming. I realize that everybody's gotta eat, but there is no excuse for them to send me "I wanted to connect regarding your interest in the New Relic trial. So far I have not been able to successfully reach you." after I already sent them two emails telling them to stop emailing me. Annoying anyone who hands over their email doesn't strike me as a particularly ethical business strategy.
There's not a lot of content in this article frankly. I also suspect the author has either never been exposed to an 'enterprise' J2EE or Spring app, or has simply forgotten what a labyrinthine nightmare those could become. Rails is more complex today, but it is still significantly easier than traditional Java frameworks.
I suspect that your suspicions are wrong because I wrote the article and I spend much of my day writing both Java and Ruby. I just find it easier these days to work with Spring 3. Why? Because the Spring and the Oracle folks reacted to Rails pretty quickly and came up with a lot of solutions that might surprise you.
It takes just about the same LoC now to do in Spring what I'm doing in Java. The difference is that the performance in Java is much higher.
* Lines of code, and number of tasks necessary to get a development environment set up.
* Memory used with one client accessing the system, and with, say, 10 clients accessing it.
* Some performance benchmarks.
I keep my ear to the ground, and have used enough languages in my time that jumping to a new one isn't that big a deal, but I'm pretty happy with Rails and use it by default these days. It's a great way of getting something up and running quickly, while maintaining some order and sense of purpose to the code. It's what I'd use unless there are very clear reasons not to, such as huge scale requirements from the get-go, heavy involvement with web sockets or something like that where thinking a bit before coding is in order.
Rails is probably not going to do well in the performance department, but I think the other metrics would be interesting to see, and require actual research, rather than just whipping up an attention-gathering headline.
This. If there is anything that has ever appealed about Rails is the ease to get started. And I think it still rocks in that regard. 90% of all apps fit the rest-style persistence in a relational database. For that, Rails is perfect.
I'm obviously biased, but I don't think any other framework can do this?
Particularly for small startups and self-funded projects, the most important factor in technology choice is almost always "How long does it take me to translate my idea into a working product?".
For me, I haven't yet found anything that matches the ability of Rails to quickly go from just an idea into something that you can start pitching to customers.
While Rails and the entire community is dizzyingly large, with rapid innovation, new libraries, and a new set of best practices seemingly every few months, this ability to quickly create stuff differentiates it from Java completely.
Rails is just the sweet spot for low enough bar of entry, power and expressiveness. It also offers you a proven way to get up on your feet easily.
But well, it's a fashion thing. People need new things, people need to kill the father, people need new chapels. Nevermind that what we have right now does the job perfectly and is lots of fun, we need something NEW.
I don't know. I'm running a business on a Rails site and it's sort of sucking right now in terms of what I can get done and how fast I can get it done. Why? Because learning rails isn't the easiest thing in the world any more especially when half of the application is custom work around to jury-rig different frameworks together.
One of the developers came to me just last week and showed me a POC in Java that was cleanly assembled, easy to understand, and lacked all the enterprisey stuff that scared me away from Java years ago. That's why I wrote the article.
I'm not burning the chapel to build a new one. I'm setting sail for the fatherland in search of Silk and Spices. (I didn't mean to make sense with that ending, but you read it, didn't you?)
It's surprising that you talk about "learning" Rails though.
I am not an entrepreneur so take this is a shovelful of salt, but I wouldn't venture into creating a business on a technology that I have to learn along the way.
Also, I am now confused that Rails is turning into Java, yet you recently saw a beautiful piece of Java. Rails is just like Java and its "darker" Enterprise Side ™, you get to pick and choose what you want to use, no one is forcing RefineryCMS and Devise and whatnot down your text editor :D
I, for one, would love to see a follow up post which discusses specific things Java allowed you to do faster/clearer/better in that context. ... if you're so inclined. It might also be neat to hear about which Java libraries were in play and how they compare to Ruby equivalents.
I don't think it's the build vs. buy trade-off, I think it is more a question of efficient platforms for vendor collaboration resulting in the emergence of voluntary standards that create efficient and open markets kind of problem. Ruby has a DIY ethic which is respectable, but there's little infrastructure to support market-wide discussions throughout the ecosystem.
Really, if you want to make analogies. Rails is essential loose federation covered under Articles of Confederation while Java is to be appreciated as a strong Federal system that allows for states to innovate.
He's trading most of the simplicity for rich pre-rolled features.
Building your own authorization/authentication and integrating with OAuth is pretty trivial, maybe a few hours if all you need is simply logging people in. Same with a CRUD CMS that'd replace refinery -- you're collecting complexity for a more rich feature set out of the box.
Rack Rewrite isn't really that complex, though Carrierwave+Fog is a complexity layer, if Fog is anything like S3 you could just be posting directly to a REST api(adding complexity in client-side JS -- my favorite kind of complexity.)
Unicorn is slightly more complicated to manage than Passenger, but, apparently you needed to serve fast clients and work on disk a lot? Well, can't be mad about what it buys you.
Honeybadger, Foreman, and New Relic are pretty much DevOps burdens, you'd probably have some form or fashion of this complexity in any web-based app, ever. AMQP is a standard, most people would need a library to interact with it -- this is sort've akin to complaining that you need a library/gem for JSON.
I wasn't even sure you needed heroku as a project dependency -- I though you just needed it locally because it acted like a CLI to their service.
Also, Sinatra is it's own framework, having nothing to do with Rails. And it certainly wouldn't trade out a lot of the dependency complexity you're dealing with.
Really, you traded simplicity for rich features out of the box. Hopefully you took the time to figure out if you actually need those features before integrating them with your app. Also, Refinery's Engine architecture is kind've hair brained.
(P.S. on chrome 24.0.1312.57 and Mountain Lion the dynamic length comment box on this blog is totally fucked.)
Right, and I'm calling Grails, Play, Scala, Vert.x Java in that article I wrote. I think a lot of Rails folks walked into a closed box in 2008, and they should have. Rails was hugely different from the alternatives back then.
The world has caught up. That's one of the points I didn't quite make very well. Ugh.
That makes sense. The landscape has definitely changed, and you're right, there are alternatives now that didn't exist when Rails was just starting.
I think Rails still has some advantages, and a head start in both development concepts and supporting libraries and frameworks. My point wasn't that Java and its kin are necessarily incapable of these things, just that Rails has had that mindset from the start, and as such deserves the mindshare that it receives.
Oh I disagree entirely. After having spend two days debugging someone's versionless Gemfile / bundler problem on my CI server, I want someone to pay for my pain.
That's not Bundler's fault. It's the fault of the person who made the versionless Gemfile.
There's really no comparison between using Bundler and mucking around with JAR files or Ant scripts in Java. I've even seen Python codebases with a Java-esque rats nest of dependencies that are just as painful to get setup correctly.
Bundler is way easier. I've never been on a Rails project where it took more than 30 minutes to get the env setup and it's in large part, thanks to Bundler. Admittedly, I haven't touched Java in a few years, but last I checked, Java had nothing like Bundler (which is a shame, because it could really use it).
Maven and POM files are the standard way of managing dependencies in Java projects. Maven's more complex than bundler, but reasonably easy to use as it is very convention oriented.
Hey, don't forget Gradle - http://www.gradle.org - Gradle syntax for declaring dependencies is similar to Maven.
But there's a very close comparison between Bundler and managing dependencies with Maven or Gradle. And there's a huge difference. Maven Central has never been compromised because they have a secure method for deploying artifacts, RubyGems? You've had a fun month with RubyGems, right?
If you are going to base your argument on a one-time security vulnerability in RubyGems, then I'm just going to get out of your way and let you troll on.
Yes. I take it you've never worked at an enterprise company before ?
Every time a new developer comes on board they just love to add new technology X
and then in the years to come other developers add Y and so on. Of course there
are developers who have to manage this.
Are you using Java or Scala with Play 2.0? Play looks like an excellent framework, but my perception is that Play 2.0 is very Scala oriented. Scala seems a bit daunting.
I'm using it with Scala. My understanding is that Play can be used without writing any Scala whatsoever.
That said, you can start with Scala as "better Java" and ramp up to its advanced features. That's how I began. At first you're just replacing for-loops with map/reduce, eventually you'll start passing around implicit variables and using for-comprehensions all over the place.
Actually what's happening is that Rails is turning into MS Access. Access is a product that famously makes 80% of what you want to do incredibly easy, and the last 20% impossible. The Rails ecosystem is growing so that you can, essentially, deploy your own MS Access, with exactly the same trade-offs.
This has got to be one of the worst analogies I've ever seen. One of Rails' core strengths is that it is written in Ruby which makes anything, even batshit-insane dynamic runtime monkeypatching possible. Not that anyone would advocate doing that as a matter of course, but the point is nothing is out of reach in a Ruby app.
First of all, it's a classic appeal to emotion; it uses hyperbole that is propped up with emotions ("You’ll find yourself staring at incomprehensible mega-frameworks maintained by developers who are unapologetic about how little they care for writing documentation", etc) and not by concrete facts. It cleverly it uses two fictitious quotes to imply it represents real people's complaints, when it's in fact the author himself making up the supposed complaints.
It also works up a strawman argument: That you can criticize Rails on the basis of a collection of frameworks that the OP apparently thinks are required to good apps. The fallacy here is that those frameworks are not needed, and their problems are not Rails' fault. Perhaps there is subculture of engine-loving Rails people out there that promote such frameworks, but I would not listen to them any more than I would listen to PHP devs.
Rails is like any other tool: What you get out of it depends on how you use it. Judicious use of gems, libs, frameworks, databases etc. is just as important as managing your own application complexity. Sorry, but complexity is bad whatever language or framework or whatever you use. If Rails is an easy target it's probably because the apparent ease of implementation makes it tempting to grow your app.
Here's a suggestion, a constructive suggestion: Try not to stuff you app with everything you can possibly think of. Login and user accounts? Belongs in a separate app. Document storage? Separate app. Image upload and scaling? Separate app. Email and SMS notifications? Separate app. Integration with external systems such that you feed data to, or from? Separate app. Computing scores or ranks or other statistics based on data? Separate app. And so on.
Use a service-oriented architecture for everything, and you will reduce the complexity of each component to a bare mimimum. For example, we use Checkpoint [1] to integrate logins (FB, Twitter, Google) through a single system, so that our apps don't need to deal with API keys or OAuth or anything; performing login in an app using Checkpoint is literally a single line of code (a redirect). Instead of using a database, most data fits into Grove [2], a structured, hierarchical, indexed data store on top of a relational database. Instead of reinventing rating and voting systems for every app, we use Kudu [3], and instead of reinventing flagging of spam or illegal content for every app, we use Snitch [4] -- just to mention a few trivial examples. Our stable of mini-apps has much more, a small ecosystem of reusable, composable tools.
By using HTTP as interface glue, we put an artificial limit on the ways that components can entangle themselves; for example, since the API deals entirely with basic JSON objects like arrays, strings and hashes, there are no surprises when you try to access the result of a call, since it will never re-enter its source (unlike, say, ActiveRecord associatons).
You are joking right, "Try not to stuff your app with everything you can possibly think of." Like providing a admin interface on Refinery as well as authentication with Devise is "everything and the kitchen sink".
Have you used Refinery? I have and wouldn't base an app on it, or even use it again for a CMS - frankly you could build the same admin features better in Rails in a couple of days, and tailor them properly to your application. Refinery is not a good model of a rails app and is probably the main reason for his problems or perception that Rails is heavy - it was a mistake to try to base an app on it and most of his gripes seem centered on that - there's a lesson there and it's not about Rails.
Rails has become lighter with 3.x and will become lighter still with 4.x - they're dropping a lot of unnecessary stuff and trying to pare it down to the minimum - an admirable direction and quite the opposite to Java, which makes this article all the more baffling. Of course it's not the perfect framework and there are plenty of options, but the complaints of the article are histrionics.
The laundry list of possible technologies in the article is absurd - RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, Heroku.
You can get started with rails on a cheap VPS and serve your first few hundred thousand users with the following very simple stack: Apache, Ruby, Passenger, Rails. Setup is a few lines in your package manager of choice, writing the app is straightforward and requires none of the software above, maintenance is running aptitude update and bundle update now and then.
Out of the stack above, Devise is quite a nice authentication solution and is the only one I'd recommend, but it's easy to roll your own, as to the rest of his list, if you don't need it, don't bother using it, none of it is required.
"An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails?
Why is the laundry list of technologies absurd, these are the technologies that I run a business on. I think what's absurd is the level of reaction in your comment. Rails people now have this defensive reaction, and I've noticed it in person as well.
It reminds me of the reaction of Java zealots in 2007. It really does. "Oh, really, you couldn't be serious, I mean it's absurd to think that Ruby...." It wasn't absurd to challenge, and neither is this challenge.
Firstly, apologies for the harsh tone and references in the 3rd person as I see from your other comments that you are the author of the article.
"An admirable direction and quite the opposite of Java." What are you talking, specifics please? Is Java a framework with features comparable to Rails?
I admit this was sloppy wording, however your article is called 'Rails, You Have Turned into Java.' :) I was comparing Rails 4 (removes lots of features/bloat), with Java Frameworks which do not have a reputation for slimming down... Of course I'm sure there are some minimal Java web frameworks out there too (sorry not familiar with many). Your article is somewhat provocative and not representative of the experience of many with Rails so I wouldn't be surprised if you encounter a defensive reaction to this sort of sentiment. That's to be expected, as was the reaction of those using Java frameworks to DHH's blowhard rhetoric when he started out with Rails.
Why is the laundry list of technologies absurd, these are the technologies that I run a business on.
They're absurd as a criticism of Rails because many of them are completely external to Rails, not required to run a website/app, and some of them are not the right choices IMHO. Rails does not require any of these components to run websites even at scale. Sure some of them might be useful, but none are essential or intrinsic to Rails.
Forgive me but I think the choice of RefineryCMS was a mistake, and if you back out of that mistake, you'd find Rails a lot more forgiving, a lot lighter, and a lot more suited to what you want to do if you're writing a large webapp with lots of components (or several interacting webapps). Problems with engines, subapps, conflicting routes etc are all based on this, and simply don't occur in most Rails apps. I've used it as a CMS for some clients and regret having done so in retrospect - it's not terrible standalone (also not great) but I can see how integrating it with an app would be a nightmare. You don't need to use meta-frameworks built on Rails to build an app, in fact I'd say it's a mistake, use a few discrete gems like devise, and just build what you want.
I am not joking. There is absolutely no reason to put an admin interface in an app.
Here is an example applicaion, let's call it Foo. It's a blogging tool:
* FooCore: This is an API exposing the data Foo that works with, and the ways to change that data. It has a Blog model, a Posting model and an Author model. It has endpoints like "GET /api/blogs", "PUT /api/blogs/:id/postings" and "GET /api/authors/:id" to create blogs and postings. It has no UI.
* FooApp: This is the user-facing frontend application. It serves the main site in HTML, JS, CSS and whatever other. It renders blogs from FooCore by calling is API. It has no logic other than presenting the UI and acting as an MVC controller and view (the M being the API). It calls the API both from its server app, as well from the browser via XMLHttpRequest.
* FooAdmin: This is the user-facing admin frontend app. It serves the "back office" admin UI for managing blogs and posts and users.
We now have a very elegant app where the division between the parts is crystal clear. The admin UI's requirements do not affect the public UI's requirements or vice versa. The underlying data model can't build up weird UI cruft because there is no UI to let sloppy devs screw it up with their laziness.
(Need a new UI -- say, you want to accept blog postings via email? Create a new app, FooEmailApp that handles only this interaction using the same API. Want to accept blog postings by fax? Create a new app, FooFaxApp. Neither frontends will have code that bogs down the other UIs. If you decide fax is dead, just delete the entire app.)
(And you can extend your own ecosystem of services organically. Need role-based permissions? Create an app for it, and wrap every HTTP verb with a check against the permission app.)
Anyway, the above app is not complete; you want login via Twitter, so we add Checkpoint into the mix. This happens:
1. When FooCore wants needs a user, it looks in its session cookie and determines which user it is.
2. If there is no user, we create a redirect to Checkpoint's /login/twitter. Checkpoint does the necessary OAuth interaction behind the scenes, stores the credentials in its store, update its own cookie, and redirects back to FooCore. (Remember, Checkpoint has no UI. It just redirects to Twitter, which displays the usual OAuth login/authorization dialog.)
3. FooCore can now use Checkpoint's cookie to determine who the logged-in user is, and it can ask Checkpoint for data such as the user's name and email. It can also create an internal User object that represents FooCore's own data about the user, such as blogs and postings.
The upshot: The app knows nothing about authentication. It outsources everything. It can focus on the important stuff.
This modular separation of concerns into separate apps sharpens your focus as a developer, and forces you to think about the data and the interactions that are necessary. Because of HTTP/REST's relative poverty, everything becomes a verb, and every verb must be designed separately.
Two other benefits: It forces you to think of reuse, since every feature becomes an opportunity to reuse a modular component. Secondly, it forces you to think of "presentation" and the divison between ugly internal state and public state, because every interface becomes much more exposed to the world; when an app becomes an API, you are subject to more scrutiny than if you were tucking the stuff away in some class somewhere in your app.
No, I'm not kidding. Back in 2006 we tried the old model of putting everything and kitchen sink (login/auth, normal UI, admin UI, promo site, email notifications, role-based permissions, statistics, visualizations, image upload etc.) into our apps. The model does not scale. The benefits of a "many small apps" model have been obvious even for relatively small applications.
I'm not defending anything. If anything I'm attacking? :-)
Every app that I need a user to access requires three requests to IT. Each application must go through a pre-approval process and a separate set of meetings to determine requirements.
That's not to mention that many applications have a view/edit distinction, requiring nearly the same page based on permissions. If you make the choice to split this page into two applications, your UI will have to be written twice rather than an if statement in the view logic. (Oh, and wait until the change request comes in..)
Maybe your system will work in small businesses and direct to customer apps. It's a non-starter in many other places.
> Every app that I need a user to access requires three requests to IT.
Then you have (voluntarily or as a result of placing yourself in such an organization) hobbled yourself and your ability to be an efficient developer.
If your escape route through a beaurocracy — in order to accomplishing your goals — is to compromise in your technical design, then you have my sympathy. That is a situation I could never tolerate personally. (Do you really use Ruby? Sounds like Java would be something an organization of this type would use.)
> That's not to mention that many applications have a view/edit distinction
That requirement is certainly not incompatible with the model.
I have to agree. I used to love rails in the beginning. I kept the source code to both Ruby 1.8.x and Rails (and Merb) easily available for browsing and it was all "understandable" at some level.
Maybe it is just laziness but in the last few years I have used almost exclusively much simpler libraries/frameworks like Compojure/Noir and Sinara - and I have lost interest in seriously reading the source to these libraries.
It seems better to have to write a little more code, but layer on top of much small libraries/frameworks.
With the LuaVM, you really can fulfill the absolute promise of 'write codebase once, run anywhere', where "anywhere = wherever you've got your LIBS+LuaVM host code running", of course.
You can do it in a compact, highly performant manner. One host binary for each supported platform, much work at the vendor layer to adopt to a common Lua dictionary/table, and the rest is .. as they say .. fat city. All nice app case logic in a comfortable, friendly language.
Java long ago become an unweildy beast replete with inane dependencies and insensitive amounts of hassle to get things in and out, whereas with the Lua stack, it seems, one need only know how to do things at least with a C stack, first, to gain immense benefit.
I daily dream, in my idle moments, of a complete OS based on a selected set of normal/plain-ol' /usr/lib C-libraries, but booting directly to Lua, for GUI and all higher-layer goodness. Such fancies are already tickled in places like LOAD81 and MOAI, and so on, and I think sort of prove the point, a little, that the VM is no longer something a vendor controls, but rather .. the developer.
As someone who is just now learning Rails, I'm loving it. Is this an actual issue that should push me away from the technology? What other technologies are there that streamline the development process as much as rails?
No, please don't let this article affect your experience with Rails. Rails is awesome. It is. It's a great framework to learn and the problems that the author of this piece was discussing are really just a critique of his own faults. He made some awful decisions about architecture and framework and now he's paying the price.
If you love constant patching for the daily critical security holes, stick with Rails.
If you love worrying where they have stuck yet another Yaml parser, and where else they are eval-ing user supplied data, stick with Rails.
If you prefer a bit of an easier, less-stressful life, there is hope with many of the Perl, Python and PHP frameworks.
The fact that the Rails team quickly responds to vulnerabilities should be reassuring not a disincentive to use the framework. All software is subject to vulnerabilities - the recent issues with YAML are a class of exploit common across many frameworks in different ecosystems (Django's TastyPie had a similar issue in the past).
Yes, Django took a solid step to properly fix the underlying issue, rather than apply many small sticky-plasters over several days instead, leaving the same basic vector open in the meantime. In fact, the Django issue reported was posted on HN yesterday and the comments on that posting underline what I just said here.
I think Rails is following the footprints of the Wordpress eco-system. The once 'blogging-only' platform has now matured into a complex, component based, 'also-a-do-it-yourself-CMS' with so much code that just makes it fragile.
I'd love to see anyone write something custom based out of Wordpress and not have it automatically break in the next few updates. I believe this is the same case for Rails too. One day you would update your gems only to find out that something on your site (devise? Carrierwave??) would be broken. I guess, the best approach would be to make it modular - You know, write some custom classes and inherit them when you need them, instead of depending what the framework provides you 'out-of-the-box', of course not to the point of making the framework itself redundant.
I actually had to write some Java recently for the first time in about ten years. I was hoping that the evolution of the language would make it less painful than it used to be.
I was unimpressed. Generics are better than nothing, but still dramatically worse than having a reasonable syntax for anonymous closures. The newer iterator syntax is better than nothing, but still maddeningly lacking in the most basic type inference -- any compiler that can't infer the type of "thing" here is stupid:
ArrayList<MyClass> list = this.buildList();
for (MyClass thing: list){
...
}
The programmer is still forced to overspecify and manually convert between types like ArrayList<Thing> and Thing[], even though 95% of the time the difference has no impact worth thinking about.
I could go on, but my point is that people like me who dislike Java dislike it for fundamental reasons. We're not going to be converted, because the changes we would demand would probably horrify Java's core audience.
My bank uses a security module written in Java. I had to switch from Google Chrome to Firefox because Java 7 for Mac doesn't have a compatible version for Chrome.
I disagree. It's just as easy to set up a simple web app in Rails now as it was then. Rails may have grown in complexity, but it didn't add complexity to the easy thing.
"Sure, Rails itself is straightforward, but the frameworks you slap on top of it can quickly become burdensome abstractions"
I agree. However, I think it's so much easier to avoid these burdensome abstractions if you choose than it was in Spring when it first hit the scene. If you wanted to do something simple, I think it was far easier to write lower level servlet and jdbc code than to get spring mvc, hibernate, and some sort of build too (probably maven) all working together properly.
There were some good efforts. There seemed to be some enthusiasm about Roo, though I didn't find the code generated by Roo anywhere near as easy to work with as Rails code. I thought Play looked promising, though it wasn't enough to get me back to Java once I'd built some momentum with Rails.
A few people have commented that Spring 3 is excellent. It may very well be, and maybe I'll take a look some time, but to say I'm once bitten twice shy is to greatly undercount the number of times I was bitten.
Definitely write the Spring 3 blog post! I can't get deep into it right now, but I'd be interested in an overview, especially from someone who uses Rails as well.
I still remeber reading some blog post comparing the stack trace of a spring/tomcat web app and a rails web app. Blah blah the rails web app stack was much nicer to read. Well, in 2012, the rails stack trace has become the tomcat's stack trace. It seems that if you really need to implement alot of abstractions on a webapp for generic pipe/filter, interception, routing, param parsing, session managemnt and such, you really do need some layers in your app!
And I think it's funny that some of the Java-ey concepts that spring made so popular like IoC are beginning to appear in frameworks such as angular.js - this is not a critique, I think IoC is really clever.
As for JSF, I actually like JSF2. It's really not everyone's cup of tea, but it's quite good for those boring LOB apps. Oh and it's view-first! I don't know why there aren't more view-first frameworks. The other ones I know of are Lift, WPF (kinda, never really used intensively), angular.js (has a view-first feel to it).
Anyway, I still like rails, I just think they were a bit premature in judging the java camp...
Couldn't be more timely for me. I've been working on documenting the Discourse installation. For someone who doesn't work in Ruby every day, even as a long time Linux user, it is daunting.
Once an application, no matter the language, has a significant number of external dependencies deploying it becomes a challenge.
Post title seems like it should be, "Refinery is a messy CMS".
Seems like a good portion of these comments are comparing simple code written in (other-framework/language) with a big messy CMS written as an add-on for Rails. Hardly apples-to-apples comparisons, and only tangentially about Rails to begin with.
Nobody wins by just using programming language Y or framework X. Product, features, design, execution etc is what make you wins. Facebook won in social-networking using php, some other social networks were build in Java and failed. Amazon won using Perl. Instagram used python/django and got acquired for a billion. Yammer used ruby/ rails and was acquired for 1.2 billion.
In reality most companies are polyglot using different languages, tools and frameworks for different features in their stack.
I am personally tied of unnecessary rants. There is no perfect programming language or framework.
Abandon the notion that there's a "right framework," and just choose one and get hacking.
Ok, I get the complaint, and I understand and sympathize with the author. But just doing a simple search for "spring 3 hello world" was enough to remind me to stay away.
You're doing it wrong! Do not slap frameworks and complexity on top of Rails. Rails' strength has been unchanged from day 1 - "favoring convention over configuration".
Rails is for building web apps. 99% of the world's web apps will work fine with Rails, an RDMBS, a web server. That's about all you need. Anything else is probably just developers wanting to play with the latest toys.
So yes, if you try to avoid Rails' conventions, you will have trouble. But it's not Rails' fault.
Let me try another way. Some Rails apps that are too unwieldy are barely even Rails apps. They just happen to have Rails at some layer of the tech stack, but also have many other non-Rails components such that saying "Rails" has become too complex is disingenuous.
Cheapshot: Rails HAS turned into Java, in so much both are riddled with security holes.
Longer-term view: Rails mocked the Java web eco-system in the early days because it was 'Enterprise', and Rails was the scrappy upstart with magic commands to scaffold a blog in 5 mins and show screencasts to the world. This sold a lot of books (without it would Pragmatic Programmer have even had a book store?).
Slowly, the rot set it, and the once light and nimble Rails become bloated as everyone added their pet features, their design pattersn (even though they would never call them that - that is so Java!), and the too-many-cooks-in-the-code-kitchen sprinkling so much magic and syntactic sugar around the codebase it practically causes diabetes.
Rails solved a problem for the company that wrote it. Since then people have been trying to shoe-horn it work with their business problem, and then found once they now have two problems.
"RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, not to mention the extra magic that Heroku gems throw into the mix (backups and other fun)."
Just going through all those names makes me tired. Its like framework names are to software as band names are to bands.
"One of the basic tenets of the Python language has been that code should be simple and clear to express and to read, and Ruby has followed this idea, although not as far as Python has because of the inherited Perlisms. But for someone who has invested Herculean effort to use EJBs just to baby-sit a database, Rails must seem like the essence of simplicity. The understandable reaction for such a person is that everything they did in Java was a waste of time, and that Ruby is the one true path."
http://www.artima.com/weblogs/viewpost.jsp?thread=141312