9 ms·

Rails Has Turned into Java

136 points by urlwolf 14y ago

lkrubner 14y ago
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." http://www.artima.com/weblogs/viewpost.jsp?thread=141312 http://www.artima.com/weblogs/viewpost.jsp?thread=141312
- adventureloop 14y ago
  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.
  - lkrubner 14y ago
    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.
    - aantix 14y ago
      Curious, what other web dev frameworks offer a unified stack (ORM, deployment, dependency management, testing, project structuring)?
      - Thieum22 14y ago
        ASP.NET MVC + Entity Framework + NuGet could be a candidate. At least it's going in this direction.
      - taligent 14y ago
        Play and Grails are two on the Java side.
        jshen 14y ago
        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.
      - programminggeek 14y ago
        Offering all of those things is nice, but tightly coupling them all together is where Rails goes wrong many/much of the time.
        jshen 14y ago
        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?
    - douglasisshiny 14y ago
      I don't doubt that this is the case, but can you mention some of the language / frameworks which have done this? (I'm not being critical; I'm really just curious and would like to learn about different frameworks).
  - jules 14y ago
    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). Does anybody remember this video: https://www.youtube.com/watch?v=Gzj723LkRJY https://www.youtube.com/watch?v=Gzj723LkRJY 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.
    - jshen 14y ago
      I have yet to see any competition that is better. What do you think is better?
      - jules 14y ago
        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.
        jshen 14y ago
        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.
        14y ago
  - currywurst 14y ago
    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.
    - adventureloop 14y ago
      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.
    - mbell 14y ago
      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.
      - markokocic 14y ago
        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.
      - tmo9d 14y ago
        Ah, watch out for JSF, it's a dangerous place. JPA on the other hand is surprisingly good these days try Spring 3 Oliver Gierke has done good things.
        mbell 14y ago
- jgjgcghjhhbfv 14y ago
  You have to be an idiot if you actually bought the crap about EJBs. The first time I heard about them I said "What is this bulls*t" and swore never to touch it. It is one of those sins that you hope never to repeat again. I continued writing Java server code and never used that. Everyboy I knew thought the same thing. And yet I'm still able to progrAm in Java.
- fusiongyro 14y ago
  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.
vampirechicken 14y ago
It's the age old set of trade-offs between buy and build. Build it all yourself and it takes forever, but you understand it all. Buy it from somebody else, and you get it quickly, but you're at their mercy for efficient understandable code. No language or framework is immune. Enjoy your java.
- tmo9d 14y ago
  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.
calinet6 14y ago
"... Java, have you learned to easy yet?" No, it hasn't. That's why we're using Rails. And to be honest, it ain't that bad.
- taligent 14y ago
  "... Java, have you learned to easy yet?" Try Play, Grails, Vert.X. And you know what it isn't easy. Having to deal with Ruby's dependency nightmares.
  - spellboots 14y ago
    Dependency management in ruby is trivial with bundler.
    - taligent 14y ago
      For small, single apps sure. But if you have large apps with multiple Ruby versions then dealing with rvmrc, bundler and gem incompatibilities is a nightmare. Java's forward compatibility is a lot more robust.
      - jdminhbg 14y ago
        You have an app with multiple Ruby versions?
        taligent 14y ago
        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.
        calinet6 14y ago
        Enterprise company? Ha. Just try dealing with three different decade-old JVM versions once. You'll pray for bundler.
axlerunner 14y ago
To answer the question...Yes, Java has changed for the better. Give it a go...you'll be impressed.
- Cigano 14y ago
  Changed so much that version 7 does not support 32-bit applications anymore. I was impressed, for real.
  - taligent 14y ago
    Really ? That is not what the installation guide says: http://docs.oracle.com/javase/7/docs/webnotes/install/index.html http://docs.oracle.com/javase/7/docs/webnotes/install/index....
    - Cigano 14y ago
      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. Mysteries from Oracle.
- ef4 14y ago
  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.
kevinconroy 14y ago
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.
- tmo9d 14y ago
  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 know this makes me sound old. I own that.
  - kevinconroy 14y ago
    I, for one, welcome our W3C overlords.
    - tmo9d 14y ago
      Oh c'mon it's much much worse than that. Oracle runs the JCP not the W3C. And, yes, I admit it, I'm a jerk.
  - nathanappere 14y ago
    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)
throwaway420 14y ago
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.
- VeejayRampay 14y ago
  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.
  - tmo9d 14y ago
    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?)
    - ziel 14y ago
      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.
squidsoup 14y ago
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.
- tmo9d 14y ago
  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.
  - squidsoup 14y ago
    An article comparing Spring 3 to Rails, enumerating some of those solutions, would have been more informative.
  - packet 14y ago
    I suspect most that complain about Java and have written JEE code in the past have never seen Spring 3.
hnwh 14y ago
hope that means I have job options for another decade
lkrubner 14y ago
The pushback against Ruby/Rails has been building for a long time. There's always been jokes about Ruby being slow: http://harmful.cat-v.org/software/ruby/ http://harmful.cat-v.org/software/ruby/ 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-stop-worrying-and-love-the-threads 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: http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto 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".
- BonoboBoner 14y ago
  Thanks for posting the link to the rant. My plans to go to bed early have been shattered.
- phillmv 14y ago
  Uhm. We deployed a new server last night. `cap staging deploy:setup` `cap staging deploy` `cap staging deploy:migrate` You do have to know how to setup Unicorn but…
ExpiredLink 14y ago
Java is like a truck, Rails like a bicycle. Rails cannot turn into Java because it lacks the capabilities to turn into Java.
- tmo9d 14y ago
  No Java is like a Lepton and Rails is like a Neutrino. Neither interact with the Strong force. Got it?
jgjgcghjhhbfv 14y ago
Jaaaaajajajajahajahajajajajaj
neya 14y ago
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.
Amanda_Panda 14y ago
"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.
danielsju6 14y ago
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.
- tmo9d 14y ago
  Who said anything about Dynamic typing? 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).
  - evilduck 14y ago
    It was a joke/metaphor about Ruby's duck typing, not a literal reference.
- dmpk2k 14y ago
  Kindly refrain from swearing, all caps, and 4chan-isms. I prefer to not read that kind of noise, and no doubt others here feel the same.
  - danielsju6 14y ago
    It was a sensational claim, I'm responding with "sensation". Since we're talking Rails I'll leave this here for you http://david.heinemeierhansson.com/posts/15-potty-mouths http://david.heinemeierhansson.com/posts/15-potty-mouths
- stuff4ben 14y ago
deleted 14y ago
[deleted]
Skoofoo 14y ago
> 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.
- tmo9d 14y ago
  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.
  - Skoofoo 14y ago
    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. [1] http://www.farbeyondprogramming.com/2011/05/rails-user-authentication-using-has_secure_password/ http://www.farbeyondprogramming.com/2011/05/rails-user-authe... [2] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
RyanZAG 14y ago
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.
- runT1ME 14y ago
  >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: http://news.ycombinator.com/item?id=4939624 http://news.ycombinator.com/item?id=4939624
- fleitz 14y ago
  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.
  - cglee 14y ago
    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.
t4nkd 14y ago
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.)
davidw 14y ago
Flame-bait title if I've ever seen one. Let's see an actual comparison with some numbers: * 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.
- tmo9d 14y ago
  You want that. Ok? I'm not sure you are going to like the results. But, if you want a follow up, I'll happily supply it.
  - davidw 14y ago
    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.
- artsrc 14y ago
  If those are the metrics you care about, then I think you should go with PHP.
- nchuhoai 14y ago
  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?
cmbaus 14y ago
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.
rzendacott 14y ago
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?
- tmo9d 14y ago
  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. Ignore this idiot and continue on. Also, I wrote the original piece.
- static_typed 14y ago
  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.
  - squidsoup 14y ago
    Like the Django patch that was released yesterday? (https://www.djangoproject.com/weblog/2013/feb/19/security/ https://www.djangoproject.com/weblog/2013/feb/19/security/) 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).
    - static_typed 14y ago
      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. Remember - Python for Pros, Ruby to pose.
lobster_johnson 14y ago
Sorry, but this article is bullshit. 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). [1] https://github.com/bengler/checkpoint https://github.com/bengler/checkpoint [2] https://github.com/bengler/grove https://github.com/bengler/grove [3] https://github.com/bengler/kudu https://github.com/bengler/kudu [4] https://github.com/bengler/snitch https://github.com/bengler/snitch
static_typed 14y ago
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. The rest of us moved on.
joedev 14y ago
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.
javajosh 14y ago
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.
- dasil003 14y ago
  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.
  - javajosh 14y ago
    Rails has monkeypatching. Access has COM. Inbound developers will not be able to use either of these things because their skills and expectations have been set by that easy 80%.
    - danielsju6 14y ago
      Monkey-patching really? You're forgetting what else Rails has in our ecosystem: Github. 1.) Fork a project on Github, say the push notification gem https://github.com/jpoz/APNS https://github.com/jpoz/APNS 2.) Alter behavior in your branch https://github.com/jamesdaniels/APNS https://github.com/jamesdaniels/APNS 3.) Optional bit, send a pull-request with your changes 4.) Vendor it or require your fork in the Gemfile: gem 'apns', :git => 'git@github.com:jamesdaniels/APNS.git' Tada!
      - mtarnovan 14y ago
        shortcut: gem 'apns', :github => 'jamesdaniels/APNS'
        danielsju6 14y ago
jscheel 14y ago
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.
joedev 14y ago
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.
Legion 14y ago
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.
geebee 14y ago
"Rails isn't the easy framework it once was..." 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.
- tmo9d 14y ago
  Spring 3 is excellent BTW. I originally started to blog about a Spring 3 application I wrote, but then it turned into this Rails rants. And, I don't hate Rails at all. Really. I don't.
  - geebee 14y ago
    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.
mark_l_watson 14y ago
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.
throwa 14y ago
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.
mping 14y ago
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...
primitur 14y ago
You know what has become the "Best Java" for me? Lua. 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.

136 points by urlwolf 14y ago

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." http://www.artima.com/weblogs/viewpost.jsp?thread=141312 http://www.artima.com/weblogs/viewpost.jsp?thread=141312

adventureloop 14y ago
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.
- lkrubner 14y ago
  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.
  - aantix 14y ago
    Curious, what other web dev frameworks offer a unified stack (ORM, deployment, dependency management, testing, project structuring)?
    - Thieum22 14y ago
      ASP.NET MVC + Entity Framework + NuGet could be a candidate. At least it's going in this direction.
    - taligent 14y ago
      Play and Grails are two on the Java side.
      - jshen 14y ago
        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.
    - programminggeek 14y ago
      Offering all of those things is nice, but tightly coupling them all together is where Rails goes wrong many/much of the time.
      - jshen 14y ago
        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?
  - douglasisshiny 14y ago
    I don't doubt that this is the case, but can you mention some of the language / frameworks which have done this? (I'm not being critical; I'm really just curious and would like to learn about different frameworks).
- jules 14y ago
  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). Does anybody remember this video: https://www.youtube.com/watch?v=Gzj723LkRJY https://www.youtube.com/watch?v=Gzj723LkRJY 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.
  - jshen 14y ago
    I have yet to see any competition that is better. What do you think is better?
    - jules 14y ago
      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.
      - jshen 14y ago
        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.
        14y ago
- currywurst 14y ago
  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.
  - adventureloop 14y ago
    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.
  - mbell 14y ago
    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.
    - markokocic 14y ago
      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.
    - tmo9d 14y ago
      Ah, watch out for JSF, it's a dangerous place. JPA on the other hand is surprisingly good these days try Spring 3 Oliver Gierke has done good things.
      - mbell 14y ago
jgjgcghjhhbfv 14y ago
You have to be an idiot if you actually bought the crap about EJBs. The first time I heard about them I said "What is this bulls*t" and swore never to touch it. It is one of those sins that you hope never to repeat again. I continued writing Java server code and never used that. Everyboy I knew thought the same thing. And yet I'm still able to progrAm in Java.
fusiongyro 14y ago
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.

vampirechicken 14y ago

It's the age old set of trade-offs between buy and build. Build it all yourself and it takes forever, but you understand it all. Buy it from somebody else, and you get it quickly, but you're at their mercy for efficient understandable code. No language or framework is immune. Enjoy your java.

tmo9d 14y ago
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.

calinet6 14y ago

"... Java, have you learned to easy yet?" No, it hasn't. That's why we're using Rails. And to be honest, it ain't that bad.

taligent 14y ago
"... Java, have you learned to easy yet?" Try Play, Grails, Vert.X. And you know what it isn't easy. Having to deal with Ruby's dependency nightmares.
- spellboots 14y ago
  Dependency management in ruby is trivial with bundler.
  - taligent 14y ago
    For small, single apps sure. But if you have large apps with multiple Ruby versions then dealing with rvmrc, bundler and gem incompatibilities is a nightmare. Java's forward compatibility is a lot more robust.
    - jdminhbg 14y ago
      You have an app with multiple Ruby versions?
      - taligent 14y ago
        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.
        calinet6 14y ago
        Enterprise company? Ha. Just try dealing with three different decade-old JVM versions once. You'll pray for bundler.

axlerunner 14y ago

To answer the question...Yes, Java has changed for the better. Give it a go...you'll be impressed.

Cigano 14y ago
Changed so much that version 7 does not support 32-bit applications anymore. I was impressed, for real.
- taligent 14y ago
  Really ? That is not what the installation guide says: http://docs.oracle.com/javase/7/docs/webnotes/install/index.html http://docs.oracle.com/javase/7/docs/webnotes/install/index....
  - Cigano 14y ago
    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. Mysteries from Oracle.
ef4 14y ago
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.

kevinconroy 14y ago

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.

tmo9d 14y ago
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 know this makes me sound old. I own that.
- kevinconroy 14y ago
  I, for one, welcome our W3C overlords.
  - tmo9d 14y ago
    Oh c'mon it's much much worse than that. Oracle runs the JCP not the W3C. And, yes, I admit it, I'm a jerk.
- nathanappere 14y ago
  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)

throwaway420 14y ago

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.

VeejayRampay 14y ago
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.
- tmo9d 14y ago
  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?)
  - ziel 14y ago
    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.

squidsoup 14y ago

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.

tmo9d 14y ago
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.
- squidsoup 14y ago
  An article comparing Spring 3 to Rails, enumerating some of those solutions, would have been more informative.
- packet 14y ago
  I suspect most that complain about Java and have written JEE code in the past have never seen Spring 3.

hnwh 14y ago

hope that means I have job options for another decade

lkrubner 14y ago

The pushback against Ruby/Rails has been building for a long time. There's always been jokes about Ruby being slow: http://harmful.cat-v.org/software/ruby/ http://harmful.cat-v.org/software/ruby/ 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-stop-worrying-and-love-the-threads 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: http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto 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".

BonoboBoner 14y ago
Thanks for posting the link to the rant. My plans to go to bed early have been shattered.
phillmv 14y ago
Uhm. We deployed a new server last night. `cap staging deploy:setup` `cap staging deploy` `cap staging deploy:migrate` You do have to know how to setup Unicorn but…

ExpiredLink 14y ago

Java is like a truck, Rails like a bicycle. Rails cannot turn into Java because it lacks the capabilities to turn into Java.

tmo9d 14y ago
No Java is like a Lepton and Rails is like a Neutrino. Neither interact with the Strong force. Got it?

jgjgcghjhhbfv 14y ago

Jaaaaajajajajahajahajajajajaj

neya 14y ago

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.

Amanda_Panda 14y ago

"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.

danielsju6 14y ago

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.

tmo9d 14y ago
Who said anything about Dynamic typing? 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).
- evilduck 14y ago
  It was a joke/metaphor about Ruby's duck typing, not a literal reference.
dmpk2k 14y ago
Kindly refrain from swearing, all caps, and 4chan-isms. I prefer to not read that kind of noise, and no doubt others here feel the same.
- danielsju6 14y ago
  It was a sensational claim, I'm responding with "sensation". Since we're talking Rails I'll leave this here for you http://david.heinemeierhansson.com/posts/15-potty-mouths http://david.heinemeierhansson.com/posts/15-potty-mouths
stuff4ben 14y ago

deleted 14y ago

[deleted]

Skoofoo 14y ago

> 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.

tmo9d 14y ago
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.
- Skoofoo 14y ago
  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. [1] http://www.farbeyondprogramming.com/2011/05/rails-user-authentication-using-has_secure_password/ http://www.farbeyondprogramming.com/2011/05/rails-user-authe... [2] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus

RyanZAG 14y ago

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.

runT1ME 14y ago
>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: http://news.ycombinator.com/item?id=4939624 http://news.ycombinator.com/item?id=4939624
fleitz 14y ago
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.
- cglee 14y ago
  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.

t4nkd 14y ago

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.)

davidw 14y ago

Flame-bait title if I've ever seen one. Let's see an actual comparison with some numbers: * 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.

tmo9d 14y ago
You want that. Ok? I'm not sure you are going to like the results. But, if you want a follow up, I'll happily supply it.
- davidw 14y ago
  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.
artsrc 14y ago
If those are the metrics you care about, then I think you should go with PHP.
nchuhoai 14y ago
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?

cmbaus 14y ago

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.

rzendacott 14y ago

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?

tmo9d 14y ago
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. Ignore this idiot and continue on. Also, I wrote the original piece.
static_typed 14y ago
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.
- squidsoup 14y ago
  Like the Django patch that was released yesterday? (https://www.djangoproject.com/weblog/2013/feb/19/security/ https://www.djangoproject.com/weblog/2013/feb/19/security/) 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).
  - static_typed 14y ago
    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. Remember - Python for Pros, Ruby to pose.

lobster_johnson 14y ago

Sorry, but this article is bullshit. 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). [1] https://github.com/bengler/checkpoint https://github.com/bengler/checkpoint [2] https://github.com/bengler/grove https://github.com/bengler/grove [3] https://github.com/bengler/kudu https://github.com/bengler/kudu [4] https://github.com/bengler/snitch https://github.com/bengler/snitch

static_typed 14y ago

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. The rest of us moved on.

joedev 14y ago

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.

javajosh 14y ago

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.

dasil003 14y ago
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.
- javajosh 14y ago
  Rails has monkeypatching. Access has COM. Inbound developers will not be able to use either of these things because their skills and expectations have been set by that easy 80%.
  - danielsju6 14y ago
    Monkey-patching really? You're forgetting what else Rails has in our ecosystem: Github. 1.) Fork a project on Github, say the push notification gem https://github.com/jpoz/APNS https://github.com/jpoz/APNS 2.) Alter behavior in your branch https://github.com/jamesdaniels/APNS https://github.com/jamesdaniels/APNS 3.) Optional bit, send a pull-request with your changes 4.) Vendor it or require your fork in the Gemfile: gem 'apns', :git => 'git@github.com:jamesdaniels/APNS.git' Tada!
    - mtarnovan 14y ago
      shortcut: gem 'apns', :github => 'jamesdaniels/APNS'
      - danielsju6 14y ago

jscheel 14y ago

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.

joedev 14y ago

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.

Legion 14y ago

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.

geebee 14y ago

"Rails isn't the easy framework it once was..." 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.

tmo9d 14y ago
Spring 3 is excellent BTW. I originally started to blog about a Spring 3 application I wrote, but then it turned into this Rails rants. And, I don't hate Rails at all. Really. I don't.
- geebee 14y ago
  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.

mark_l_watson 14y ago

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.

throwa 14y ago

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.

mping 14y ago

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...

primitur 14y ago

You know what has become the "Best Java" for me? Lua. 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.