Today I accept that Rails is yesterday’s software
medium.com
medium.com
https://speakerdeck.com/tehviking/surviving-the-framework-hy...
Nothing wrong with yesterday's technology if you're solving yesterday's problems! I don't mean that in a sarcastic or glib way, most of your problems really are yesterday's problems. Or even yesteryear's problems…. now that I think of it, when I depart from rails in a rails project (which is common), it's usually to use raw sql, unix, various networking protocols, or other programming languages that predate rails and ruby.
There was a good book out recently from pragmatic bookshelf called "rails angular postgres and bootstrap". Not saying you should necessarily use this stack (I don't), but the idea that you don't need to do everything in rails to use rails is worth listening to.
Generally, you're going to want to go back in time, to use tools that were designed for even older problems. For instance, why reinvent sql in a new language? If it's convenient to use active record and there's no performance hit, ok, use it, but don't go into contortions to avoid sql.
On a similar note, for those parts of a project where you really should go forward in time and start using tools that haven't withstood the test of time, by all means, go for it. But you aren't obligated to write the other 95% of the project in some new framework.
But yeah if you use them judiciously they can remove some drudgery.
Take today's example, using the Doctrine2 ORM. I needed something simple: For every user, find the number of articles belonging to them with a specific status code.
Seems simple. Except the dumb ORM way of count($user->articles) lost the JOIN conditions, and counted every article.
So the 50% way was to use COUNT(article.id) in the query via the ORM. Unfortunately, because it doesn't know where to put the COUNT() value, the ORM destroys the easy usage, and returns a collection of the user object and a scalar value for the COUNT().
I worked with it, but TBH going back to raw SQL in this case would've been much easier.
Pragmatism, the lost art (TM)
ActiveRecord for me hits a sweet spot in that it covers most of what you would need to do day-to-day in SQL and gives you easy ways to bypass it if you need to do something more complicated.
The biggest issue with ActiveRecord IMO is Rails devs who feel that falling down to raw SQL when it's warranted is wrong, and end up building insanely unreadable garbage using ARel (which in and of itself isn't a bad library, but should almost never be used in "high-level" code.)
There are also some queries that I think are best handled by find by sql oreven just raw sql. Sometimes this is performance othertimes it's for clarity.
Overall if you use an form properly I think it can save time and improve clarity.
The pioneer lifestyle is full of risks. Sometimes you want that excitement, other times you have different priorities.
But no, fixing stuff is hard. Let's write bitchy blog posts and blame everyone else.
As you say, the actual article is about how Rails has all of yesterday's flaws, which is pretty much the opposite of "reliable and boring".
After 30+ years of coding, my first encounter with Rails, a summer morning I received a ripped draft of a very early book on it remains one of the seminal moments of my career - so many elegant solutions to so many issues I'd grappled with since the mid-90s
As with any tool it's got some quirks and areas I could criticise - but it's got a place in my toolkit and will have for some time
As an aside, how do people consume slide decks? It doesn't seem as interesting without the associated lecture...
1. extensive speaker notes included as an addendum
2. all of the content on the slides (which usually makes for a bad presentation)
But srsly, thank you, that's very kind to say.
1) Batteries-included web frameworks (like Rails and Django)
2) Interpreted languages without strict typing (like Ruby and Python)
3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and the resulting difficulty in reasoning about the software
The last paragraph then goes on to suggest that different languages are required. This seems wrong. If you want to write web software you can reason about, you can still use web frameworks (maybe Flask or Sinatra) and you can still use third party packages (gems or things from pypi).
If you import a library (left pad or whatever) and call it from your code, then you can still reason about what's going on. The problem comes when you rely on adding packages that just talk directly to your framework (like Django middleware). Once you do that a few times, you really don't know what's going on between a web request hitting your server, and your own code running.
I think this is where the lack of strict typing can make things harder to figure out. Especially if you're trying to understand middleware functions with opaque signatures (like kwargs in Python). IDEs like PyCharm do their best at providing "Find all references", "Go to defintion" etc, and that helps, but it's not quite the same. Putting the info in the docstring is better than nothing, but it's still harder to parse (and maybe not machine parseable) and who knows if it's really correct?
Personally I'm really hoping mypy or type-hinting really takes off in Python 3, and makes everyone's life easier.
It also helps that most matplotlib kwargs can be controlled using an additional function, if you have a reference to the line/plot you want to modify. So you could do:
plt.plot(range(10), ls='solid')
lines = plt.plot(range(10))
lines[0].set_linestyle('solid')
This is where the fuzziness of the phrase "strongly typed" becomes a bit of a problem, but the fundamental idea is that there are two levels of meaning in the program, one static, and one dynamic, and the static level produces useful info. There are lots of levels this can take. The most common is in an IDE for a language like C or Python; it compiles or style-checks the file, warning you about issues, but it doesn't have any sense of what the program means. Another very common one is where you have non-code configuration files for GUI layout. You usually don't need a Turing-complete language to describe your GUI, so putting it in some other format like XML means the IDE can render the GUI and let you make changes to it without having to actually run your code. Strong typing for DSLs is just another example of the same sort of thing. If you're able to e.g. describe your models to the ORM entirely statically, it can figure out what a ton of your code means without running any of it.
I think this is basically what you mean by metaprogramming, except with the constraint that one of the two languages is pure and Turing-incomplete and doesn't rely on external input. Then the IDE can safely run that language.
I'm not saying that Rails is stupid anything (I'm not familiar with it), but maybe that's the way it is in the blog author's view.
Here is an example of stupid: someone writes some class framework or whatever. It's open-source. Yet, the next someone wants to extend it---but instead of a proper source code patch, they implement some monkey patch which relies on mutating things in the original framework after it's loaded. Then the next someone after that does the same thing to the second someone's customizations, and so on. Then to find out what is being called you have to trace through to understand the side effects of several run-time patches.
Let's not dump dynamic because of stupid dynamic.
It's a general complaint about Python and the tooling I suppose, not specific to web application frameworks.
Django bundles two DSLs - the ORM (filter, etc.) and the templating language.
>I don't think Flask attempts to be a DSL at all
Flask bundles jinja2 and sqlalchemy which perform the same purpose.
Though, being pedantic, Flask doesn't bundle SQLAlchemy (though it's what you end up using) unless things have changed recently.
Static typed languages tend to require that code deals with only a restrict set of types, and avoid metaprograming in exchange of other kinds of code abstraction.
I don't think this specific problem is big, tough. The dependencies one, by its turn, is huge.
Some disappointments about core.typed not being what some would have liked, but other than that...
So many gems are either not written well, or not maintained well. How many times have you seen the case where you update gem to fix a bug, and then cause two more?
It's not Rails or Ruby's fault, it's the community.
Consider: ImageMagick and OpenSSL.
Newer platforms haven't had this problem because they've already broken all their old software (Rust) or because they're still changing rapidly enough that new software is still emerging (Swift).
It's not the community's fault. It's that it gets harder and harder to keep things clean the longer your language has been around.
People get hyped about any language the same way. How many Erlang "experts" or Node.js "ninjas" are there out there? Give it a rest. If people want to get excited about something don't shit all over them.
Right about now is when you should go ahead and read his username, ideally out loud in your best Sean Connery voice.
I feel that the programming languages are being used here as proxy for something else: the community surrounding them.
Consider for a moment that most projects just need to figure out product-market fit before we know where to throw the money to scale. Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language.
This is why I continue to use Rails despite being interested in this that and the other new thing. It's very productive in terms of getting something up and running.
I mean, heck, Twitter started with Rails, and despite some hiccups, managed to grow. And Twitter is pretty much the poster child for something that has to scale massively. Odds are, you won't have the same problem.
Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.
Also, I haven't heard of an application that never had to be rewritten partially/optimised after X years in production. Some problems just don't present themselves in the first couple of years.
If it does scale, don't be surprised if you have to toss out your v1 and rebuild. The difference between a good framework and a bad one isn't about whether it survives scaling; it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.
So the important questions are:
1. Does Rails performance degrade gracefully under load?
2. Can you gradually shift away from a quick-and-dirty Rails-based implementation to something more scalable without the dreaded "rewrite-while-hair-on-fire" scenario?
In my experience, the answer to both of these is 'no'.
(But these challenges are hardly unique to Rails.)
About question number one: no idea, but you can add more machines and scale horizontally. Then you might ask if you want more efficient code between the web server and the database. You can optimize up to C. Finally, Twitter is still using Rails for the front end AFAIK, so it shouldn't be so bad.
Implying that Twitter reached success under Rails, even if it was _not_ the best fit for the problem set.
Dumping Rails when you have won the market is a nice luxury to have, one that most people on HN do not have.
(To be more specific, I object with how professionally-done Medium posts look, in contrast with their content, which often seem amateurish at best.)
For example, C is a great tool. But heaven help someone if they ignore its' sharp edges.
There is no silver bullet. So the best you can do is find something that suits you, and the task(s) you are trying to accomplish.
If your entire purpose is to ship a product quick, you should be ignoring the "too much magic, too many dependencies" narrative and building something, which Rails is wonderful at.
If I was learning, I'd build an app with the current stable version of 4, a toy crud app with 100% test coverage, then try to convert that to 5. Then compare that to building 5.0 using it's generators. You are likely to work with legacy code, so learning 4 is not bad. May well do that myself, so I'm catching gotchas like the integration test changes in my toy and not at work on a deadline.
But yeah, coding, at least for me, is all about trade offs, and as long as you understand the rails trade offs and mitigations, you are fine.
And honestly when it comes to learning languages ideas are transferable, the only thing that changes is the wrapping around it. Learn what seems interesting and useful, and use the right tool for the right job.
For any given technology which manages to take off at all, there's generally at least a ten year span during which some groups of early adopters are calling it "old and busted" and moving on, while other people are just discovering the "new hotness" and piling in. Just because this guy has switched from one group to the other doesn't mean you need to follow him; if the technology is good and meets your needs then hey, take it on, it'll be great.
The other thing that happens is... well, most of what this article is talking about has nothing to do with technology in the first place; it's more about the community built around that technology, and the fact that the author no longer feels like that community is going in a direction compatible with his needs.
I'm not part of the ruby community at all so maybe he's right and the "roadmap for rails is bleak" - but I'd bet that it's really more that it has developed further but not in a way that suits this author's needs, so he feels disappointed and alienated from the community, and he is observing that he and the rails community are drifting apart and will soon get divorced.
This says nothing whatsoever about the compatibility of the current rails community's direction with your direction, and it makes no useful predictions about the future development of the rails technology and its potential compatibility with your needs. It could be that the same forces driving this author away from rails are the ones which have brought it to your attention as something worth learning about and investing in.
Oh, the irony: https://news.ycombinator.com/item?id=8787117
Frameworks are like hamburgers at maccy ds - consumption for the masses, no thinking required. Later in life those decisions can be a problem.
Getting up and running and building things on a huge foundation like Rails is easy but you should also act responsibly and take the extra steps required to understand what's going under the hood. The effort of understanding a set of well defined "small" libraries is less daunting than a whole monolithic framework (probably with tons of bells and whistles you rarely even use) but both approaches (compare for example the style of the Clojure web app community vs Rails) have their benefits. A set of libs can be adapted more easily to specific needs and development of each of the individual dependencies can move fast without worrying about the others. On the other hand Rails changes relatively slowly but each Rails app being just another Rails app with all the pieces where you expect them to be can be considered a big plus in maintenance.
How much research has the author done to find other solutions? The plea at the end seemed very lazywebish to me. Or maybe ghost of Christmas Future-esque?
1. The costs of any layer of abstraction and magic that we have internalized seem free to us. So we feel free to add a more marginal one.
2. We have little visibility into any layer of the stack above or below ours.
3. As people migrate between languages, they take what they did previously and recreate it. Only "better".
As a result, complexity grows over time. And programmers are really bad at noticing/correcting it. And when they try, they will come up with different prescriptions. Often opposing ones. Explicit is good. (Go.) Don't let people mutate state. (Functional languages.) Convention over configuration. (Rails.) Move work from programmers to IDEs and tooling. (Java.) Make programmers productive so more gets done with less code. (Most scripting languages from Perl on.)
Over my lifetime, I've watched the resulting slide into complexity. Reading up on history I recognize that it had been going on for decades before I learned how to program. And it shows every sign of continuing to accelerate going forward.
I'm not following your reasoning. Just because Ruby/Rails runs slower than Java/Spring, why does that mean you "don't understand how web development actually works" if you choose Ruby/Rails?
That's a serious question. Runtime performance of a language/framework is only one small sliver of the overall performance of a large system. And overall runtime performance of a system is only one factor, among many, when choosing the right stack for a business.
I don't feel comfortable with all these behind the scenes scaffolding things happening. I prefer to design back-ends as data endpoints that feed a separate business logic layer. I feel like I have the most control of these things using java.
This lack of flexibility is precisely the reason that people choose Rails. It is a very opinionated solution and the Rails community doesn't hide that fact. The power of a Rails project is anyone familiar with Rails can walk up to it and get productive in minutes. All the code is in a standard place, the tests are run the same way, the deployment is familiar, etc.
On the contrary, look at 100 different Java projects and you would find 100 very different solutions. Getting up to speed on an existing Java project would take multiple times longer than a Rails project, even if you were generally familiar with Java + Spring.
If Groovy and Grails are technology "to dream about", one wonders then why VMware (the Spring backers) retrenched their 6 developers working on Grails and (what is now Apache) Groovy early last year, and why Sun Microsystems (the JVM backers before Oracle) wanted nothing to do with Groovy in its day (despite supporting the JRuby and Jython developers).
That's quite big for Groovy. There's a lot of exaggerated claims coming out of that ecosystem. Most JVM apps that size are actually written in Java, perhaps with the codebase duplicated a few times, and counting testing copies of the code in the LOC count. If the harness for testing is written in Groovy, you could call it a "1.5 million line Groovy app". If some of that Java code is compiled or run as Groovy code in some testing framework, you could call it all "Groovy code". If the Groovy code is called from some app written in Java, such as Grails, you could get creative and call it a "Groovy application".
> groovy static compilation seems to work great
And just what proportion of that Groovy code is really compiled statically and run in a production app?
Then there's their governance problem -- nowadays, a single person owns the groovy-lang.org website, whereas until early last year it was governed by 5 "despots" at Codehaus. It's never good when leadership becomes less consensual.
Rails' problems are its own, and Ruby's limitations and problem domain are well known.
This is a terrible blog post by someone without much perspective. I award it no stars.
I guess example #1 is method_missing. I get it, it's a huge time-saver and lets you do all kinds of cool things like specify a default behavior for an API if someone sends a random command, or, define the behavior of a method dynamically by the name of the phantom method. But then the rest of me is reflexively saying, "Seriously??" And I get that Spring Data does sort of the same thing, but at least there it's limited by domain. If I'm in a Ruby codebase that is taking regular advantage of that, my first instinct would be find calls that eventually go to method_missing, and then just define the damn method somewhere so that my IDE's "Find Usage" will work again. How the heck do you explore a codebase quickly if your IDE doesn't work?
I guess for me it just reinforces the same rules of thumb. Dynamic languages are fine if you're prototyping or doing an MVP. But as soon as you find that your codebase is being read/maintained more often than it's being written (which will happen sooner than you think), or as soon as you start finding weird production runtime bugs that don't happen in your local environment, you're better off with something strong or static or compiled.
As for how to get that safety full-stack these days, I'm still poking around. Scalajs seems interesting, or Angular2 with Typescript, or something that uses RxJs...
I have been doing clojure dev for a little bit, and here's what I do -
- Run tests in the background continuously (lein expectations will give you that. or you can write your own shell script)
- Do small checkins, frequently to git
- Write tests that enforce invariants. Haven't gotten to test check yet - but I guess that would be even better.
The trouble with types is they push you into a corner early, and after a while people will be coding to zombie constraints - the constraints that were there before, but not true anymore. They are also verbose, and need tooling to get you out of the corner. If the requirements change a little bit, it could be that, your old solution goes against the grain of the new problem, which is very hard to get rid of without rewriting the code.
With dynamic languages, I find that I think more about the problem, than trying to do constraint satisfaction with other entities in the code, not to mention the language itself.
I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints. If anything, having a good type system makes it easier to rip out code that isn't used anymore. And Generics can help with keeping your solution from getting too specific.
> I'm having trouble thinking of a time when I felt something akin to what you describe with zombie constraints
Think of deprecated methods in a class, unneeded methods in an interface that are stubbed etc.
> I also write plenty of tests with plenty of mocking
This is good. But what happens to mock objects when the underlying class changes its implementation - It needs a large number of changes in tests.
If you are writing micro-services, the guarantees that typed system gives you are more trouble than they are worth. If your average microservice is less than 10k lines of code, it probably reduces to 1000 lines of code in Clojure, and for the codebase of that size, typed systems provide little value for the cost(atleast for me).
But I'm still pro-types, and think they solve way more problems than they cause.
There is no textual or design pattern alternative to that - ides simply get you there faster and safer.
I’m not even defending Ruby or Rails here. Use at your own benefit/risk…as with every other programming language and framework.
This was one of the mistakes Django made and - to their credit - got over relatively quickly. It began as a kind of imitation of Rails but they stripped out the magic pretty quickly and made it a lot more explicit.
Also my first CRUD app was very small and boring. That means un-debuggable isn't a big deal. Now apps are huge, therefore undebuggable. Even if you limit external dependencies that doesn't help internal dependencies.
You can prototype things quickly, as long as they're small, featureless, no one uses them, and you don't care how difficult the are to deploy or debug. Other than that, no problem. Hmm.
2. In the second wave, we got languages like Ruby and Python which are flexible and easy for developers to work with. Sometimes it's more important to be able to iterate quickly than execute quickly. Server software, app backends, etc were all implemented in whatever language was easiest using HTTP as an interchange with other languages
3. In the third wave, developer experience enhancements that scripting languages pioneered trickled down to systems programming with new languages like Swift and Go. These give you most of the benefits of the second wave languages without their significant overhead. Since they are better suited to building small light services, old bulky Ruby / Rails app are starting to look antiquated pretty quickly.
I also used to go to Rails first for web projects... I use Go now because it's more lightweight. I used to do native apps in Objective-C... I now use Swift because it's easier to write.
That said, you will have to re-implement machinery that rails gave you for free. If you're building a simple API, there will be obvious simplicity benefits. If you're trying to build a server-side rendered web application, you may long for some things that rails provided (of course, you can use libraries and create simpler patterns than rails provided).
Note that going the sinatra+libs (or any "micro" framework for that matter) route places a higher burden on the development team when it comes to documentation. If you implement a scheme for server side templating/rendering outside of what is provided, you will be in a world of pain in a relatively short time if you do not maintain good documentation.
I maintain a large-ish Sinatra app that should've been done with Rails. Update cycles on the gems are a nightmare. It feels cobbled together. it's a "half baked homegrown version of Rails."
Someday I will just move the logic to a new Rails app and be done with it. It was a terrible idea.
* your experience may vary. :)
What makes it large-ish? The number of tables? The number of views?
What is the problem that large-ish apps give that Rails solves?
Genuine questions, I only do small projects and I honestly don't see a huge benefit to using rails, despite having used it before.
Moreover, the author seems to be imagining Rails as a huge monolithic piece of software. That does not need to be true.
Personally I design my Django code to be as simple as possible. I use third party libraries, and don't see too many of the problems he talks about.
So far, I still haven't seen anything better than Rails to solve yesterday's (and today's) problems.
We're out of new frontiers to innovate around and the work from now on is about playing custodian to the innovations of the past.
Unless something spectacularly interesting comes along, the priorities of the web are now all about supporting what's already been built. Either by maintaining something hastily built and cracking at the seams with patches and fresh coats of paint - or replacing it with something more stable for the long haul. Rails was designed around rapid innovation, not the long haul. So it's in maintenance mode.
I almost learned Rails in 2007 when it was at the peak of its hype cycle but after reading a series of (not very well publicized) tirades about pain that Rails' magic caused I learned Django instead.
I think node is at the peak of its hype cycle right now.
Go is great for plumbing, you can get network utilities up and running pretty fast with no dependencies so it's easy to deploy, that's its niche. Now try writing a complex eCommerce website, a news site, or any large app backed by a complex data model in Go...
I started to use Asp.net CORE on Linux with Postgres the other day and frankly, I don't want to hear about Go and its "simple" type system anymore when I can just use C# and do projects in minutes without fighting the language. Go is at at most a safe C with channels (without macros which make it worse than C in term of features).
My point is neither Swift,Rust or Go are silver bullets which will fit every use cases in Web Development. Neither is asp.net core,but for my use case there is no debate as to what I should be using.
Rust,Go and Swift aren't tomorrow languages. They are languages that fit a specific use case like every other language.
Rails could eventually get very fast, but it can be frustrating that it's not right now!
This is the same kind of problem of Ruby not having a proper x-platform GUI toolkit or binary packager: you have such a expressive and powerful language and still you feel you are limited by the lack of speed and tooling.
That's why, IMO, a Ruby/Rails dev frustration can explode in such a strong way at some point.
Sadly Ruby isn't backed by a big corporation, so you can only wait for the language and frameworks to get more mature.
Personally I've dealt with this frustration by learning C#. It allowed me to overcome all the current limits of Ruby, while avoiding the Java ShitFactory. At the same it feels great to get back to Ruby when you want to explore ideas! It's still an unbeatable tool for prototyping. Being aware that I have knowledge of another language, makes me feel better, less frustrated, and I browse Ruby weekly news with much less "anxiety" for a revolutionary Ruby improvement (but still I browse it because I know it will happen sooner or later!).
I'm quite sure that the OP after having vented with this post, and having found what for him is a solution, then he will peacefully embrace Ruby or Rails again under a different light (but again, I wouldn't be so surprises to see big improvements soon, so maybe it could even be a better light!)
When I first switched from PHP to Rails it was a natural choice whereas i don't feel Rails to Node.js is in its current state.
Ruby/Rails certainly has its quirks, and while Rails certainly does seem to be taking on more and more unnecessary dependencies, some are still plenty productive in day-to-day Rails. A lot of pain avoidance in Rails is following its opinions up-and-until it takes you further than you need to go
I perfer static typed languages now (not only because of Grails and Groovy). And I prefer to compose some specialized frameworks. For example JAX-RS (Jersey) is a very good REST framework. There is no need to force the user to use it with a certain ORM (if at all), a certain way to validate objects and so on. Just take what fit's best. Java is not the most elegant or productive language but there are other static typed JVM languages like Kotlin or Scala.
To come back to the article: I don't think that we need new languages, but another way to use existing frameworks and maybe statically typed languages.
I don't think any of that is going to change by switching to the next fashionable concept to base a web app on.
It would seem to me that Rails is just not the tool to use going forward for writing APIs for websites at scale. There are much better tools out there.
Rails' sweet spot is server side rendered pages that are quick to bring up and to add features. It seems great for certain types of websites so it does have its niche.
But moving forward, Rails for API vs. other frameworks in other languages is really a wash in terms of productivity, while other frameworks in those other languages are much more highly performant.
That might all matter if the first thing people did once deploying it was to port off of it. For software that has such a rapid expiration date, none of it selling points matter. You might as well have written it in php or perl.
Rails continues to be a favorite joke of mine.
The last place I worked had 80% of their products running Rails 2 and 20% of them running on Rails 3. No product was ever both completed AND caught traction since.
Do you stick with Rails 5 for the next project? Do you meander over to Python or Node?
"The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple."
First, I found Rails simple and easy, but it has become more complex over time as it has grown to support a variety of uses. The simplicity is not just because of Ruby, which is a low ceremony language, but rather because of the simple structure of the application, with a clear separation of concerns, very easy to find where a particular code item went.
"The meta-programming and object injection that 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. "
Dependency oriented development is a real problem, but it is insane to blame that on Ruby. I was working with an enterprise Java team last year that had over 1000 .jars in their build. It doesn't necessarily make it hard to debug, but it does mean you have understand a wide variety of different libraries. People are willing to load a library for the simplest of functions (as the leftpad npm case showed). Again, nothing to do with Rails or Ruby in particular.
"The magic of active record, the crazy levels of duck typing and the expressiveness of ruby, are exactly why it runs poorly even on your development box." This is highly dubious- it's very fast on my dev box. The Ruby interpreter keeps getting better, even taking lessons from V8, and you can compile to JRuby if you think that interpreted runtimes aren't ever going to keep up.
"It’s why you have to build a caching strategy in as a requirement from first line of code." This seems like a good strategy regardless, and caching is nicely handled in Rails.
"Competitors to Rails seemed subject to the same problem — basing themselves on interpreted, slow languages that favoured ‘easy to learn’ over ‘easy to maintain’." As opposed to compiled, fast languages like C++ that are hard to learn and hard to maintain? If anything, duck typing makes maintenance lot easier in some cases, where you can add in new types which support existing behavior, without making changes throughout the dependency tree. Even some 8 year old Rails apps we have are quite maintainable. JavaScript code does have a tendency towards messiness, as there are such a variety of schemes for organizing code, but it keeps getting better.
"I should be spending time writing code, not debugging a haystack of mutable, dependency-wired mess." This is your choice! I think it's nice to have toolsets that give people the ability to assemble things quickly, but no one is forcing you to use a gem to do something.
"Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself?" This seems like barking up the wrong tree. The thing making web development complex is largely the complexity of the front end. You can turn your back-end application into a separate API and isolate this problem. At some point, these become browser capabilities, and the polyfill approach has promise. (http://bitworking.org/news/2014/05/zero_framework_manifesto)
In reality none of the stuff mentioned in this article is really a shortcoming of Rails as compared to anything else. The biggest change is the move away from the basic nature of REST-ful, URL driven applications. Single page apps are a lot more like desktop applications. Many applications are looking for web sockets. These changes to the basic structure of what a web application is are much more of a challenge to Rails than the Ruby language itself.
Exceptions: I won't POST to a chat, even if there is nothing so wrong with that. Rationale: I'm already using that websocket for receiving messages, but only the messages for that chat.
I learnt then - avoid any web framework which has pragprog pushing a book behind it. The new one to avoid because the masses are already circling around it is 'phoenix', and sure enough, pragprog is hawking a book on it.
What framework is sufficiently irrelevant that Pragmatic Press or O'Reilly can't be bothered to write a book about it?
The pragprog web books seem to be a bell weather, the shiny web crowd flowed into Rails, node and soon probably phoenix. The early start and promise and phoenix will soon sink under the weight once hex packages bloat in number like the festering turds within ruby gems.
You sound out of your mind. Please try and make a rational argument.