Rails, You Have Turned into Java. Congratulations!

Rails isn’t the easy framework it once was, age has brought along a good deal of complexity both in the way Rails applications are deployed and in the number of technologies you need to assemble together to get anything meaningful done.

Update (2/20/13): Hello all, one additional note.   I’m surprised to be saying this, but I think the key difference between Rails and Java is that the Java “ecosystem” has this imperfect, somewhat ad-hoc standards group called the JCP.  This means that Hibernate and MyBatis or Spring and Oracle aren’t just pulling another framework out of thin air, they have to agree on standards and APIs.   This slows things down a bit, but, in the long run, this makes things more interchangeable.   It’s odd for me to write this because I’ve railed against the JCP for years, but I do think that Rails is a picture of what happens to “frameworks” in the absence of standards.   Call me old for saying it, but I did.  So there.

Frameworks atop Frameworks atop Opaque Hosting Platforms

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

Why is the site slow today?  I don’t know maybe AWS is having problems?  Nope.  Ok, maybe the Unicorn configuration is screwy?  No.   Alright, everything works except Refinery take a look at New Relic.   That didn’t help.   Ok, let’s restart the application.   Great, that fixed it.  Why?  Not sure.  Was it a worker thread that was stuck?  Who knows, and who cares the site works now…

Maybe I’m reacting more to Heroku’s recent unpredictably and mysterious performance issues.   Maybe, I’m not fully dissatisfied with Rails or Ruby, but I can’t help but notice that Rails has become heavier these days.

Is it the complexity that Refinery brings to the table?  Maybe.  Refinery does what it does, but it is something of a beast.   If you follow the rules closely, you’ll end up developing a Rails application with an excessive number of Engines, which is really just another way of saying that you’ll be fumbling through a messy file explosion.  (What view is that engine in?   Hold on, let me click through five levels of folders….)    There are those of you who will shout “Sinatra, you should use Sinatra?”  But that’s really not what I came to Rails for.

I know I have unrealistic expectations.  I want it all, and I want it to be easy: I want straightforward defaults, but I also want customizations to be things I can understand.    Take the intersection of Devise, Refinery, and Omniauth as an example.  All three of these frameworks are first-class, don’t get me wrong.   (I lied, Devise and Omniauth are first-class, and Refinery is an awful mess.) Making them work seamlessly together is an obtuse nightmare  – a documentation desert littered with wreckage.

Frameworks that Eat Frameworks don’t like it when you Customize the Frameworks they Eat

The problem is really that once you start making use of Rails and all of the frameworks built atop of Rails you end up creating an opaque mess of customization.   One framework, say Refinery depends on something like Devise.   Customize anything and good luck upgrading.

Who really knows what happens during the login process?  Oh, I know, we’ll use RubyMine to step through this unpredictable mess.     I need to make a simple change to how routes work… oh look Routes have become incomprehensible because you now have 12 difference Refinery engines.

You’ll find yourself staring at incomprehensible mega-frameworks maintained by developers who are unapologetic about how little they care for writing documentation.     You’ll also end up with the most common pattern from Hell: the single Rails application that runs an entire business.

I’m starting to think that Rails has turned into the new Java, and that it is time to return to Java and ask it a simple question…

…Java, have you learned to “easy” yet? 


67 thoughts on “Rails, You Have Turned into Java. Congratulations!

  1. If you’re adamant to go back to Java looking, I hear good things about Play. If you’re more adventurous and prepared to learn a new language while at it, Scala with Play2 is quite nice. Both dialects of Play replicate much of what once made Rails nice, including hot reloading on edit.

    If you’re even more adventurous and not put off by the parenses of Lisp, Clojure is a beautiful language well worth learning that will change the way you think about software. The community is excellent, there are many good libraries available and people really “get” the “simple” part.

  2. […] Programming News: Rails, You Have Turned into Java. Congratulations! Rails isn’t the easy framework it once was, age has brought along a good deal of complexity both in the way Rails applications are deployed and in the number of technologies you need to assemble together to get anything meaningful done. 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). Read full story => Discursive […]

  3. Any “framework” naturally follows this progression. Something is complex so someone does something to make it easier. Everyone rushes to it but needs one or two things from the technologies they left behind so they introduce that into the “new” framework. Over the years everyone’s edge cases are accounted for with frameworks on top of frameworks and suddenly everyone is looking for the next big simplification.

    It’s always death by a thousand cuts.

  4. I disagree. Java is way ahead of Rails until now. Rails is much better. However, the issue usually is people getting into the habit of taking things for granted. It is funny how wrong choice of gems usually just saves some development time but makes the application slow. Nokogiri is a fine example. It is at least 10 times faster than pure Ruby parsers like REXML. Even after that if someone uses REXML, that is a blunder. After handling heavy traffic on rails applicatons, I have learnt that correct choice of gems goes a long way in the long run.

  5. I mostly agree, but I think the Spring Framework has done a good job adapting to change and also avoiding the creation of a monolithic beast. (Some would clearly disagree with that assessment.) Spring works because, while they attempt to solve all problems, they’ve provided clear exit lanes for people that don’t want to follow the convention. When I use rails I feel like the conventions shift suddenly, add frameworks atop Rails and I just feel like I’m further removed from being able to customize anything without understanding too much abstraction.

    Java seems healthier these days because (and I can’t believe I’m saying this) there is no Rails, there are a series of utility-like standards defined by the JCP, I have options and alternatives at almost every level, and the contracts that they satisfy are both well defined and leave in enough room to innovate. It sounds like marketing, but it isn’t. I promise.

  6. Gem selection and performance isn’t my complaint. It is the complexity of the various abstractions – Rails itself provides a model for Web MVC and providing APIs, slap a framework for a simple CMS atop it + a framework for authentication and you suddenly have this situation where you are not developing a Rails app per se, it’s a Refinery application with a bunch of custom hacks to make Devise work with OmniAuth. Rails has an upgrade, good luck with that, you’ll be fighting battles between frameworks.

    And, why, it is because the Ruby world lacks a set of standards and APIs above the language. Yes, you can get it to work. I like Rails, I still use it, but I just don’t see it as a sustainable option for continued development.

  7. Hello Tim!

    I’m one of the guys behind Refinery.

    Could you please elaborate on “Refinery is an awful mess” a bit more? Is there something we can do to make it less awful?

  8. You’re 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 like CMS that’d replace refinery — you’re collecting complexity for a more rich feature set out of the box.

    Same with Unicorn(you could just run a fire-and-forget with Apache+Passenger). 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.)

    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 this dynamic length comment box is totally fucked.)

  9. So glad I made the decision last year to learn Python and Django instead of Ruby on Rails. Simplicity and transparency triumph.

  10. But, but… You know, I’m not going to argue here because you took time to comment and I think we just have a style disagreement.

    I don’t think I traded simplicity for rich features out of the box, I think I focused on the requirements of the application. Why build OAUTH integration out of thin air when Omniauth has support for so many providers out of the box? Why reimplement a CMS when Refinery does it for you? These are especially important questions if you are thinking about what to spend time on to deliver value to a paying client. For me, I was not comfortable spending time on the finished.

    My main “beef” isn’t with the individual frameworks it is with the tangled mess that I’ve ended up with. A sort of a DLL-hell of dependency frameworks which cause me to ask the same questions you asked in your comment: “Why didn’t I just do this all from scratch? It may have been easier.” but, if that’s the question they I might not have selected Rails in the first place.

    Anyway, I’m sure if you were right next to me you’d just punch me in the face and we’d go out for a beer and get along well after that. But, we’re not in the same place so let’s just end with what we agree upon Refinery’s Engine architecture is kind’ve hair brained.

  11. Interesting article in that I think you have a point, but perhaps got lost in a few details.

    For instance: Refinery is a CMS written in Rails. You can’t expect “the Rails ecosystem” to bear responsibility for this. Devise/OmniAuth are indeed complex BUT they scale perfectly well in terms of complexity.

    Plug in the gem, and do what it tells you and you’re done. Need to customize it? Just look at the initilalizer – it holds your hand the whole way.

    Unicorn is an application server, it works on top of Rack. You don’t need to know a thing about it to use Rails (it’s for production use anyway). New Relic is a 3rd party monitoring service that works in a myriad of platforms – suggeting it’s a “framework” is like suggesting Google Analytics is a framework – it sort of is, but really isn’t.

    If I had to guess – it would be that you’re having a really hard time getting Refinery to run properly on Heroku? And yes, I can totally understand the issues thus. I had ALL KINDS of issues with Heroku when I moved Tekpub over but that’s not really a Rails issue.

    Maybe it would be worth your while to use Linode and one of their Rails stack scripts for spinning up a Rails server? I won’t suggest deployment and server setup is simple with Rails – but I do think it’s not all that hard.

  12. Sure, Rails isn’t responsible for Refinery, totally agree. And I want to make sure that I’m differentiating Refinery from both Devise and Omniauth which are great frameworks.

    I’ll certain revisit this idea after moving off of Heroku. Not only have I noticed that Heroku has degraded over time, but I’ve noticed a brain drain. All the really smart people I followed who worked Heroku have left (and I won’t name names). I do think that Heroku post the Salesforce non-acquisition, well something happened there. I don’t know if Salesforce made good on its promise not to ruin a good thing.

  13. A lot of this is what you get when you tightly couple components to a framework. So much ruby code is tightly coupled to rails which is tightly coupled to a database, that your architecture is a big ball of mud. It doesn’t have to be that way, but programmers are lazy and don’t try to fix the mess until it is super gross and requires the dreaded “full rewrite”.

    It’s not just a rails problem and Java certainly isn’t much better in many regards. As long as your codebase is a series of components that are tightly coupled to a framework and a database you’re going to end up with a mess eventually.

  14. You have pretty much read my thoughts…Rails as an ecosystem has become more and more complicated, and the dynamic nature of ruby…while nice for short programs…makes navigating this ecosystem very difficult. It’s sad that Java hasn’t come along faster than it has. I personally hold out a lot of hope for Kotlin.

  15. I was doing Java web dev in the early and mid 2000’s and part of the problem was there were “options and alternatives at almost every level”. The promise of Rails was that the decisions were made for you and you could just focus on the business logic of your application. Naturally over time people want to make everything configurable so you end up going back to the mess where there’s 10 ways to do every simple thing.

  16. I’ve been pondering this sentiment for quite a while. I did Rails for a little while back in the early Rails 2 days. However, for whatever reason, I got out of Rails, but I kept seeing it come up time and time again, and the general idea was that the Rails community was the community really driving the web forward. When I re-approached trying to ‘relearn’ Rails again (this time, much later in the mid Rails 3 days), I was pretty much overwhelmed. Now, this is no fault of the framework, but from an outside observer, the framework, tools, ideology, and community was generally overwhelming, and I have yet to jump back into it. My general sentiment was, I had no idea how or where to start. There seemed to be so many Rails-esque ways to do stuff and it was just generally overwhelming. I’m curious if others feel the same way.

  17. Great write up. I’d second your opinion that SpringSource has done an excellent job drawing lines in the sand. They’ve got a project for nearly anything you want to do on the JVM, but you can pick your pieces and change them as much as you want, all while keeping things fairly clean & interoperable.

    In my experience, being able to maintain a product / platform is the biggest sign of a job well done. I’ve kept my distance from Rails (and solutions like Spring Roo) because of the fear of the monolithic beast can be produced.

  18. I didn’t read the article word by word so maybe I missed the point. But I have a question: do you think if you did the project in Java, you won’t hit these or a different set of problems? My point is, your project involves OAuth, CMS, deployment and various other things. Its inherent complexity brings all kind of headaches. No current technology stack can avoid that.

  19. It’s a bit more nuanced than that. If I did it in Java, would I have a CMS system yeah there are a few, but I’d use an entirely different strategy. I might offload the CMS bits to a separate application. Would I have OAuth? Yes, there are a few frameworks. The point here is that the integration of all these parts would be much easier because of the underlying standards that are present not just for web applications but a for almost all parts of the stack. Does that make sense?

  20. So, right it isn’t that I think Rails is “bad” and Java is “good”. Right? I think the community is relatively healthy, but what has happened is that there’s this big “cohort” of people that adopted Rails as a reaction to Java years ago, they’ve matured together, they’ve come to create a certain level of complexity within this community, and, ironically, I do think that they’ve come to resemble the communities they originally challenged.

    Rails like other revolutionary movements (or groups like the Hippies in the 60s) they catch on fast, they grow a culture, and inevitably the culture becomes a bit isolated. Who knows?

  21. Have you taken a look at play! Its pretty nice overall and very different from J2EE (the scala API is particularly nice).

  22. ……I might offload the CMS bits to a separate application.

    You can do thesame even with rails or better still offload the cms into a rails-engine and mount.

    What is your gripe really. Quietly move over to Javaland and you won’t be missed.

  23. I’m quite amazed by the level of service and integration you are demanding for free…
    For me it’s like you create a music band with volunteer free musician while you and only you has the right to decide who is in the band and what they should play. Then you start getting angry that they dont perform together exactly as you need and even start to call names on some musicians.
    I dont see how this could ever work

  24. Yes, I created a music band with volunteer free musicians and I am the only one who can decide what they will play. And, I will call them all names. That is the power I command. Yes.


  25. I’m recommending the Play! framework too. Scala is powerful and beautiful language (much better than Ruby for me) and the Play! framework is fast, lightweight, and with hot reloading during development. Plus: you can use any Java library you want. I’m using Play! (Scala taste) with good old Hibernate and BeanValidation for example.

    Play is the best web framework I’ve ever used!

  26. After reading this, the Clojure community’s decision to eschew frameworks in favor of libraries makes a lot more sense. Thanks for showing some of the pitfalls of relying on layers of frameworks to get the job done!

  27. That is interesting. Isn’t it. vert.x is mentioned in the Hacker News thread, and vert.x is node-inspired. My theory is that I don’t think a lot of people are really using Node.js, it’s very popular right now to learn it, but I just interact with a lot of developers that confess to using it.

    That may change, but I think there’s a built-in filter function with Node.js that excludes a lot of developers from using it. You have to be both smart and curious enough to learn it, and no one like DHH has emerged as a hero for the framework.

  28. Working with Java (and its associated frameworks) you’ll find your team spending more time implementing infrastructure code. Stuff that adds no value to your customers bottom line. IT Waste. Vendors love this.

  29. This is total nonsense. You think Rails is too “heavy” because you are using the CarrierWave “framework”? Just know that CarrierWave is a) not a framework and b) you might find yourself needing a file upload and image management tool on any other framework. These tools exist to solve problems that crop up frequently for developers, regardless of their language and framework.

    Furthermore, why are you complaining about New Relic? Again — New Relic is not specific to Rails, but it does help solve a complex problem. Applications are growing in complexity not because of “bloat” but because clients need to do more, and us developers are here to deliver that functionality. As a user of New Relic, I can tell you, using data, it solves problems and makes things faster if you know what you’re doing.

    I’m not a framework hipster. Use what you like. But to say that Rails is growing unwieldy because of “Heroku gems” (?) or crappy CMS gems like Refinery is absolute bullshit.

  30. I love how you didn’t even read the post. Again, the defensiveness of the Rails people reminds me of the defensiveness of Java people in 2007. The fact is that Rails 3, in an effort to simplify, created a monster of brittle, interdependent frameworks and libraries. Choose a few little details and make a few digs. You’ll make yourself feel better in the short-term, but I do think that people are moving on from Rails. First it is a drip, then it is much more.

  31. In fact i kind of agree that the learning curve to master rails is getting higher than it used to be, but i dont get the point that it’s proven by the difficulty to make work together independent projects that did not even existed when rails was supposed to be easier to use and learn.

  32. hey Tim,

    You are bringing up two points in your article:

    1/ the huge number of gems to build a Rails application.

    Right, compared to the very first versions of the Rails framework, we have now so many different gems to embed in our applications. But wait, consequently, we also have TONS of features coming with for nothing. So, it’s definitively unfair to blame Rails for that !
    A tip for you: https://www.ruby-toolbox.com.

    2/ Refinery “sucks”

    Would you embed WordPress within your PHP application ? Nope, because it does not make sense. Same thing goes with Refinery or other Rails CMS engines (even Spree). See them as layers on top of Rails because they are not very agnostic in terms of gems / UI / etc.
    Is that a problem ? Certainly. I’d rather say a misunderstanding about engines. Should Devise and Refinery be considered as equal engines ? That’s a point which definitively needs to be clarified by the Rails community.

    I realize your article was written to be provocative but I doubt you spend a few minutes to have a full customized web app with auth / upload / …etc in Java. I’d say that a few minutes was the time I wasted starting Eclipse a few years ago 🙂



  33. #1 The explosion of gems is a good thing, but it is a very bad thing in the absence of any standards that encourage interoperability. The Rails community doesn’t have the same political/structural mechanisms that are present in Java to create standards that encourage interoperability.

    Would you embed WordPress in your PHP application? I don’t think you understand what Refinery is.

    #2 Minutes, you think it took “minutes” to get this site up and running. Try months. And, this is the point. Rails developers are still holding on to this 2007 myth that it’s all easy and it takes minutes, etc. This is just one of the production Rails apps I’m maintaining, the other one? Oh boy, wow it’s not easy by any sense of the word. A tough problem is a tough problem that takes time to solve regardless of the platform.

  34. Just because you don’t see something, doesn’t mean it’s not there!

    Ruby (not Rails, because Rails is simply a piece of the Ruby ecosystem) *does* have a set of standards, they’re called conventions. We all agree on conventions that are reasonable and in the event a convention can’t solve our problem we introduce configuration with reasonable defaults.

    Perhaps instead of just taking a look at the Ruby world, actually try to build something with it. Express your ideas, and stop worrying about what the “best” tool for the job is. Honestly if you don’t even believe in yourself enough to know you’re making the right decision when you’re picking a TOOLCHAIN…you should probably either stop coding or switch to something a little less complex…like Java! Or Visual Basic!

  35. Hello Tom who hasn’t read the post you are commenting on. I have built many things with it. I’ve been an advocate of the platform in many situations. It has grown a bit long in the tooth, one of the reasons for this is because these “conventions” are less about collaboration and more about the particular fancy or style of the moment.

    But, have fun in what I’m now calling the Rails Epistemic Closure.

  36. The title of this post is annoying. The fact that YOU chose to use a gem set that does not work says nothing about Rails.

    We’re building a very complex Rails app (> 180 gems in use atm) and do not have any problems managing the setup.

    I’ve done large pojects on Java and .NET and – compared the the rest – Rails is still a joy to use and easy to handle.

  37. If it can help, I planned to integrate Refinery for my web-app, but the “breaking” point was when it started to mess with the layout in a very “breaks everything” way…

  38. It isn’t just the layout this is the issue with the framework. What it provides out of the box is respectable, but it isn’t something that lends itself to customization.

  39. Tim, I’m noting that you don’t really seem interested in other people’s counter-points; which is fair, I suppose. This is the Internet and few people’s minds have ever been changed in comment threads. Instead of trolling along talking about users flocking back to Java, why not just take a moment and consider; “Maybe Rails wasn’t the right choice for what I’m doing and where I’m at rails-skill-wise.”.

    If I’m reading your article right; you’re attempting to build a CMS-driven, Open-Auth Using, Custom User Tracking (Assuming that’s why you’re using Devise with Refinery), Performance Profiling, Super 301 Redirecting (Rack rewrite?), Custom Attachment Uploading, Custom Web Served (Unicorn, why aren’t you just using passenger?), S3 Supporting, Fault Tolerant, Message Queuing (uh…), custom exception logging, self backup’ing application that’s hosted on a very framework-not-agnostic platform (Heroku) and getting a bad taste in your mouth.

    That is indeed quite a mess of things. Putting together *that* many distinct pieces of functionality, that you’re not writing, will be a trying task in any framework no matter if its .NET, PHP, Rails or Java. On top of that, factoring in the fact that you’re mixing in a CMS (Refinery) spells disaster. The integration testing and different interaction points alone for that many disparate technologies is staggering. There is a place, in any framework, where what you’re doing is just too complex for a novice in that framework to effectively and efficiently pull off. Sometimes its difficult for a developer with experience in one framework to understand that they will take longer, experience more issues and probably require a bit of guidance in another framework.

    It sounds like your primary experience is with Java (eschewing more towards the documentation side of things, if your github profile is an indication) and you’ve gotten handed a pretty difficult and complicated project in Rails to complete. It is a most unfortunate circumstance for you, but judging an entire framework and community based off this sort of experience is a bit… unfair. The experience would be mirrored by a .NET developer trying this in Java, a Rails developer trying this in PHP or a Python developer trying this in Clojure. While experience in one framework/language does assist in another, there is still a learning curve – and these sorts of problems in particular tend to be framework-specific.

    Anyway; to try and spin this more constructively, what sorts of equivalent options are available on the Java world for accomplishing these tasks? I’ve been working with CQ5 a bit as of late, and would be interested in hearing a bit more from the Java side of things on these issues. What you’re building sounds like a who’s who of web technologies; I’d love to hear the popular Java equivalents for:

    – Writing web applications (No, I’m not joking – I have no idea what the popular Java framework is)
    – Free CMS (refinery)
    – Devise/ASP.NET Membership User Management Equivalent w/ OAuth support (Devise/Omniauth)
    – Local and S3 File Upload, Management and Storage (carrier wave)
    – Small, Efficient Web Server (unicorn)
    – Application-Contained Cloud-Image Cloning and Scaling Support (fog)
    – Free / Affordable On-The-Fly Performance Profiling, Query Analysis and Profiling with Historical Logging and Reports (New Relic)
    – Custom server-level rewrite rules (rack rewrite)
    – Multi-process Management (foreman)
    – Custom Exception Logging and Notification (honeybadger)
    – Application-Contained Backup Routines (heroku’s backup gem)
    – and SaaS hosting (heroku)



  40. #1 You can not pretend that RoR have gems interoperability issues and needs “standards” like in Java just because you had a single bad experience with a gem which is, in my point of view, a full app instead of a helper gem.

    #2 “Would you embed WordPress in your PHP application? I don’t think you understand what Refinery is.”
    Oh, yes, I do, believe me. I built myself a Rails CMS open source app so I know exactly the context.
    Refinery is just a full app itself, period. You met that architecture issue because you didn’t consider the true nature of RefineryCMS.
    Seriously, you thought that you could embed a whole and complex CMS app inside your big application without any frictions ? It’s too easy to blame Refinery / Rails.
    Our job as developer / dev manager is to anticipate that kind of problems regardless of the technology.

    #3 “Rails developers are still holding on to this 2007 myth that it’s all easy and it takes minutes, etc.”
    It still takes minutes to bootstrap a Rails app. Even better, you have a better first Rails app (authentication / upload / tests are cheap) for the same price compared to 2007.
    It’s a fact.

    #4 “A tough problem is a tough problem that takes time to solve regardless of the platform.”
    I do agree with you on that. Like any other apps, a Rails app can become a nightware to maintain if you don’t apply development general rules (refactoring, tests, …etc).

    So I don’t know the exact context of your project, neither the experience of your team in Rails / Ruby but I doubt they were senior. As you do / should know, for big projects, it’s better (even required) to have a couple of top gun experts in the main technology. Just saying.

  41. Good I’m certain you are doing it right. It’s all about expertise and there’s nothing brittle about the platform… Again these are all comments that remind me of the reaction of Java developers in 2007. Defend the platform at all costs

  42. Jesus, that’s not a comment, that’s an essay, and a good one nonetheless.

    The applications in question are actually a few. I’ve separated most of the concerns out already, Refinery bills itself as an embeddable CMS that allows for customization. It actually isn’t a mess of things at all, it’s just a collection of frameworks and libraries, some of which behave just fine, but other which tend to take over everything.

    My experience in not captured in my Github profile. I’d call myself primary a Rails developer and a Java developer. I’ve been the proponent for Rails at companies that you use every day, and one of the common themes in the past few days have been a steady stream of people assuming that I must be some sort of Rails newbie. It isn’t the case, what you are hearing is someone who has used the platform for years (probably before many of you jumped on board) reacting to the mess of things that Rails has turned into. Rails was, at one point, the exact right choice for a system like this, but it morphed into something nearly as frustrating as Java was in 2006.

    It’s dogma and tradition, it’s a legion of people showing up and saying, “Oh, you should just build your own stuff and not use these gems.” It’s people that can develop on a platform like Rails without knowing technology equivalents in other platforms. It’s an island or a culture, with defenses. It’s a culture that has hundreds of people showing up because someone is “trying to write an application that does too much, when too much is defined by: a simple CMS library, authentication/authorization, OAuth, URL rewriting, AWS integration, and logging.

    Like that’s too much, and if it’s too much it means you should just roll your own. I lean back in my chair, stare off into the distance and think, “These people are living in a bubble. If I stay on this train, we’ll be spending a great deal of money on hubris.”

    BTW, If you want a list of technology equivalents, I’ll go through these in detail over the next two years.

  43. Gotcha. Connecting between the tone of the issues you were talking about, consistent references to “you guys” (referring to Rails devs) and your github profile, I had drawn the conclusion that you weren’t very experienced with much beyond Java. I’ve also noticed over my professional career that most loaded-inspecific negative commentaries about this-or-that framework/language/technology tends to come from silo’d/inexperienced developers who are either casually browsing a framework or haven’t had any real experience with it. Apologies.

    You mention the dogma and tradition of showing up and saying “build your own stuff” intermingled with a lack of cross-framework understanding. I’m not exactly sure how those interact; but there does come a point in any system where using a lot of prebuilt stuff ends in disaster. A generic OAuth creator can’t know all the intricacies that can come from a CMS’ user structure or session management tendencies. Its not just Rails, most seasoned (myself included) developers will insist that at a certain level of “piling on plugins and extensions”; you stop and build it yourself into a comprehensive design. That’s just good architecture. I think you mentioned DLL hell at some point. DLL hell, gem hell, jquery plugin hell, java jar hell, python egg hell – every language/framework has it. Its your job as an architect to avoid it when you’re building a large system.

    The cross-framework-understanding bit is a little baffling to me. I’ve encountered very few professional Rails developers for which Rails is their first-framework. I mentioned not knowing Java’s variants, and that’s totally true. I could, however, prattle on and on about .NET’s variants and some awesome differences there-in. I frequently poach features from .NET into Rails and vice-versa when working on various projects. Have you met a lot of Rails developers for whom Rails is their primary language? (lending to “(not) knowing technology equivalents in other paltforms”)

    Your final paragraph and general response to comments here seems to indicate that you’re unhappy with a perceived bubble/silo in the Rails community. That’s fantastic, and I mean it without a hint of sarcasm. Maybe that is the kernel of your discussions at this point; “Bubble! I hate this bubble and want to make sure it doesn’t lead this train off the deep end!”. You seem unhappy with a train that’s going off without you, presumably towards a land of unstructured intermingling crazy dependancies.

    If that is truly what you’re unhappy about; don’t you think you may be better served trying to fix that? Instead of negatively sticking to refuting every commentor’s point; (your response to Gernot embodies this; “I have the opposite experience, but congratulations on not having problems.””) – mayhaps you would find your problems better received and resolved by truly discussing them and trying to find solutions?

    For instance; the purpose of the tail of my last comment was to get you thinking about equivalent encounters in other frameworks (that, and I would like to know a Java perspective). I believe your position is that Java knows how to handle inter-dependency of 3rd party libraries better. Splendid! How? What sorts of things can we do to integrate this knowledge into Rails and help make things better; instead of simply standing in the theater shouting “Fire!”?

  44. Not sure if that reply went out-of-thread or not; sorry if it did. Just one final exercise/demonstration.

    Transport yourself back a decade and imagine two headlines:

    * Java sucks and is totally turning into Perl
    * How you can implement Perl’s simplicity in Java

    What sorts of responses do you think you’d get for each? Which one do you think would receive helpful feedback and which one would be an emotional demonstration of defense?

  45. If you think Rails is bloated now, you should check out http://code.google.com/p/magix-illuminate-2 – A new way to Polymorphism and Encapsulation, which allows for some pretty interesting scenarios. Such as overriding a method to go to another server, runt time, etc …

    Based upon a Design Pattern called “Active Events”, which is at the core of it, and less than 2.000 lines of code …

  46. Read the post. The Java community has developed an imperfect, but effective strategy for developing APIs that encourage interoperability at the framework level. JCR, JPA, Servlets: many find issue with the standards, but over the long-term, say a decade, many of these standards evolve toward something usable (thanks in no small part to the influence of Rails). Rails has nothing like this, it has a culture of DIY and roll your own, and if you ever proposed a standards body people would laugh you out of the place.

    Also, this is my theater, I’ll shout “Fire” is I want to.

  47. I’d expect people to bow down to my infinite wisdom. No we’re talking about the political strategy of title-making?

    Ah, but Perl has a different problem. All those people are insane. Have you seen then at OSCON? Perl is like an entertaining cult (of interesting geniuses nonetheless).

  48. Take a look at Spring Roo. Ruby/Rails is the evolution of the “webmasters” of an earlier time that is just starting to mature and the seams are coming apart. Java started with a mature approach.

Comments are closed.