Sweet, sweet vindication

It’s been awhile since I have written an eye-poker post. I’ve been trying be more reserved, professional, and politically correct. But that basically had a cooling effect on my writing. So it’s time we turn up the heat and let the rage flow.

The State of Web Frameworks Sucks

The state of big web frameworks sucks. Not the least sucky among these is Rails. There, I said it. “Bah, he’s just a bitter .NET developer stuck in the stone ages”. I’m tired of getting made fun of and beat up by former PHP scripters telling me how lame and “enterprisey” .NET is and how wonderful and magical Rails is and how it solves every problem.  Tell it all to this guy:

ActiveRecord (and Rails) Considered Harmful

Especially with this wonderful quote:

It is practically impossible to teach OO design to students that have had a prior exposure to Rails: as potential programmers they are mentally mutilated beyond hope of regeneration.

  • Edsger W. Dijkstra (paraphrased)

My thoughts exactly, on all counts.  The whole “Controller” mindset in most MVC frameworks is “pants-on-head retarded”. Worse yet, most frameworks use inheritance.  I can’t say this loud enough, so I’m going to BOLDFACE it, ALLCAPS, BLOCKQUOTE it so maybe you’ll see it:


Rails is one of the biggest violators of this. I don’t care about your stupid dynamic typing and all your excuses about how it “just doesn’t matter” — it matters. The laws of good design don’t just fly out the window when you’re using Ruby or any other language.

More Pants On Head: ActiveRecord

To call ActiveRecord an ORM is to insult the already sullied and notorious name of ORM. I won’t even say that AR is the Linq2SQL of Rails dev because it’s worse than that. AR is the equivalent of dragging and dropping your database to your design surface in Northwind/Designer-driven developing in Visual Studio.

I don’t care what you’re doing with your data store, the model should be the core. This principle is so fundamental that not even silly dynamic typing can overcome it. The model flows out into everything, not your database driving your model. AR represents everything that’s wrong with data-driven development as much as designer-driven EF does in .NET.  It’s just wrong, always has been wrong, and always will be wrong. The model is the key, not the persistence mechanisms.  AR flagrantly and flamboyantly violates this principle and anyone with a clue who has used AR seriously on any project of length will tell you how it grows into a big mess.

And then you have the whole “Unit test against your database” phenomenon. I’ve had Rails guys chide me for this unmentionable and detestable practice and say that I’m too stuck in my .NET ways, but I’m sorry. You’re an idiot. Unit testing against the database is always, and in every case, wrong. Attempts to explain otherwise sound awfully like arguments I once heard from someone explaining why cannibalism isn’t as bad as people make it out to be. It’s just wrong (unit testing against your database and eating people).  Just because you wear thick rimmed glasses and drink lattes with your scarf flipped casually around your neck doesn’t mean you get to throw fundamental principles out of the window. So stop it. Just because it may be quick or easy (which I don’t believe) doesn’t make it right.

Just when I thought I couldn’t say anything worse about AR, I’ve got one more — the coup de grace –it uses inheritance! ARGH! Add “maliciously” to the adverb list (“flagrantly, flamboyantly”).

ActionController – Crack Den of Inheritance

It seems almost every web framework has this wrong: Rails, ASP.NET MVC, Struts, Django, Spring, and MonoRail from my limited research.

Let me put it another way in case I haven’t been clear enough: Inheritance is antithetical to web app design.

One class — that derives from some gawdawful ginormous base class — that has many “action” methods on it is a pile of fail. Why? Because each of those methods has, by definition, a different responsibility and you’re breaking the Single Responsibility Principle.  Principles matter! No matter what language (dynamic, static, etc), principles matter!  Just because you’re a Rails hipster doesn’t mean you don’t have to obey the laws of physics. With sufficient thrust, pigs can fly for a short while. Likewise, with sufficient ignoring of principles, a rails dev can be successful for awhile but the legacy maintenance cluestick will eventually come crashing down on him/her.

The Perfect Web Framework

Rails is the whipping boy of this post, but most of the other frameworks deserve all the same vitriol because they have all the same fatal flaws (primarily inheritance).  So what would the perfect web framework look like? Let me show you:

  • Total adherence to principles: The framework should itself abide by the fundamental principles of good software design and it should require you to do so as well. It should make it as difficult as possible to flout them and, preferably, punish you for doing so by making everything harder.
  • Completely compositional: It should itself be based entirely off of composition and either not use inheritance at all, or only in very minor circumstances and certainly should not require you to derive from any framework base classes if you don’t want to. Convenience base classes are fine, but should not be imposed upon the framework consumer.  The framework should encourage and reward compositional design and frustrate and punish inheritance mis-design.
  • Model based: It should encourage and reward you for having a centrally defined model (or models) and be based around one itself. The framework should itself use one or more models to represent its own internal structures (configuration, routing, etc) and expose these for manipulation by the consumer. It should facilitate you using your own models in your actions and views.
  • Not have any notion of controllers: The framework itself has one controller that processes the routes and this satisfies the “C” in MVC. The words “controller” should not appear anywhere else in the framework or outside. It should completely break you of the notion that you need a class called “controller” because this is just wrong and leads you to do all sorts of bad, nasty, and dumb things.
  • Statically typed: In line with the “Model based” requirement, it should facilitate inspection, reflection, and convention-based development where everything (and I mean everything) flows OUT from the model (not into the model, like ActiveRecord foolishly does).  All your validation rules, authorization rules, binding rules, display rules, input rules, etc. should all flow from decorations and conventions attached to your model. Which leads to the next requirement….
  • Conventional top-to-bottom: The framework itself should expose all of its own conventions and allow them to be replaced. It should encourage and reward conventional development and frustrate and punish you for doing one-off stuff except as a last resort.  And I don’t mean Rails’ conventions where it’s my-(lame)-way-or-the-highway, I mean real conventions – YOUR conventions where you can define them and reuse them. This is only possible with static typing because you can’t get the level of introspection and reflection necessary to pull this off with dynamic typing and string-only reflection.
  • Based on IoC: No more IoC as an afterthought. I’m not going to have this debate. If you disagree with this you are wrong. If you disagree then you simply haven’t seen the power of IoC done right in a framework and in an app. Try playing with FubuMVC for a few weeks and look at some of our samples or come hang out at Dovetail for a day or two and I guarantee you will no longer disagree with me.  The power this provides is so overwhelming and fundamental that is perhaps the requirement of requirements.
  • Mostly model-based conventional routing: Your routes should flow out, conventionally, from the model as much as possible allowing proper REST scenarios. This is extremely important in a CRUD app. Specific actions (for service actions like “send email” that aren’t based on your main domain model) should be easily created, defined, and conventionally routed.
  • Action-based: In line with the whole “no controllers” and “completely compositional” requirements, it should encourage each action to be tiny (a few lines at most). All things like model binding, validation, object/persistence retrieval, should be moved into composable “behaviors” that are outside of the action since they are not the concern of the action. Each action should be a single class with a single public method that does that one thing. No more multiple-50-plus-line methods in your dripping-with-inheritance “Controller” class. NO!
  • Minimized code-in-view: This one fits with the “conventional” and “compositional” requirements. The framework should provide ways of micro-HTML generation that flows from the model and through conventions. I’m not talking about lame loosely-typed “HTML helpers”, I mean real meaty, conventional, model-based micro-HTML generators.  The framework should also make using partials a natural, normal, and preferred way of compositing screens.  It should support the ability to render simple HTML no-code partials, or to execute a partial action through the framework to render a chunk of HTML, JSON, etc.
  • One Model In, One Model Out: Every action method should take in one model (not primitives) in and return one model out (no ActionResult nonsense or framework-dependent inheritance silly classes).  The action should not tell the framework which view to render or where to go next unless the action’s purpose is specifically for that (such as a post-successful-login routing action).  The framework shall conventionally determine how to bind the models going in and render views from the outgoing model
  • Zero touch: My actions should have ZERO knowledge of the web framework. I shouldn’t have to “import” or “using” or “require” any of your framework stuff. My actions should be simple PO*O’s like this (note no “using FubuMVC*”)
  • Independent of other frameworks: I shouldn’t have to use your stupid “ORM” or your favorite JavaScript framework which is 2 weeks old and already outdated.  This is made easier, if not entirely possible, by the “IoC” requirement, by the way.
  • Testing as a first class citizen: I debated whether or not I should even put this in here because, for me, this is like putting “Step 1: Breathe” at the top of any list of instructions.  Generally, if you care about any of the other requirements, this one is essentially a “Step 0″ requirement kinda like “Use a computer” or “Run on x86 processors”.

It should come as no surprise that we, at Dovetail, came to these conclusions (many of them solely by Jeremy Miller) after evaluating all the other major frameworks, suffering much ridicule and derision for noting the inherent and fundamental flaws in them and then building our own that follows all the principles: FubuMVC.

In many ways, FubuMVC is better than Rails and I’ll put my framework up against yours any day of the week. In some ways, it has a long distance to go yet. These are, namely, approach-ability for newbies and community. Currently you have to be disgusted with your current web framework and have tried to replace large portions of it before you can truly appreciate FubuMVC. As far as community, it’s still pretty small at this point, and community contributions are growing, but still not anywhere near Rails level, for sure.

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • If I hadn’t the experience of FubuMVC I would think you are just looking for attention and  a bit of traffic. But honestly, compared to MS MVC, most of the benefits you have pointed of I have also found to be very beneficial.

    Can’t say much for Rails, except Uncle Bob pretty much has the same OO/AR gripe.

    Loved reading the strong, opinionated post – didn’t know you had it in you.

    By the way, 2 days at DoveTail sounds great. If I make good tea could we make it a permanent deal?

    • Anonymous

      Let’s make that a Surgery Logistics and Dovetail party ;)

  • Adam Dymitruk

    Now write something about StoryTeller and how Gerkin, SpecFlow and all the others fail to see the friction they impose by not exposing grammar in an easily consumable way.

    • Anonymous

      How about we wait for the Serenity bits to settle after all the churning from my team ;)

      • Anonymous

        What’s Serenity?

  • I follow all you FubuMVC creators, and think all of you are extremely smart. I know you are way smarter than me and respect your opinions, but when I see posts/tweets deriding everything not created by a certain group as rubbish, well that’s just rubbish. You’d do better focusing on FubuMVC and how it works rather than tooting your own horn. Sorry that’s just what it sounds like.

    I’ve not used FubuMVC yet, but I’d like too. First I want to learn MSMVC better so I can properly compare. One thing Rails has on FubuMVC is naming, seems like all popular rails frameworks have some awesome name. :)

  • cbp

    I disagree with nportelli – good inventions and meaningful progress usually arises out of genuine passionate frustration with current tools. I say, don’t hold back!
    FubuMVC is a step in the right direction. Like you acknowledge though, what is needed is a combination of approachability for newbies, as well as best practice design.

  • Having worked with Monorail since before v1.0, all versions of ASP.NET MVC and most recently the WCF Web API (plus playing with Rails, Sinatra and Node), I can say with some experience…I agree with you on all points. Very good list. The importance of composition really can’t be overstated today, since most developers don’t understand this notion at all.

  • Actually, I’d love to hear all about how StoryTeller is better than Gherkin, since all of the Cucumber people don’t understand how to test.  Follow it with a post on how the only IoC container that does dependency injection correctly is StructureMap, since everybody doesn’t have your deep understanding of dependency injection.  Then write a post that finally declares what we all know anyway:  The Mecca of the programming world is in one building in Austin, Texas.  That’s where truth starts, and the rest of the world is wrong.

    I screwed around with FubuMVC last year, hearing how seriously it took important ideas like SOLID and convention-over-configuration.  Those are things I care about, so I tried it.  Except that I couldn’t get it to build.  Tinker, tinker, ok, now it works.  Now let’s get a website with a few basic things in out.  Error page.  Ok, tinker, tinker… got it.  Wait, that doesn’t work like that.  Tinker, tinker, got it.  Now I want to stick this behavior into this chain on this one route… ugh, but where’s the documentation on that?  Sigh, maybe tomorrow.  Oh, wait, how about I try to contribute my knowledge of the intricacies of many IoC containers by trying to add support for something other than StructureMap?  Yoink, there goes a week I’ll never get back.

    I still took all of these issues as signs that I need to improve, though, and I lurked on the FubuMVC google group for a long time.  And frankly, it wasn’t as great, or finished, as it has been sold.  FubuMVC is like the great electric car that we “should” be driving.  Except when you look at the details, you see that it’s more expensive, it doesn’t go as far, it breaks down more, it’s harder to fix, the batteries are a fire hazard, etc.  Yet electric cars (and FubuMVC) are superior and ahead of their time, if only people could SEE!!!

    SOLID, convention-over-configuration, and all of the best practices in the world are means to an end.  And it’s the end that we’re tasked to complete, under budget and on time.  This is where Rails shines.  I can hire a Rails programmer, but I can’t hire a FubuMVC programmer.  I can TDD Ruby quickly and easily, instead of chewing my fingernails in-between red compile and green compile and refactor compile.  I can get projects done in hours versus days, or days instead of weeks.  I can change things according to client demand much faster and easier, which makes them like me.  Gosh, I can even *understand* how a Rails application works.  Yet today, when I go to the FubuMVC website, I (an experienced .Net developer with a computer science degree and dozens of web applications under my belt) still don’t know what’s going on.

    I’ve known for a while what Microsoft offers, but it took me a while to figure out with the “alternative” to .Net offers.  I switched to Ruby and Rails.

    P.S.  Chad, you can’t really mean what you said when you wrote that “This is only possible with static typing because you can’t get the level of introspection and reflection necessary to pull this off with dynamic typing and string-only reflection.”  Stop for one second, take a deep breath, remember all of the ways you can use Ruby, and then think…  is there really *no* way for a dynamic language like Ruby to accomplish this goal?  

    • Hey Darren, I don’t know what your deal is, but not reason to be a jerk and hate. Disagree, fine, but enough with the bitterness. Sorry you didn’t grok Fubu. It’s rough, and it was rougher then, I get it, but dont’ rage on us.

      Sorry you missed most of my points, I guess you really didn’t read the post. Read it and ask questions, or go troll somewhere else.

      • Nate

        Chad – You are an idiot. Most of the principles you list under an ideal web framework
        are present in Rails. Other things like having no controllers seem
        incredibly pointless to me. Too bad you were unable to manage any
        coherent arguments other than your caveman-esque “CONTROLLERS BAD. YOU

        Then you have the balls to call someone a troll just because they don’t like your pet framework. Amazing.

      • Sorry Chad, but you’re the one coming off as a “jerk” here.  I read your entire post, and it sounds like the sad ramblings of an angry man.  I guess while the rest of us are getting stuff done, your team can keep hacking on an MVC framework that complicates things far more than it needs to.  Do you enjoy coding for the sake of coding?

        You’re the guy blasting every other prominent web framework and touting your own at the same time, yet when someone comes to criticize yours, you reply with: “rawr you’re an angry troll, don’t hate or be a jerk, rawr!”  Hypocrite, much?

        It’s vitriol like this that hurts the .NET community.  I’m a .NET developer, and I have been for a number of years.  But linkbait posts like this are a scourge on the community, and I honestly believe you should be ashamed.

        • Like I said, it was an eyepoke post trying to get people to think about inheritance and composition. 

      • I don’t read his comment as hating, or being a jerk, or bitterness. 13 Likes, too.

    • Jay Godse

      I loved the analogy of the electric car. 

    • Darren’s taken giant dumps on my projects before and as much as you want to hate him and shove him in his locker, you usually end up agreeing with his points (case in point: I spent last weekend with Ruby)

  • Will Gant

    I found myself nodding my head in agreement on most of your points. However, the “no controllers” statement is baffling. Given that I’m pretty darned sure you’re right about the rest of it, can you enlighten me on what you are talking about with this? Are you saying that each action on the controller should be its own class or something? I guess I’m having trouble getting my head around how that might work, but I will admit to having a vague feeling of annoyance when working with controller code in every framework I’ve used.

    I’m glad every time I see somebody state that a site without IOC is all fail. That’s been my experience and it usually sucks pretty bad trying to put it in there when it wasn’t present in the first place.

    • The controller in most “MVC” frameworks is in the framework itself. They are “Front Controller” frameworks (google for “Front Controller fowler”).  The class that you create to host your action method(s) is not a “controller” even though every other framework calls it that.  And this is why, if you’ve ever used any of those frameworks for any length of time you note that you get “action creep” and the controllers get bigger and more bloated as time goes on because it puts you in the wrong mindset (i.e. makes you dumb and do dumb things).

      In Fubu, there are many ways to arrange your action methods, but the most popular one today is the either the “endpoint” mode or the “handler” mode (or both combined).

      Endpoint is where you have a class that corresponds to a route (i.e. /user) and it’ll have a get() and a post() method which corresponds to the HTTP verbs.

      Handler is where you have a single class “UserHandler” which has a single method (for example, “Execute”, but you can call it whatever you like) which handles that request.

      There is no “controller” anywhere and that concept is not meant to go beyond the internal workings of the framework.

      • Could you perhaps explain the Endpoint method further? If I have something like /user/create and also /user, would there then be a seperate class for each?

      • Anonymous

        So would it be correct to say that the code examples in http://readthedocs.org/docs/fubumvc/en/latest/topics/gettingstarted.html are correct, but the class names which end in ‘Controller’ should really end with ‘EndPoint’?

        I think that might be where the ‘there is no controller’ statement is a bit confusing.

        • Those code examples are correct, but they use the mistaken term “controller” for the class that houses the Action methods. Old habits die hard, I must admit (I do it myself from time to time).

          People are used to seeing that, so it helps ease them into FubuMVC. But I suppose we should just be straight up from the get-go and get rid of all “controller” nomenclature to avoid confusion. Thanks for pointing that out.

          “EndPoint” is but one style or convention for discovering action methods in FubuMVC. You can define your own conventions. The real important thing is the *METHOD*. The class that houses the method is not as important.  Calling it “Controller” is wrong and misleading and leads people to put multiple action methods in the class which is almost always wrong (SRP violation).

          This post explains it a little better, perhaps: http://lostechies.com/joshuaflanagan/2010/01/18/fubumvc-define-your-actions-your-way/

    • Anonymous

      Hey, Will. To add to Chad’s response, I thought reading the following post might help to explain the design motivations for ditching traditional controllers: http://lostechies.com/derekgreer/2011/05/31/cohesion-and-controller-ontology/

  • While I don’t agree with a few of your points it’s largely pretty sound advice that I also share. Though you do have a few points where the rationale for your assumptions is “Its wrong” or “you’re an idiot”. Angst begets Angst, so don’t be surprised if you draw angst comments from people you’re calling an idiot as trying to defend your assumptions in this way is in itself “wrong” :)

    i.e. you say “Unit testing against database” is very wrong, I’m not sure if you mean you should never have db integration tests which I find unsound advice since db integration tests can pick up a class of errors not otherwise possible. I routinely test against in-memory sqlite dbs and I’m happy with this approach as its fast and tests are able to test the state of the db.

    You also say inheritance in a web framework is pure evil but then go on to mention convenience base classes are fine – which contradicts itself. Whilst I agree composition should be preferred over inheritance (which should be kept thin) there are clearly times where inheritance is beneficial, i.e. in ServiceStack the convenience base class is used to generically catch C# exceptions, log them and serialize the exception into your Response DTO with the preferred HTTP status code, etc. 

    You keep referring to some fundamental principles as the Gospel truth that all languages should abide by. Not all languages share the same weaknesses/traits and are required to abide by the same ‘set of principles’, i.e. what’s good for C#/Java isn’t always what’s good for Ruby/JavaScript/Lisp/Obj-C/etc. e.g. ISP is less relevant and you’re unlikely to see an IOC in dynamic languages because they’re not needed. 

    Clearly people manage to build large scale projects in Ruby+Rails / Python / PHP /etc. I wouldn’t assume they’re doing it wrong if they don’t follow some other languages “holy principles”.

    Anyway I’m surprised by how many similarities we’ve ended up with in ServiceStack, i.e. statically-typed Model Driven Development, model in / model out, IOC built-in connects services + deps / no XML config, non-invasive layered (zero touch) dev, Testability, pre-defined conventional routes + custom user defined routes, No Controllers, services impl interfaces w/ optional convenience base class, etc.

    ServiceStack may be more opinionated as its focused on performance and uses its own JSON and JSV serializers since its a critical part of web services development. Other high performance components are bundled but optional and connected via IOC.

    Not having looked at FubuMVC, I assume the implementations are going to be very different but it sounds like ServiceStack + FubuMVC share similar core beliefs – albeit focused for different purposes (i.e. Web vs Web Services).

    • RE: “idiot” – Yeah, I was being purposely bombastic. Note I didn’t delete the offending comments.

      RE: “if you mean you should never have db integration tests” – I do not. DB integration tests are necessary. Just don’t call them unit tests and don’t treat them like unit tests

      RE: “I routinely test against in-memory sqlite dbs” that’s great. So do we, but they’re not unit tests, they’re integration tests.

      We stopped doing memory DB tests because they’re not real-world. The purpose of an integration test is to test the integration. If you’re mocking or simulating things, you’re defeating the purpose.

      RE: “You also say inheritance in a web framework is pure evil but then go on to mention convenience base classes are fine – which contradicts itself. ” – No, it doesn’t. There’s a difference between “baked into your design, poorly and required by consumers” and “provided for convenience, but not required and with strong cautions on usage”

      There’s also a difference between a convenience class that has 1 or 2 methods in it, one of which you’re required to override and the AR base class which has 300+ methods on it and detonates a nuclear bomb on SRP and OCP

      RE: “You keep referring to some fundamental principles as the Gospel truth that all languages should abide by. ” – these are core principles that frameworks on all OO-ish languages must abide by or suffer short-term or long-term design problems and maintenance issues.  Yes, even Ruby and Rails. Many people have spoken about SOLID and principles in Ruby not the least of which are the PragProg guys and Uncle Bob.

      I was specifically addressing this “I program in Ruby, the rules don’t apply to me and you’re just a dumb C# guy” mentality and it’s wrong on its face and it’s not just my opinion. Many experienced Ruby guys agree.

      RE: “Clearly people manage to build large scale projects in Ruby+Rails” yep, and they suffer the same maintenance problems that every other inheritance-based framework suffers, except it’s easier to hack and work around them in Ruby, but that doesn’t mean it’s right or good.

      RE: “I wouldn’t assume they’re doing it wrong if they don’t follow some other languages “holy principles”.”  This is just ignorance (as in, you’re a smart guy, you’re just mistaken on this point). Go look up what the Ruby leaders are saying about OO principles, testing, etc. 

      • “yep, and they suffer the same maintenance problems that every other inheritance-based framework suffers, except it’s easier to hack and work around them in Ruby, but that doesn’t mean it’s right or good. “I wouldn’t be so quick to judge. The largest websites in the world are built using dynamic languages which themselves have very good characteristics in enabling large-scale multi-developer, multi-site deployments, so they’re proven at the very least to scale in the large (i.e. past C#).” This is just ignorance (as in, you’re a smart guy, you’re just mistaken on this point). Go look up what the Ruby leaders are saying about OO principles, testing, etc.”Well I wont consider myself mistaken on your say-so :) and telling someone to “Go look up” something to prove your point is like telling me “there’s a Google Proof out there that backs up my theory but I wont tell you where” :)As for testing, it’s a trait embedded in Ruby’s culture and IMO they’re much ahead of the game with BDD, frinction-less testable DSLs and executable User Stories etc. Compared to C#/.NET framework which had testing as an afterthought and still suffers from .NET Frameworks un-testable, sealed internal classes.OOP principles is one thing but Ruby is also dynamic and functional (where composition looks very different) and I’ve simply suggested the same rules don’t apply which is the reason why you won’t see C#/Java/OOP concepts thriving in Ruby land.

        • @twitter-17575623:disqus , I think you’re confusing some issues here. I don’t doubt that people build all sorts of great things with Rails. I’m not saying that Rails is completely worthless. Quite the contrary, I like it and there’s a LOT of good stuff in it. But it, like most-if-not-all the other MVC frameworks, suffers a major design flaw that will bite you and cause a lot of maintenance headaches.  I think people just ignore this or grin-and-bear through it needlessly.  And I’m trying to stop framework designers from making these mistakes in the future so that whatever-comes-after-Rails won’t suffer from this and will be even MORE awesome than Rails.
          “ and telling someone to “Go look up” something to prove your point ”  I don’t feel the need to prove my point. It’s not my fault you’re not really paying attention to what’s going on in the Rails/Ruby community. Pretty much every RailsConf in the last 5 years has had several major speakers on this subject. In fact, Uncle Bob did the Keynote a year or two ago, if I recall. And guess what his keynote was about? About the sore lack of OO principles used by Ruby devs and how it REALLY DOES MATTER.  I’m merely repeating many of his points and the points of many others — like the PragProg guys.

          “I’ve simply suggested the same rules don’t apply which is the reason why you won’t see C#/Java/OOP concepts thriving in Ruby land.”

          Then you’re in bad company, because many of the OOP experts and leaders in the Ruby community disagree with you.

          You’ll find that my post about Rails is nothing novel and is merely an amalgamation of current thought in the Ruby community (except for the MVC bashing and the FubuMVC stuff).

          • Gads, are you going to bring up that talk by Bob Martin?  He got his history so messed up in that talk that it was hard to pay attention to his supposed points.  Smalltalk has many faults, but believe me, the list he used for talking points isn’t among them.  Major, major analogy fail on his part.

        • @twitter-17575623:disqus Check this out, I think it may help the conversation: 

  • I don’t understand the fetishism you have for statically typed languages. You seem to be arguing that because the current tooling for statically typed languages like C# and Java is better, that the languages themselves are better than dynamically typed or dynamic dispatched languages.

    I would argue that you are trying to fit your principles, IoC and Action-based in particular, into the statically typed world by using interface-based design. While some dynamic typed, and dynamic dispatch, languages use messaging instead of interfaces. Since interfaces are the only way to really achieve message based architecture in C#, you assume that the only way to achieve your principles is through interface-based design and IoC.

    I’m not going to say that you can achieve a message-based architecture by slinging around Expressions or Action/Func, because that’s just painful.

    Speaking of eye-poking, I’ve found your ultimate web framework.

    • RE: ”
      because the current tooling for statically typed languages like C# and Java is better”  - that’s not my argument.   It’s not the tooling, though things like ReSharper do help.  My argument is that static typing gives you the kind of rich metadata to do conventional and compositional based programming that langs like Ruby and Python simply cannot.  It’s easier to do composition in dynamic languages, however. There are some trade-offs, but overall I think that the power of static typing’s metadata enables amazing scenarios in conventions. We’ve proven this in FubuMVC, Fluent NHibernate, HTMLTags, and a few other projects.

      RE: “you assume that the only way to achieve your principles”  that’s not what I assumed or said at all. I’m not sure why you’re jumping to conclusions like that.  IoC and action-based are important for MVC frameworks. How you accomplish this in your lang is different, granted, but they’re still important. 

      I did mention StructureMap which is a particular .NET-centered way of doing IoC and so I should’ve been more generic and clear about that, sorry.

      RE: Expressions or Action, etc – no, that’s how we do static reflection which is where you get the metadata from which enables the rich features of static typing I was alluding to.  You can do some of these things in a dynamic system, but it’s a lot more work.


  • Thanks for the link. I think it’s really interesting that we can agree that Rails has some problems, yet come to very different conclusions about some things. I don’t think static types are the end-all be-all, for example.

    I am admittedly ignorant of the .NET world, but every community is trying to improve. Even if Ruby isn’t perfect, we’re at least working on it.

    • @steveklabnik:disqus Thank you for the comments.  For the record, I don’t think static typing is the end-all be-all. I use Ruby for a lot of things.  I also don’t think Rails is that bad. I just think that the whole “Controller” base class design that most MVC frameworks has is bad design.

      I think Static Typing does give you certain advantages in certain circumstances, and one of those is when doing conventional development which, as Rails taught me, is very important in web/MVC programming. 

  • Avi Block

    I understand that inheritance is fail in most designs, but why in web frameworks more than anything else?

    • I wouldn’t say “more than anything else”, but “more than most circumstances”.  Because building web apps, like most UI-heavy apps, are all about composition (composing smaller pieces of info onto the final rendered page). 

  • I’m trying to figure out if this is a joke or link bait.  

    • Quite serious, though I did purposely use the polemic style, hopefully to get people to listen. It seem far too many people have no problem with huge controller classes, or even that their framework has massive (and massive fail) base classes for “controllers”. And then there’s the abomination that is AR. Every language/framework seems to have one — the massive base class with “save” and “load” methods on it — and it’s an anti-pattern and a huge design fail in every language and framework, including Ruby/Rails.

      • The thing you seem to be forgetting is the purpose behind web frameworks, they are a means to an end, not an end to themselves, which is what you seem to believe.

        Rails (and other similar frameworks that you think are “wrong”) came out of a need to speed up the web development process, and at the same time build easy to maintain, easy to understand applications in a fraction of the time it takes to write them previous to their coming to be.

        Things like getting wrapped up in whether a test is technical a Unit Test or an Integration Test is getting tied up by semantics and is completely losing the forest for the trees.  It’s the kind of stuff that drives non technical people crazy, because it doesn’t matter.  Does it matter that Active Record isn’t technically an ORM?  Not at all, it’s one of many possible solutions to a problem, the fact that it doesn’t technically adhere to a definition that you care to apply to ORM means nothing to a customer.

        This entire post is a classic example of “show, don’t tell”, because it’s really just an advertisement for why you feel your framework is better than the other ones out there.  The reality is, you should be showing it.

        If Rails and things like Backbone have show us anything it’s that if there is a better way, people will gladly move to it.  If Fubu is indeed all these things, and all these things make for a superior web framework, the proof should be in the pudding.  I’ve tried out both major incarnations of Fubu and I’ve used Rails (and ASP.NET MVC and other frameworks), and Fubu doesn’t make life easier than any other framework the way Rails makes life easier.  Maybe it will down the road, and that’s great, but saying stuff like it’s better than Rails because C# is statically typed is just silly.

  • Anonymous

    “Just because you wear thick rimmed glasses and drink lattes with your scarf flipped casually around your neck doesn’t mean you get to throw fundamental principles out of the window.”

    French press, actually. But close! :)


    Microsoft Visual Studio Program Manager, 2003-2007

  • I’m taking a break from my latte to complement you on a class-A rant. Good show! I tip my scarf to you!

    • Giles

      Seriously? This was unreadable blathering which featured a bunch of unimaginative name-calling and not a single line of code. I’ve written better rants while asleep.

      Just google James Golick’s post on disentangling ActiveRecord from models (something like “the crazy heretical way I write Rails apps”) and Chad’s main points in his rant all disappear like dust. It’s a blog post from 2010 or 2009, ffs! You can’t expect people to take you seriously if you make broad claims about what Rails developers do, but those claims lag behind the state of the art by YEARS.

      The same applies for testing in the DB — plenty of ways around it — and his demand for ORM agnosticism, which Rails has had for a while now, AND his complaining about logic in templates, which many of the best Rails devs circumvent by using Mustache. This would have been a worthy bit of foaming at the mouth in 2006, maybe even 2009, but in 2012 it’s just ignorant trolling. Some of the complaints he has are pointless and idiotic, and as for the rest, it’s not only easy to work around these limitations, it’s becoming de rigeur in some cases, and it’s even built into the framework in at least one!

      Complete and total waste of time.

      • I’m aware Rails has ORM agnosticism. Why is AR still the default, primary option, though?

        I’m not sure you really read my post or even tried to understand the larger points I was making.

        • Giles

          Well, I didn’t read your post. I’m sorry but it just didn’t seem worth the effort. If Avdi busts me on the things I said, and it turns out I was way off base or something, then I might read your post, but (again with my apologies) I really don’t see it happening. The fragments I skimmed just made the whole thing seem utterly senseless.

          • Giles

            Hi Chad, sorry, I read Avdi’s reply and I’m basically not going to read your post. Very sorry, very rude of me. I came down to the comments section to object to the donkey in your header, which I perceive as very racist and utterly inappropriate, and while I was down here I saw Avdi’s appreciation for your rant and expressed surprise and disbelief due to being surprised and having a hard time believing it.

            Best of luck with FubuMVC, please reconsider the donkey, and please also investigate the state of the art with Rails, as you’ll find the best Rails devs share some of your criticisms, but respond by fine-tuning Rails with power tools, rather than ranting about scarves and lattes or indulging in what looks awfully like NIH from here.

          • @ce8b03e5750097942c58e12b46724312:disqus  Ok, then let me distill it for you and remove all the bluster, hyperbole, and purposeful antagonism? :)

            Inheritance = bad (except in very small doses, and not in the core of your framework and not required for consumers of your framework)

            OO principles matter in any OO-ish language. If you’re doing OO-ish programming (even in a lang that isn’t strictly OO, like JavaScript), then follow core OO principles.  Just because it’s easier to work around the principles in Ruby, JavaScript, etc. doesn’t make it right.

            Composition is a key component for success in any framework, especially web frameworks.  Rails does a mediocre job of this which is sad since Ruby has really amazing and awesome OO composition possibilities baked into the language. In short, Rails could be SO much better, it’s frustrating to me that they purposely chose poor design choices in a few areas.

            ActiveRecord-style ORMs/data-layers (and I mean the original Fowler PoEE “ActiveRecord” pattern, not necessarily Rails’ implementation of it) should be used very carefully and only for small CRUD situations.  It’s frustrating to me that this is the default, encouraged route in Rails. This is the whole “falling into the pit of success or failure”  As Rails’ adoption grows, you’ll get more and more people who don’t know what the hell they’re doing and will make a mess of things with AR.

      • I didn’t say it was *right*. It’s mostly strawmen, ignorance, and inexplicably using the willingness of the Rails community to constructively criticize Rails as an opportunity for schadenfreude. Oh, and self-promotion.

        But there were several moments when I genuinely laughed out loud, so I still enjoyed it as a rant :-) Not as good as one of yours or Zed’s, but that’s a pinnacle we all can only aspire to.

        Not to mention that as much as you or I avoid stuff like “Unit Testing” the DB, there is still a buttload of Rails code doing just that, and a decent number of Rails developers who claim that it’s no big deal. We haven’t completely transcended all the issues criticized here.

        • Giles

          OK, fair enough. Thnx for the flattery, geeez. I have to admit that although the in-db testing workarounds exist, I’ve often ended up doing it anyway on many projects, although in my defense, I certainly want to put those days behind me. I basically want to be Gary Bernhardt when I grow up.

        • It’s not schadenfreude. I don’t glee in problems in the Rails community. I’m tired of ignorant Rails people telling me how great and wonderful things are and spitting on me when I tell them that inheritance designs are seriously problematic and that AR-style data layers are seriously problematic for serious/considerable projects. 

          To you and me and most intelligent Rails folks, this is common sense, but yet I get made fun of and called names since I once used a .NET compiler.

          I’m glad to hear people in the Rails community speak up, especially when they’re saying things that I feel very strongly about :)

  • Somebody needs a hug.

  • Jay Godse

    Interesting post. I’m a programmer, and not a great one. I have tried to write web apps in Java, .Net, Perl, PHP, and Ruby/Rails. I have succeeded very modestly with Perl, and succeeded solidly with Ruby/Rails. 

    Why is Ruby/Rails great? The number one reason is feedback. When I am  trying to solve a problem, Ruby and Rails makes it easy to try out different ideas and test them and get immediate feedback. I can rapidly iterate towards a solution which works. This is not as easy to do with statically typed languages. 

    Another reason is that I find Ruby much easier to read than Java, .Net (C#) and PHP, and this makes it easy to incorporate and/or adapt 3rd party code. This makes Ruby and Rails very useful to me. 

    Another reason is initialization. With Rails’ scaffold generators, I can go from a whiteboard software session to a quick and dirty Rails prototype in an hour, and for simple apps that drops to about 10 minutes. That is not possible with most web frameworks. There is immense productivity benefit in always having something that works. 

    Another reason is the Rails console, and “raise Exception”. In a web app, I use both to stop the code to inspect variables and to try stuff step by step. I have found those two tools more effective than trying to configure a debugger to work in a variety of languages and IDEs (including Ruby). I’m sure that many would consider me lame and incompetent for this, but it works for me. 

    Your biggest criticisms of Rails revolves around maintenance, evolution, and performance. You’re probably right, but it doesn’t matter. The biggest problem in software productivity is that people are building applications which nobody wants to use. Rails lets you get to the point of people using the application much faster, and if you built the wrong application, failure is cheap. If you built an application which people are willing to pay for, the P&L leader will not withhold funds to pay for expensive maintenance and scaling, albeit grudgingly. The one thing P&L leaders hate much more than this is paying high software development costs for unnecessary quality before the market for the application has even been validated by enthusiastic users, and paying the high opportunity costs of late delivery. Ruby does very well at reducing the costs of building applications which nobody wants (by letting developers develop quickly), and it reduces the market opportunity costs by letting developers develop quickly. 

    I can’t wait to see how FubuMVC beats Rails on these points. 

  • Anonymous

    Okay, I will take the bait. Why exactly do you find controllers so wrong?  I agree that monster controllers are hard to work with, but that is the case with any big class.

    And the need to expose resources/actions exists whether we use a controller or not. So we can either have one controller collecting related ones together, or we can break each of them into its own page, as some people did before the rise of the MVC web framework. At the end of the day it doesn’t matter if you have to search through one class or your file system to find right function when something breaks down.

    Also, do you have a sample app in FubuMVC so that we can see your opinions expressed in the form of code?

    • @hugoestr:disqus , you are absolutely right… As @j3:twitter has said before, be suspicious of any controller method longer than 7 lines. I’m sorry if @chadmyers:disqus has had the misfortune of encountering poorly coded Rails apps, but that’s the fault of the developers of those apps, not Rails itself.

      • I would say it’s the half the fault of the developers and half the fault of a framework (like Rails, ASP.NET MVC, etc) that encourages that bad design.

        That’s the whole point of my post: If you’re stuck in the “controller” mindset, you’re going to keep falling into the pit of big-action-methods and lots-of-action-methods-on-a-controller-class

        • Anonymous

          Okay, Chad, so it seems that there isn’t an example out there of well written fubuMVC. If you are using it within a company of clients, that makes sense.

          Could you at least link me to a post where you flesh out your argument against controllers and why your way is better? I may end up agreeing; I just don’t know yet.

          • @hugoestr:disqus Unfortunately I can’t think of a blog post that spells it all out clearly. Apparently I have my work cut out for me.

            It’s been a process of discovery the past few years, messing with MVC frameworks and seeing the problems that arise.  We’ve discussed the controller-less action concept on the mailing list and have reached a shared understanding. But we’ve (I’ve) failed to communicate this well outside of our circle. I apologize.

            The root of the argument lies in the concept of “Composition vs. Inheritance” – If you’re thinking compositionally, then the ideas of a “Controller” base class, and a class with lots of unrelated methods doing a lot of unrelated things, becomes abhorrent (as it should).

            Many controller action methods do far too much: input validation, model binding, model validation, business logic,  some persistence, and then deciding what to do next (render view, redirect, etc).

            These are far too many responsibilities for one action method, and then when you have 3-4 actions per controller, you have a big mess.

            Thank you for inspiring me to write a post on this subject.

            I wrote a post about Composition vs. Inheritance awhile ago which you may find interesting:
            (note is has a little in there assuming static typing and IoC containers, you can just skip over that part, the rest should apply to any OO language/framework)


          • Anonymous

            Hey,  if you haven’t gotten around explaining why you don’t like controllers, that is fair. 

            I see now that part of the problem is violation OOP principles. And you are right, a lot can happen there.

            Okay, now I have the proper perspective to look at the documentation of fubuMVC to see how you solve these problems.

            Thank so much, and I will look forward to that article in the future.

  • “One class — that derives from some gawdawful ginormous base class — that has many “action” methods on it is a pile of fail.”

    I remember a discussion about this on some mailing list ages ago in relation to repositories. In each situation you’ve potentially got a class with methods that do different things and don’t talk to each other so as you say it could be seen as a SRP violation.

    However someone (Greg Young maybe) noted that things like repositories/controllers/resource handlers are layer entry points, they provide an interface into your layer. The question is then whether having a more fragmented approach (each action its own type) really provides a better interface. Arguable.

    Regardless I’m not sure it matters as much as you are making out, these sorts of classes (repositories/controllers/resource handlers) should not have much code in them anwyay, they tend to delegate for most of their work so I don’t have a problem with their existence. I’m obviously open to admitting I could change my mind on this at some future date though.

    The big base class thing is more of an issue though, that I do dislike.

    “And then you have the whole “Unit test against your database” phenomenon.”

    Yeah I’ll admit that messed with my head, I couldn’t believe people were running these big slow test suites against the DB. It is now being addressed by people who do care about the speed of their tests, I can dig out some links if you want.

    “To call ActiveRecord an ORM is to insult the already sullied and notorious name of ORM. ”

    I obviously agree on importance of model but if thats an issue, if you are working on an app with non-trivial business logic, then just move that out of the (Web focussed) AR model that you are using with Rails.

    “Your routes should flow out, conventionally, from the model as much as possible allowing proper REST scenarios”

    Pants on head thinking here :P

    No good domain model is going to map nicely to an HTTP (RESTful or not) service layer.

    “In many ways, FubuMVC is better than Rails and I’ll put my framework up against yours any day of the week”

    Now you’ve got your rant out of the way and set the stage have you thought about taking some of your key bullet points and describing how you’d do them in FubuMVC so people can compare them to typical Rails solutions?

    Might be a good way of getting people up to speed on the design approach around Fubu.

  • Anonymous

    Chad, while I agree with a lot of what you had to say, I think the main thing that is being overlooked here is that you are approaching this from someone who is developing a web framework.

    Most developers are delivering business apps to businesses for business value.

    While I know that you also do the same, the POV of this post was from that of a web framework developer. This is harmful, because it felt like the theme of the post was how to create the best web framework, or how the best web framework should be built.

    Most developers don’t care how a web framework is built, they care how their business app is built.

    Before you start, I know that the framework can encourage developers to build their app “better”, and I’m not trying to give a pass to these people or excuse them. It’s just that here you are viewing the framework as the product (as you should, since you are developing it) while everyone else views the framework as one of many tools to develop THEIR product. Again, not  trying to diminish any of the points you made, as they are all valid and all very important, but approaching this from the POV of a framework developer tends to appeal only to: 

    1) Other framework devs. (1%, who will only get defensive about being flamed like this)
    2) Framework fanbois. (90%, who would rather die than give up their framework)
    3) Ivory Tower, Armchair Quarterbacks who have never developed a web framework but, for some reason, think that they know how. (me, and I just like to pop a bag of popcorn and watch the flame wars as free entertainment)

    And it is therefore, unfortunately, primarily ineffective.

    • I’m not asking people to leave Rails. I’m asking them to improve Rails.

      • Anonymous

        I guess I missed that part…

        • I never said “Leave Rails”. I just pointed out a lot of its design flaws.

          The irony is, Ruby is prime for building a compositional web framework because object composition design is very easily and elegantly done in Ruby.

          The convention stuff is nicer in static-typed languages, though. So it’s a trade-off.

          • Anonymous

            That’s true, you guys have done a very good job of taking what most people consider a drawback of C# (static-typing) and really found good ways of using it to your advantage.

            …instead of just thinking of it as a way to make sure you don’t assign a Foo type to a Bar type.

  • Giles

    Can you guys do something about your racist header graphic please? I really don’t appreciate it at all. The whole world is not Texas, and if you want people outside your state to take your opinions seriously, the least you could do is leave behind a graphic which appears to date from before the Civil Rights Movement of the 1960s. I mean it’s been fifty years now.

    • Whine_a_little

      Who cares. 

      • NorwegianDude

        Well, he does, obviously. :) And probably others too.

    • Jimmy Bogard

      Racist header graphic? What’s racist about it? It was created by one of the founders of Los Techies, Joe Ocampo, a Mexican-American from San Antonio.

      And his name is Pablo!

      • Anonymous

        well the idea I get from the graphic is: “retarded nerd mexican donkey “

        • Not retarded, just silly.   Nerd, Mexican, and Donkey are true. It goes with the “Los Techies” Mexicana vibe.  LT was founded by folks in San Antonio which has a strong Hispanic culture and vibe. 

          So if people consider exhibiting Hispanic culture is “racist” somehow, then I’m sorry that they have such a white washed, bleached concept of culture and society that they are offended by the mere exhibition of  cultural display.

          • msuarz

            yo llevo buen tiempo siguiendo este blog y nunca he visto nada q de la idea de un ‘Hispanic culture/vibe’ … just saying … it does looks a bit racist to me … only it doesn’t really bug me

          • Most of the original LT folks were Hispanic from San Antonio, if I recall correctly.

            Would it change your opinion at all to know that the name, logo, mascot, etc were all chosen and designed by people of Hispanic origin?

          • not really … i consider Carlos Mencia quite racist … being from a minority shouldn’t give u a free card to do what others outside can’t … so in general i could care less if Benito Juarez was the founder 

            i have a higher tolerance to racism that an average … the theme of the logo n’ name doesn’t really bug me … but if i am to pick yes/no i would call it racist based on the fact that it is a stereotyped mexican/texan lingo which has nothing to do with the actual content or style of the content published in the site 

          • Joey

            Incredible what “Politically Correct” has come to when people troll blogs looking for logos to label racism.  Reminds me of when Rasheed Wallace called the NBA a bunch of slave owners.  He was making 12 million a year at the time.  I am sure that all the souls that suffered at the hands of slave owners, all the families that were ripped apart, the generations of people plunged into poverty to this day felt vindicated when a millionaire athlete compared his inability to make $13 million a year playing a game to their plight.  He knew EXACTLY how they felt, what they had gone through.  

            Calling the logo racist is disrespectful to the millions of people that have suffered at the hands of racism.  How many people have died in the last 100 years through wars raged over racist notions? And your charge to rectify this is to go and critique graphics?  Wow I guess all of the evil in the world better look out there is a fat troll on a couch somewhere fighting for justice!

            How much you do you make while sitting in front of a computer sipping non-diet soda ruminating over what this particular logo will mean to the family who dares everything to cross a border in the middle of the night at the hope of a better life making less than minimum wage.  Although they would love to take up the ’cause’ with you, unfortunately they are trying to survive and do not have the time to troll.

            Pointing out a logo as racism is a slap in the face of everyone who attempts to truly address racism or inequality wherever it exists.  You trivialize what so many people have gone through, what so many people are GOING through right now by casually pointing out logos as racist.  

            I would like to forward your contact information to some people in Uganda, Mexico, Tibet, Northern Iraq, Turkey, Darfur, Southern India, to let them know that they are not alone in their plight, but that there is also a fatass in the U.S. that is going through the EXACT same thing and he is not going to take it anymore!

        • Joey

          That is a reflection of your inner psyche not the graphic.  You could just have easily interpreted the logo as an industry (nerds are cool in IT) compliment to the Mexican-American contribution to the industry.  You could also have interpreted it as a sexual innuendo, call to arms for PETA or anything else!  Interpretation is your right as a person, just as expression is the right of the person who owns this blog.  

          Your avatar could easily be interpreted (give someone the idea) that you promote Nazi-esque values and attempt to glorify the life of criminals (mugshot photo) and crime overall.  BTW, do think there is anyone out there that was offended by our use of the term “retarded”?  You may not care about that particular group of people or if they take offense, but then why would anyone care what you think? 

  • Nicolas Garfinkiel

    Its always a shame to see smart people lacking essential qualities like humility, so necessary for true knowledge…

  • Some great zingers, Rails people are sexist arrogant bastards, with some exceptions.

  • Anonymous

    1) Traditional OO does not apply to ruby, ruby software is not designed/architected as everything else. Ruby has new paradigms funded completely on the dynamism of the language. Everything you know about OO is obsolete. Partially the same applies to C#. Do you think people is writing software the same way they write them in Java? They are actually pushing forward the possibilities of the language and deprecating old-school way of doing the things.

    2) Object instantiation hurts. Composition is not always a good choice even if its “theoretically the correct way”. Zend Framework partially fits your “way to go” and it’s a pain in the ass to use it. Everything is so “modular” that you even need to glue the damn router and the front controller into your app. So before writting a single line of your app you already have 500+ lines of “framework configuration”.

    3) Your conception of “convention over configuration” is clearly wrong. Mapping all the “behaviors” to Fubu “controller classes” is not a convention, it’s clearly configuration even if it’s not XML-based.

    4) Generally, people are not paradigm talibans. If you want to create something new, be creative and engage people instead of being a jerk.

    • 1.) This point makes no sense. Maybe your definition of “OO” and/or “Traditional OO” is mistaken. If you mean “C++-style OO”, then I would agree with you. Unfortunately that’s what many people mean when they say OO and they’re wrong.  To quote Alan Kay: “I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind”

      Many people in Java and C# program with a C++ mindset (heavy inheritance, lots of big nasty classes, etc).   So yeah, that’s very wrong and I rail against that notion heavily and often on this blog.

      2.) So poorly implemented composition means composition is wrong?  That also makes no sense.  What if you had a framework that made composition natural and easy and flowing?

      3.) I don’t understand this. I don’t think you understand what behaviors are or what I mean by “conventions”.  Fubu has dozens of different types of conventions and leverages static typing heavily as a tool (and not as a crutch).  Rails has a few conventions that are baked in and based on the file system or strings. Fubu has a rich model from which to develop elaborate conventions for all sorts of things, not just view location or controller discovery, but form builder/generation (something that sucks in dynamic type systems like in Rails or Django), HTML fragment generation, model binding, validation, etc.

      4.) I have tried the nice approach, no one listens. Programmers only listen when you’re a bombastic troll jerk, this post has proven that definitively to me.

      • u r avoiding the fact that OO is way different in Ruby/Javascript … so the big point of inheritance is not that relevant … SRP is still quite relevant … DI as in StructureMap convention whatever is irrelevant … testing and mocking is quite different … u simply don’t use or know those language that much

        yeah everybody is gonna make messes in any platform … i could go on n’ on … but mostly i’ve been pissed at this post since the first day because it keeps damaging the .Net community … MS doesn’t care and ALT.Net imploded … all that’s left is an inbreed community in Austin … think about that

        • I disagree with this: “OO is way different in Ruby/Javascript” – it is fundamentally the same. Sure, you’ve got things like Ducktyping, Modules, etc in Ruby, but the fundamentals are still there and the fundamental principles still apply.

          I don’t get your comment about “inbreed” [sic]. Sounds like you’ve got some bitterness about something and you’re taking it out in my blog.

          • Guest

            Right, and there sure was no bitterness in your post!!

  • Pingback: Not Rocket Science » Thoughts on .net in 2012()

  • Pingback: The state of “web-based” MVC » Justin Lovell's Blog()

  • Chad, thanks for great article that sums important things about concepts around MVC.
    I agree with everything you said.