After reading “Rails is yesterday’s software”, I need to reply

Moving on from Rails sounds great until you try to build a serious web app with one of the alternatives. While I think that many of the architectural criticisms are valid, Rails demonstrates the primacy of ecosystem and strong conventions over language design and cs theory.<p>&#x27;Tomorrow&#x27;s&#x27; languages and frameworks would do well to take heed. Winning this war has as much to do with culture and marketing as algorithms and data structures.<p>Clojure, for example, is a much stronger programming language than Ruby on paper, but for a straightforward web app, you&#x27;ll likely spend <i>at least</i> twice as long to get something working--and while it will be based on better engineering principles, it will also take new engineers much longer to grok since it doesn&#x27;t follow any universal set of conventions.<p>With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter.

This is the old &quot;use the right tool for the job&quot; cop-out. The original post went deeper than that. I would summarize it like this: can modern complex, large-scale web apps be built with the tools we have today, be they Python, Ruby or Javascript?<p>Or do we need an entire new class of tools which have traditionally been used to build large scale systems in the past?<p>It&#x27;s a multi-faceted question of type systems, tooling, packaging, dependency resolution and others. And as web apps continue to evolve, my guess is that the current tools will be considered lacking.<p>It used to be that picking &quot;the right tool&quot; meant choosing between Ruby, Python, PHP, JS. In the future it might mean using (gulp) Java + WebAssembly or a combination of other unusual tools. This would be quite game-changing for most web developers. ;)

Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -&gt; 4.1.x... 4.1.x -&gt; 4.2.x<p>It was, and still is, a nightmare.<p>Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruciating. Many things broke in subtle ways at runtime (no compilation, so no compiler errors) and there was no clear path to upgrade; because whilst Rails&#x27; upgrade path is documented, there&#x27;s a plethora of Gems that also needed to be upgraded separately (some in contradictory manners).<p>You might wonder why I was so out of date in the first place. Two reasons:<p>1. I inherited this code-base.<p>2. I&#x27;ve attempted this (or a similar) upgrade about 5 other times in the past; spending hours upon hours debugging crashes (or just weird behaviour) with enormous stack-traces where my application&#x27;s own code often doesn&#x27;t even appear in the stack trace. It&#x27;s only now after making several failed (or rather overly time consuming) attempts I was able to come up with a &quot;workable&quot; upgrade path.<p>Gems dynamically generating methods left, right and centre, Gems replacing methods of seemingly unrelated classes (when they definitely do <i>not</i> need to), and crazy &quot;conventions&quot; that hide all the actual logic make debugging any sizeable Rails project a complete disaster. Don&#x27;t even get me started on the poor performance, much of which is to do with poorly designed Gems and not even the Ruby interpreter&#x27;s fault.<p>That said... I still turn to Rails when I want to get a new project (with users, database, login, admin etc.) up and running quickly. It&#x27;s a shame, but in terms of development speed, it&#x27;s hard to beat Ruby (and Rails). For small projects Sinatra is very solid, and Padrino is interesting - but honestly I can&#x27;t wait for the day I can move to a compiled language and still achieve this sort of development speed.

&quot;makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug&quot;.<p>This &quot;let someone else do the work, get it from a gem&quot; mindset is what kills long lived projects. It has nothing to do with the tools and everything to do with experience.<p>You don&#x27;t need 1000 gems. Managing anything more than core dependancies in a project can easily create exponential bugs and consume all your resources to fix. Remember left-pad?<p>This is true in any language and ecosystem and has nothing to do with rails&#x2F;gems&#x2F;ruby. The same is with Python, JS, PHP.<p>Senior&#x2F;Lead devs need to carefully curate what a projects foundation <i>is</i>. A strong, well designed foundation means you have something solid to build on. If you don&#x27;t understand what&#x27;s in your deps, haven&#x27;t read their code, see how often it&#x27;s updated and how many people <i>actively</i> use it, and can say you are using <i>80% or more of the code in it</i> then don&#x27;t use it.<p>Writing your own code is often the best route since it fixes your exact use case, no matter the language, libraries or frameworks being used.

Author is being nice, but I&#x27;m happy to point out that author of replied-to post is revealing they are a frustrated novice. All the focus on &quot;Rails made programming cool&quot; tells me &quot;I do things for dumb reasons.&quot; Clear case of chasing the dragon.

Reposting a reply I put on the original submission, but pertinent here as well:<p>Use whatever tools&#x2F;framework you want. Whatever it is you use, you will eventually become [the original] OP. The reality is that every language&#x2F;framework has warts. As you use it and get deeper into it, you will uncover these warts. Eventually, all you can see is the warts.<p>It&#x27;s important to take a minute every once in a while and look at the thing you built from a user&#x27;s perspective. See what problem you&#x27;ve solved for people, or just what cool new thing you&#x27;ve built. Staring at a bug backlog and a mountain of tech debt will always get you down about your project, but that&#x27;s the reality of programming...bugs and tech debt.

I feel like this is a terribly lacking reply. I&#x27;m not a trend-person by any mean: I&#x27;m a deep-backend developer, and my main language right now is Java[1]. However, when I have to maintain rails apps, even well-written ones, I find myself frustrated. I think ceding the advantages of a compiler is a fundamental mistake. Compilers and static checkers make for better software more easily; they don&#x27;t replace tests, but they complement them and constitute compilable documentation for your code, enhancing its maintainability considerably.<p>[1] I write in Java because I work for a Java shop, but even if I had my choice of languages, I&#x27;d probably be using either Swift or a compile-to-JVM language.

Many of the complaints against Rails in this HN discussion are around code base maintainability, gem proliferation, and amateurs.<p>Any tool that allows the rapid (almost effortless) accretion of complexity will suffer these problems. It goes with the territory.

The author leaves the business needs completely off the table, even though it would help his case. If you have a limited amount of time to launch your product in your current round of funding, and you want a framework that helps a small number of tech employees build working first generation critical features reasonably quickly, handle a large number of tasks not critical to the company&#x27;s value proposition reasonably well, can be maintained and scaled on a variety of PaaS options well long enough until the company is profitable enough to move to the next phase of tech infrastructure, is Rails attractive software? I&#x27;m not an expert with it, and I don&#x27;t even enjoy using it, but I believe it is.

Some software does become &quot;yesterday&#x27;s software.&quot; I&#x27;m looking at you Cold Fusion, Flash, COBOL, the Abacus. I don&#x27;t think Rails belongs in this group. I recognize that it&#x27;s a good framework even if I don&#x27;t personally like.

I personally love ruby and rails and still find it to be extremely effective and adaptable to most web development tasks.<p>As people flee the platform a huge amount of opportunities are going to open up for that still enjoy the platform. I can&#x27;t wait.

The problem I feel with Ruby and RoR apps is that people bang gems together without knowing how those gems do what they promise to do, what those gems depend upon, what those gems monkey patch, what they <i>change</i>.<p>Further down the road, maintenance drowns you.<p>I&#x27;ve rallied against this mindset before, e.g. regards security <a href="http:&#x2F;&#x2F;williamedwardscoder.tumblr.com&#x2F;post&#x2F;43394068341&#x2F;rubys-principle-of-too-much-power" rel="nofollow">http:&#x2F;&#x2F;williamedwardscoder.tumblr.com&#x2F;post&#x2F;43394068341&#x2F;rubys...</a><p>I find large Python apps fairly unmaintainable too, but to a much lesser degree.

There is, perhaps, a law, such that any project with a strong tendency to pile up more crap instead of reducing it to &quot;just right, when nothing else could be removed&quot; (a-la 9P2000 protocol, and few foundation libs of Plan9) will end up in a J2EE-like pile of collective stupidity.<p>At least, everything in nature tends to get reduced to a local optimum by a straightforward optimization process of trial and error. There is no way to make a reliable and efficient complex system by piling up more and more crap.<p>And, funny enough, JavaScript will be even worse - it already makes J2EE look not that bad.)

I&#x27;ve got my problems with Rails: routing is overly complicated, the asset pipeline can be tricky, and so on.<p>But Rails is very good at producing HTML and, in particular, partial chunks of HTML. As the current thick-clients-in-javascript trend cools off (it&#x27;s happening, this was at the top of &#x2F;r&#x2F;webdev yesterday: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;webdev&#x2F;comments&#x2F;4iphv4&#x2F;12_year_of_progress&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;webdev&#x2F;comments&#x2F;4iphv4&#x2F;12_year_of_p...</a>) people are going to migrate back to HTML as a transport for web apps, using libraries like <a href="http:&#x2F;&#x2F;intercoolerjs.org" rel="nofollow">http:&#x2F;&#x2F;intercoolerjs.org</a>. (Disclosure: I developed it)<p>Rails is well positioned for that.

Dynamic languages reduce the formal overhead required to develop new ideas.<p>I can&#x27;t imagine that an &quot;eliminate boilerplate via convention at the cost of explicitness&quot; mentality would have evolved independently in a world where assurances are earned by proving extra properties to the compiler.<p>However mordern compiled languages now formalise the shortcuts afforded by dynamic languages, e.g. type inference, generics, implicit conversions, typesafe macros, type classes, etc.<p>Similarily conventions popularised by rails-esqe frameworks are being formalised using the tools listed above.<p>I fall into the scala camp, but have used rails at a previous job. My guess is I need 1.5x scala lines vs Ruby which I believe is a justified cost. Opinions of course vary.

At the moment, the alternatives mentioned to Rails aren&#x27;t actually alternatives. You are still going to make major trade offs in productivity compared to Rails...<p>Unless he&#x27;s talking about Elixir and Phoenix, which IMHO is the future of web development.

I have to say I&#x27;m loving reading the thoughtful and insightful comments on this thread.<p>With any programming language and&#x2F;or framework you have to pick your poison. Rails backloads a lot of big development obstacles that ultimately you may never actually encounter in the life of your app. The issue regarding gems can be aggravating. But the speed in which you can get your app built cannot be understated. Rails is not a one size fits all, and you might eventually outgrow rails (i.e. Twitter). Be grateful the framework got you to the point you could outgrow it, rails helped you get there.

In the original article, he indicates Swift, Rust, and Go are tomorrow&#x27;s languages. The issue really is that the level of support in the various frameworks, the eons of bug-crushing and feature additions, and the libraries available, are going to be behind for some time. This is why I&#x27;d still gladly pick Django today.<p>What is &quot;the future&quot; isn&#x27;t really so interesting as what is productive.<p>Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries.

Fully agree with the post. Any time you&#x27;re making decisions based on some dogma versus &#x27;what is the best way to solve my current problem&#x27; you aren&#x27;t guaranteeing an optimal solution.

The thing is in many cases you had to make a choice between performance and productivity. With things like Elixir&#x2F;Phoenix you don&#x27;t really have to make that choice. Maturity argument again is moot as you are building on top of Erlang&#x2F;BEAM that&#x27;s very mature and has very good tooling. For people coming from Ruby the syntax also makes transitioning less of a pain.

In the comments of that HN post this link was posted which I found highly informative regarding the matter: <a href="https:&#x2F;&#x2F;speakerdeck.com&#x2F;tehviking&#x2F;surviving-the-framework-hype-cycle" rel="nofollow">https:&#x2F;&#x2F;speakerdeck.com&#x2F;tehviking&#x2F;surviving-the-framework-hy...</a>

It seems to me that a version of the Innovator&#x27;s Dilemma might apply to software frameworks as well.<p>By the time a project gets large enough it starts optimizing for its major stakeholders. New use cases or new ways of rethinking common use cases come along, and the small libraries that approach it from scratch have a narrowly-defined advantage. If the advantage is significant enough (e. g. virtual dom for browser UI), then new frameworks start being written around them, bringing back some but not all of the features of the older frameworks.<p>At some point (different for each user&#x2F;use case) the newer frameworks have enough functionality that people start considering them over the older ones for new projects. When enough of that happens, the older frameworks start looking like yesterday&#x27;s software.

PHP is the day before yesterday&#x27;s software, but it still gets a shitload of profitable work done.

I agree with this quite a bit. Even in my own projects, I love using Rails for web stuff, but I would never use Ruby for games. It&#x27;s a pain to distribute working binaries, and really is not an ideal language for games.

I&#x27;ve seen the biggest benefit from a client heavy approach even with rails. Make the api the core of your system, makes it easier to refactor down the road into microservices. For a lot of web apps there is no real need for server side templating, once you get beyond server templating its easier to make native versions of your app or use xamarian to access the same api from a common c# codebase for native. Place your business logic in the api and there&#x27;s really nothing for someone to steal from view source because your clients are just REST wrappers.

Sometimes I wonder if Ruby and Rails is 5x faster then now by default and allow really simple scaling without much thoughts, would it still get so much critics?<p>Most of the time People will answer saying moving away from Rails as you scale is a good problem to have. But the day Rails isn&#x27;t fast enough or scale easy enough is coming a lot quicker as the Internet Population expands.<p>And the good old saying of passing this to Morre&#x27;s Law no longer works as we haven&#x27;t had much CPU improvement.<p>I am hoping JRuby with Graal and Truffle will fix that.

Rails wasn&#x27;t even the best choice when it appeared.

Anyone finding any of this resonating really owes it to themselves to try elixir &#x2F; phoenix and, at the very least, keep an eye on it.

As more of the computational elements of UIs shift from server-side HTML to client-side Javascript, server-side frameworks like Rails, Django, PHP, etc. become less relevant.<p>Fast forwarding, many apps are (or will be) big JS blobs using APIs&#x2F;microservices back to the server. In that version of the future, frameworks like Rails can get in the way more than they help.

I&#x27;ve come to the conclusion that those who defend weak&#x2F;dynamic type systems and other unsafe toolchains simply buy into the fallacy of the uber-developer: the belief that while other, lesser developers need static typing and analysis, I&#x27;m so superior that <i>I</i> will never introduce those class of bugs, ever.

It simply boils down to what you&#x27;re most proficient with. Depending on the problem, you&#x27;re likely to encounter some technologies are better suited than others. That to me is where you&#x27;ll get the most bang for the buck, being able to decide on the right tool for the problem.

why do most people only see the extremes?<p>you don&#x27;t have to use bleeding egde libs instead of rails...<p>hapi instead of koa<p>react instead of cycle<p>ember instead of react<p>etc...

Great follow up article. Choose the right tool for the job.