Why I wouldn’t use Rails for a new company
blog.jaredfriedman.com
blog.jaredfriedman.com
And agreed that the Rails 2 to 3 jump was (and still is for many codebases) a tricky and difficult path.
However, I'd argue that doing your 'startup' in [Rails/COBOL/PHP/Logo/Java] is probably a decent idea if you have good engineers who can build something stable relatively quickly. Technology is _rarely_ the problem in any given startup.
If scalability and speed is a problem, congratulations, you're a success.
Rails is still good at giving you the tools to build decent CRUD-ish apps pretty fast and deployment is thankfully a solved problem.
Rails is not the new hotness, but it's still great at getting prototypes out the door and can scale you a long way. I think I'm cool with that.
> our front end has gone from Prototype to jQuery to Coffeescript to Angular to React with major productivity improvements each time
Also rewriting your front-end four times doesn't seem that productive.
I can not emphasize this enough. A lot of solutions are absolutely good enough for a startup's needs. You obviously don't want something completely throw away, but too much concern over tools & performance is kind of like a premature optimization for your whole business.
But this is definitely a case of the perfect being the enemy of the good.
I'm not arguing; just curious.
Some may argue that tests can theoretically cover all these bases. I would counter that in practice, tests almost never come close to serving as a poor man's compiler.
And of course, not even a dev who is experienced with the codebase could replace a true compiler, but I'd assume that this is deliberate trade-off, if there were competent technical decision-makers involved
I'd also have plenty of times that I referenced a variable and forgot to create the assignment. In a static language I'd get a compile error, but in Python I'd get everything all set up to test and then get a run-time error indicating I did something stupid. Never ceased to frustrate me.
I wrote some code a few days ago that looked like it worked. A few days later I ran the dialyzer, and it pointed out a certain code path could never be reached, because there was a comparison of an atom to an integer.
I would never have recognised that bug otherwise, because even my unit test just called that function with an integer, instead of the atom it was being called with.
Dynamic typing runs deep in what PHP/Ruby/Python offer - build it and get it running fast. Not thinking about complex types is a good thing in small projects.
But at a codebase of a certain size, static typing really helps minimise subtle bugs.
So very, very true. You could keep a front-end developer employed for years just rewriting the same application in the latest JS tech.
Ugh, I so disagree with that statement and this whole post. The company culture should be one that promotes using any technology, as long as it solves the problem. You should be hiring engineers who are comfortable picking up any language/framework, not fanboys who can only develop in X or Y.
As a start-up, you should be trying to iterate as fast as you can, not future-proofing your application. Chances are, your application will get a complete re-write once you've got enough engineers, or you're just a badass from the get-go and the code is solid all around regardless of what language or framework you used.
I can't stress this enough, but like it or not Rails (and Django) are some of the most feature complete frameworks out there. Particularly because of the ecosystem they've created and the community that supports them.
As far as remarks about Ruby or language X being slow. It really doesn't matter. The primary cause for slow applications is poor architecture and shitty code, not the speed of the language. People building one massive piece of shit monolithic application because they didn't bother to learn about microservices. Not to mention the amount of engineers who haven't gotten a clue about how to scale an application. With some proper HTTP caching and nginx to help you bypass the entire application layer, you can speed up your application by orders of magnitude.
The comment about Django being a Rails clone... wow, just wow. Although they share the Active Record design pattern for the ORM, they are vastly different.
This post makes my blood boil, because it's about language flame wars and fanboys.
So you end up being forced to optimize earlier, and the process of optimizing a single small component is generally simpler (you can profile just that process, for instance).
That said, there's nothing keeping you from gaining many of the same benefits from a well-disciplined, modular monolith, and I think there's a pretty high risk of a fast-moving and over-stressed team (like a lot of startups) being put under more stress by the time and complexity costs of microservices, and thus making much worse decisions than they would on a monolith.
In practice, I see service architecture as a way of making people think harder about how different parts relate to each other.
Personally, it would take a lot for me to switch a part of my monolith to a microservice and lose the speed of having everything done in the same process and the guarantees that having a single relational database offers. Having to reconcile data that got off sync because it was in two different data stores is not fun for anyone, and, to me, it's not worth it just to force yourself to not call any private methods on the other service. I just expose a public ABI and say "to interact with this part of the application, you may only call these functions here".
If you have a web application that handles most of the traffic on your site, and you have some management task/process that hogs resources in the same application, you're affecting your end users by running those processes on the same service.
The idea of microservices is to separate components so one does not affect the other, and you can scale individual components easily.
Say you have services X, Y, and Z. Service Z handles a lot of traffic and is becoming a bottleneck to the whole system. You spin up 2-3 more instances, throw a load balancer in front of them, and increase throughput, all without ever touching the rest of the system. Pretty seamless!
In addition, monolithic systems tend to be a pain in the ass for release cycles.
Microservices allow you to very easily bring components up and down and do zero down time deploys by using a load balancer.
Using our previous example, consider doing a release 2.0 for service Y. You spin up an additional instance of service Y with version 2.0 and the old instance is running version 1.0.
You take the old instance out of the load balancer and stick the new one in. With the flip of a switch, your end user ends up using version 2.0 of service Y, without ever having to bring the system down.
Now obviously microservices aren't the right design decision for every application. But as your system grows and uses different components, it's usually best to separate them out as individual services so that you can scale horizontally using load balancers.
I advocate the exact opposite view: use what enables your team to be most productive right now. The popularity of frameworks may change three years down the line, and good engineers will be fine with that.
The whole ecosystem is frankly a mess, you need to stay bleeding edge all the time to have a chance to long term maintenance and suffer any capricious api update each of your dependency might have because staying on old release and relying on backports is not worth it.
I'm not paid to clean other people libraries. If the idea of open source is that, then no thanks. Core business is not maintenance and costs like those do kill startups.
Spoiler: the difference is, the new ones' bugs just aren't widely known yet.
yeah, github is a perfect example or that, right? </irony>
If you want to run on old software that you don't have to upgrade or maintain, you are going to pay for someone else to do it.
If you want your cake and to eat it too, you're unrealistic.
"Yeah, we're going to be another 2 months to launch because we're betting developers in 2018 prefer Go."
I'll be pretty surprised if you're still in business in three years.
It's important to note that Express, the most popular Node framework, is a clone of Ruby's Sinatra, not of Rails. That's a great back-end when your front-end is iOS or React and you have a relatively simple data model. But it's not as strong a solution if you need to do server-rendered pages (which we need to support IE8). The bigger issue is that Rails is just a much more mature and full-featured framework than Express or Sails.js (which is designed to be Rails for Node). From migrations to validations to strong parameters to many other areas, Rails just offers a ton of back-end functionality that is not as mature on Node frameworks. The big question is how much back-end business logic needs to be implemented.
I haven't run into any issues with Ruby's server performance. AWS instances are easy to spin up, and any Ruby compute time is almost certainly going to be overwhelmed by network and database access. The performance we're focused on is developer productivity, and I think Ruby retains an advantage there over Javascript (though obviously we use both). If I were trying to support millions of simultaneous web socket connections, I would almost certainly go with Node (or maybe Go), but I remain a huge fan of the Rails platform.
You can see how rails is losing mindshare to newer frameworks.
I don't really think this proves anything. People who are already familiar with something aren't going to perform a vanilla Google search for it. For example, if I'm looking for a car, I'm not likely to perform a search for "automobile" but after overhearing somebody mention something called a Model S I might search for that.
A quick anecdote- I first learned about RoR circa 2008 from a colleague and performed a Google search for "Ruby on Rails" to find out what he was talking about. Fast forward three years and I was writing several web applications in it and don't recall ever performing that search again.
A far better metric I believe would be to perform an analysis of Stack Overflow questions by language and see whether it coincides with the chart the author cites.
I'm not entirely joking. I do the same thing you do (using ActiveRecord), but the way I got there was 1) searching "rails", 2) throwing in a term like ActiveRecord to avoid unrelated results, and final 3) realizing that "rails" was no longer necessary for the search.
Django was initially released in July 2005 (https://en.wikipedia.org/wiki/Django_(web_framework)).
Rails was initially released in December 2005 (https://en.wikipedia.org/wiki/Ruby_on_Rails).
Just a minor quibble. They basically grew in parallel and implemented similar feature sets, but the timing hardly allows for cloning.
Django does its own thing, and while it has borrowed ideas, it is an entirely different beast.
CakePHP was released before both of them, in 2005 too.
When I had to chose one over the other, I ended up using Django simply because diagnosing issues was simpler. Rails required a pretty substantial amount of a-priory knowledge to get things started (think, naming a file or method a certain way for it to magically be available somewhere else.) Django was more straightforward and allowed you to write code that, while not 100% django-esque, would work. I remember doing a lot of refactoring whenever I'd figure out a new framework idiom that I had missed earlier, but hey... I had working code before I needed to learn the idiom.
But your general point stands, Rails and Django grew up together and cribbed from each other liberally. The biggest example would perhaps be the merging of Merb into Rails 3, where Merb was a competing Ruby framework that had a much more Django-like vibe. These fanboy arguments don't hold much weight these days. They each do their own thing, they each borrow the best from each other, and everyone benefits.
Although Rails is stagnating as far as I know the library ecosystem is superior to that of others. Sure, there are more npm packages than gems. But I bet that the total complexity that Rails gems tackle is higher than what is available for Meteor. GitLab has close to 1000 non-unique dependencies https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.... I don't think that anything in the javascript world compares. But please show me I'm wrong, I love to learn.
I think that in a few years the situation might be different. Personally I hope that Elixir and Phoenix will replace Ruby and Rails. But maybe it will be Meteor or another js framework (Sails?). But I would optimize for the next few years and build my next startup on Rails. As indicated by the OP, a rewrite can happen even when you bet on javascript.
Like no other language has async capabilities and implement it 10 times better cought Go, C# (and probably many others that I don't know)...
But by all means correct me if I'm wrong.
1 - This decisions seems based more on the fact that Rails isn't as trendy as it used to be
2 - Some of these benchmarks for performance are pitting interpreted languages against compiled languages which will explain some of the performance difference
3 - Saying that Rails is static makes me think that the author would prefer a NodeJS like situation where every release might contain backwards-incompatible changes
4 - You don't future proof your application by trying to predict what will be popular in the future, you future proof by investing in stable technology and ensuring you have the talent pool to maintain it
These really popular frameworks are "mostly static" because they have been out for years, battle-tested in production and improved for years.
I guess every profession has their own version of this (someone flipping burgers probably has their special way of cooking it just so on every side). In the end, regardless of the way you do it, it gets the job done.
A lot of what Rails does, and even the little things, like naming conventions in ActiveRecord, intuitively make sense to me. If RoR ever does expire because another language/framework displaces it (maybe Elixir/Phoenix?) or because of poor/no support from a big company, I wouldn't look at it as a waste of time. Overall, I'm seeing a tried-and-true method of creating web applications and I'm enjoying it so far.
RoR can still get you where you need to go and fast, which is what you need when starting out. And if you ever find yourself in the same situation as Twitter, then you can make the switch...or better yet, improve on Ruby and give back to the Ruby community.
Rails can feel somewhat bloated, but it has a lot of functionality out of the box done transparently: generators, ORM and migrations, xss protection, templating, assets compilation, testing, configuration and naming conventions.
It's been a huge shock to me to see that a more modern framework on a more modern platform, express.js on node.js, has such a tiny subset of features we had in rails like 8 years ago. Granted, it's more like sinatra rather than rails, but nonetheless disappointing — what do all these people find in express that they couldn't have before.
If I wanted something with a high throughput of simple requests (like a chat server) or realtime responses using websockets, I'd typically go with a Node.JS inspired framework like Express.
But as this thread states, developer productivity can't be overstated, if the shipped code does what is needed.
Spot on. Biggest reason why I don't think Ruby/Python will grow bigger than what they are today is this. Meanwhile NodeJS/JavaScript is adopted by _many_ companies: IBM, SAP, Google, Joyent, Microsoft, etc. Ruby had some momentum before but none of the big guys extend their support as far as NodeJS/JavaScript.
Having said that, I'd probably use Java for a new company , why not?
Some people say "bulb" I'd say "matured"
Some people say "verbose" I'd say "explicit than implicit" (or code is written once to be read multiple times)
Some people say "bloated framework" I'd say "stable and backward compatible without sacrificing speed and flexibility" or "does not have to reinvent my memory mental model" (compare to different JS API programming style).
Some think Maven "sucks/bloated" but I'd think nothing can touch it for the most part...(plus Maven's idea is copied everywhere else..)
To each of his/her own I suppose.
PS: I use JavaScript 100% to build 2 enterprise products as my day job
> Spot on. Biggest reason why I don't think Ruby/Python will grow bigger than what they are today is this.
While no major corporate sponsors may be the case for Ruby, its not for Python:
None of these companies decided one day to write the Spring Framework for Python (or the Rails). We got Django that seems stuck in 2005-2009... (no offense to Django devs).
Python runtime hasn't changed much...
Meanwhile in NodeJS land: - GoDaddy decided to re-write stuff using NodeJS - eBay adopting NodeJS in increasing pace - Progress (.com), legacy software company acquired modulus.io (NodeJS shop) - IBM z Systems supports NodeJS - Go to Microsoft Learning, you'll find lots of JavaScript tutorials (NodeJS or WinJS or Angular)
These companies promote NodeJS up-front. When Microsoft decided to hire people behind IronRuby and IronPython, I thought they decided to adopt those languages but that didn't last long before they cut them loose...
And also quite a bit of Python, including general language courses, Django, Python/Flask/SQL, Python w/MongoDB, etc.
> When Microsoft decided to hire people behind IronRuby and IronPython, I thought they decided to adopt those languages but that didn't last long before they cut them loose...
Microsoft is still a significant backer of Python, not just a PSF sponsor, but also directly employing Python core devs, and doing a lot of direct support for Python. [0]
IronPython and IronRuby weren't Microsoft adopting the Ruby and Python languaegs, they were efforts to alternatives to the core implementations of those languages tied to the .NET platform.
[0] See, e.g., http://pycon.blogspot.com/2015/03/for-microsoft-python-suppo...
That's also an argument against verbose. Verbosity hurts on each re-reading. (As does improper terseness.)
Python has quite a bit of backing, including by every company you listed as backing JavaScript. Admittedly, it's for different reasons, but the support is there. Ruby, well, yeah, that's a totally volunteer job.
On the other hand, I think [Phoenix](http://www.phoenixframework.org/) could be the next big web thing. Not b/c it is super fast (although still faster than Rails) but b/c it is super stable and easily distributed.
The big advantage of Node.js (and thus Sails) is, of course, that the front end and back end can be written in the same language (ie. less to learn), but that might change in a few years with [WebAssembly](https://medium.com/javascript-scene/what-is-webassembly-the-...).
If that is the case, why do so many people insist on comparing a framework, such as rails to node.js? Wouldn't the more relvant comparison be node.js vs ruby, or rails vs meteor.
So many people make such comparisons I feel like I'm the one who is crazy. Of course, I probably am, but that may have nothing to do with rails and node.js comparisons. :-)
After battling Rails' conventions and getting a bit sick of learning a lot of things that are only useful in the Rails world, I figured it might be nice to do everything almost from scratch (Express.js as a shortcut though). I'm using RethinkDB without an ORM, although over time I suspect my approach will become more ORM-like over time and I might just switch to one of the existing RethinkDB ORM's.
It's loads of fun being able to understand most steps of the process of building a complete website that includes authentication, a database, a CMS, and whatnot, especially after relying on Rails' magic for a lot of things. I guess I just really prefer the explicitness of it all.
That said, if money and/or time were an issue, or if the end product would have to be worked on by other developers, I'd probably go for RoR or Django. The amount of stuff it 'just' takes care of is much more than one might assume at first, and the amount of pitfalls in the category 'not knowing what you don't know' are not insignificant (XSS, for example).
Rake is a raw server, giving the minimum to do something. Ruby on Rails is a full stack framework giving a complete solution for both: the front-end (template, asset pipeline...) and the back-end (API, routes, ORM, security...).
As much as we hate to admit it, a significant part about what attracts us to a language is the quality of people who use it. While Ruby has nicer things about it than Java did in 2004, the people adopting Ruby in the early to mid 2000s didn't just dislike Java, they liked the like-minded individuals who seek out tools to make their lives better.
That's a pretty good reason if your selection method is substantially equivalent to choosing "X programmers" (for whatever X is your technology base) at random.
But, beyond that, I don't see that it matters.
You're conflating "learning to program" with "using a specific programming language."
Rails was and is the most productive web development framework and that's why I use it. I don't even know who's in rails community.
Looking at trends is almost useless, from your example Nodejs can't be above Java for Jobs searching.
"if you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. " really? I'm not expert but the tech is a tool to create a product not the way around.
Meaning they probably also lack experience to make decisions that avoid turning greenfields into a muddy hell. No thanks.
i do not use rails but it probably is the cheapest alternative (from an engineering perspective) right now given the number of available engineers + ecosystem
This thread inspired me. I am giving up JavaScript completely and am writing a browser in Fortran that only allows Fortran servers and Fortran in the browser. I mean, everything else is new and trendy. Fortran or gtfo newbies!
Good libraries cover a multitude of language feature sins.
http://www.paulgraham.com/avg.html
I couldn't be happier with Clojure and I don't really know what else I could want.
The thing is your secret weapon should not be too secret. Languages and platforms are useless without a community around them. In fact clojure's community seems to be a pretty vibrant one.
Node.js isn't a framework. What about comparing apples with apples?
Anyway, I think that the main change that's going on right now is that lots of web apps have a higher and higher percentage of the code written for the front end (web and mobile) rather than the back end.
Rails still has much higher productivity and tooling for back-end development than the Node.js frameworks I've seen for now, but that could become irrelevant for many startups in the medium term, just because a lot of the added value for them will come from the front end rather than the back end.
What would you call it? Because it's not a language either. JavaScript is the language.
That and nodejs.org calls it a runtime built on V8 :P
What this misses is Rails was the first framework that really got the web. It's not that Rails had new ideas, but that it took existing ideas and packaged them nicely for the web. Before that, you could either just wing it rolling your own in PHP or Perl, or else use Java because you were a "serious software engineer" that cared about well-defined architectures. The reason Rails was able to eat their lunch is by marrying just-enough-structure with the on the ground reality of developing web apps. Java frameworks just never got this until they saw how much people actually loved Rails and that in fact you could get more done with less.
So all these complaints about Rails stagnating are overblown—Rails still gets the web, or at least I should say it still gets server-side web. It's not innovating the way it used to, because it is mature for it's use case. That doesn't mean it's not well maintained.
The thing that will make Rails a bad choice is the thing that makes server-side web rendering is a bad choice. Obviously there are huge use-cases for single-page apps where Node really shines. There are also cases for microservices where Go really shines. Rails is not all things to all people, and it is no longer the new hotness, however it's core use cases aren't going away any time soon.
I believe Rails is still a great option in case you want to use an existing team and where strong performance is not a requirement. Learning Rails is currently a very minor bump in the road, since (1) the language is easy to pick up, and (2) the framework is well documented (every possible question is on stack-ex it seems).
For now I'd look in the direction of Go, Erlang/Elixir, Clojure and Haskell as the new contenders for doing web development. They all have their own strong points, and I personally resonate most with Haskell (strong typed, manageable maintenance curve a.k.a. happy refactoring, fast enough).
So why not Node? It's because of JS. The language is the biggest "API" you will ever write against. Moving away from it is called either a rewrite or a port. So making a choice for a language should be made carefully. And design choices when making a language should be made carefully. In case of JS the design was clearly haphazardly done: and this will leak into any code written on top of it.
Wonder if something similar will catch on in the node ecosystem?
Whether or not this is a good thing or not, I'm undecided.
source: http://www.sitepoint.com/simplifying-asynchronous-coding-es7...
That said, the thrust of this article is that you should make your technical decisions based on the absolute most trending thing at the moment, and I think that's bogus. Plain old syncronous programming has its place.
Node 4.x is awesome (relative to Node 0.12)
I don't think we can draw any conclusion about node pulling away.
Django is SOLID, and if we went by say, dice.com data, it's about 50% as popular making it a still safe choice. Around here (RTP, NC) it feels about as popular as rails - but that's just a feeling. I think you probably have to add Flask+SQLAlchemy to that, but it's a bit less common regionally.
Either are definitely still a solid choice for rapid application development.
Now, for whatever it means, when I've talked to IT shops, it's not uncommon for a rails shop to be running at 500 nodes when an equivalent Java shop has 10 nodes -- it may be because those shops have bad developers, but there may be something a bit true about inefficiency somewhere - or it may just be those rails developers aren't as plugged in to things like CDNs and memcache.
I definitely do agree that Ruby's lack of corporate support hurt it quite a bit. Ruby didn't have a large company pumping money and time into furthering it. I think a lot of that is due to the core team almost entirely being Japanese, and mostly independent of the western web development world.
New York: https://jobs.groupon.com/careers/engineering/ruby-software-e...
Seattle: https://jobs.groupon.com/careers/engineering/senior-software...
1. Use the platform which is gaining mindshare because some years down the road you will be hiring engineers and you will want to look hip not obsolete.
2. Use the platform with solid corporate backing so that someone will support it and help it mature.
Seems very reasonable to me. Smaller companies need some strong selling points to compete with the larger firms on the hiring market and hip technology can be one of them. But the hip technology needs to actually work so better have someone with lots of resources backing it.
A "faster" language only gives a linear improvement in performance. It's only worth it if a 5-10x increase in hardware cost crosses the line between profit and failure. If it doesn't, I'll choose the tools that get the job done with half the team size and lets them get home early every time.
I pretty much tuned out when I saw the his first argument was popularity. Skimmed down to see his window is three years.
Good grief.
That said, of course rails is viable for a new company. But the reality is, rails isn't the quantum leap of productivity over other options like it was 10 years ago.
If everyone thinks like that we'll only see more faddish frameworks come and go. Why not make a bet on what framework will continue to provide the most productivity in three years? Or stability, maintainability, etc.? If it's a mere popularity contest then it's winner takes all and we'll all be writing javascript in the near future.
So many things wrong here…where to start?
Indeed trends: you’re looking at relative growth but don’t show overall numbers. Here, let me help you with that: http://www.indeed.com/jobtrends?q=rails%2C+node.js&l=
Not only is Rails still more popular than node.js, it has a similar bump in recent results. And that brings me to my next point: Indeed trends are practically useless because they’re measuring word frequency rather than actual demand. For example, apparently “garbage” is as frequently (or more frequently) mentioned in job postings as “node.js”: http://www.indeed.com/jobtrends?q=rails%2C+node.js&l= . I guess that means node.js is garbage.
Google searches: search numbers generally indicate new interest in a subject rather than overall usage. For example, “Trump” is one of the biggest search terms right now, even though he doesn’t have a snowball’s chance in hell of becoming POTUS.
Performance numbers: I can’t comment on this since you don’t provide any information on what’s being tested or methodology. You might as well be graphing total numbers of watermelon eaters for each language. And this doesn’t even consider JRuby, which is faster at steady-state Rails requests than CRuby on the same isrubyfastyet.com you attempt to use in a comment to claim it’s slower. Huh??
Rails is static: This is absurd on the face of it…Rails has been one of the fastest moving frameworks, and most people in the know often wonder if it moves too fast. You’re completely out of touch here.
And speaking of out of touch, you call JRuby “floundering” and “abandoned” when we’ve had dozens of consistent releases over the past year. Wow. Are there any actual facts in this article?
Bootcamps: Are you saying that people shouldn’t use a language or framework that’s good for new developers to use? Really? If that’s the case, perhaps we should all be writing webapps in C++. We don’t want any new developers to join us, that’s for sure!
Honestly, you need to get your facts straight before writing something like this. It’s like a parody article.
I believe the success behind rails and ruby ecosystems is due to the rails "monopoly" - it got so many things right along the way, from embracing REST, to migrations, generators, TDD, to the asset pipeline, turbolinks, supporting PG's hstore and jsonb and so on...
And even if you decide not to build the frontend part of you application with Rails, it is still a powerful tool for building an API. After a few experiments trying to embrace a more domain oriented approach (largely thanks to Bob Martin's talk 'Architecture, the lost years'), I am both productive and comfortable writing complex business logic in plain ruby and attaching it to Rails.
And finally there is testing. When I need to move from RSpec's powerful BDD capabilities to py.test (our ML algorithms are written in Python) I see how much more productive (and confident) I am writing Ruby code.
The article indicates that the next big thing in server-side development is Javascript, but hasn't it been for the last 5 years?
First express, then the whole MVC moved over to javascript with backbone, angular, ember and meteor - but you still needed a server side API so at least the models and controllers were written twice (I still see the marshalling data in JSON as a "V"), and then came Angular V2 and before you even got the chance to play with it, you were using a "useless" framework. And then came React (which, btw is just the V, despite being (wrongly) promoted as an Angular alternative), but it doesn't quite specify how to connect with the data itself so then there is Flux, and JSX and Babel, Typescript, ES6. And, let's not forget the tooling behind everything javascript: node, iojs, requirejs, webpack, npm, bower (why are some packages available on both places btw?), grunt, gulp. And the cherry on the cake: no more REST, the next big thing is GraphQL.
I exaggerated on purpose, but as a software engineer who is not strictly focused on web development I appreciate being blindly guided by the decisions made by the Rails community.
It feels there is so much more serious/strong "competitors" for the next server-side Language/Framework duo now, than there was 8 years ago (Go, Javascript, Java8, Python 3, Haskell, Clojure, etc) - and from what I am able to keep up with, if I had to move, I'd go to Elixir/Phoenix, exactly because it seems to be fixing ruby's major issues while keeping rails' excellent choices.
But this moment hasn't arrived yet. What I'm looking for, before betting on the next big thing, is success, and as a @andycroll said: "If scalability and speed is a problem, congratulations, you're a success."
In my book, this "jackass filter" is a feature, not a bug.
---
WRT performance, the actual performance in benchmarks of the language is, for the most part, thoroughly irrelevant in most web applications. You're going to be spending most of your time waiting on I/O and network calls. Making real-world applications fast consists mostly of in-memory caching, not blocking on I/O, and doing things in parallel. That Node was designed primarily around nonblocking I/O has far more bearing on real-world performance than any JS vs. Ruby benchmark.
I don't love Ruby, but Rails removes a dozen time-consuming decisions from the space between "starting an app" and "shipping an app" and leaves you building on a stack that is in use by a relatively large number of developers, which means that somebody has probably run into framework bugs before you did. And I've yet to see anything mount a serious challenge. Which is a shame, b/c I don't love Ruby, I don't love Rails, but that it's mature enough that most of the design WTFs have disappeared by now makes it hard to choose something else.
It's amazing what it's turned into. That said it's still very painful and the ecosystem has a very long way to go in terms of build tools, etc etc.
I bet there's a lot of money to be made in being able to turn old legacy php codebases into nice well factored systems in the next few years.