Why I wouldn’t use Rails for a new company

I can definitely accept that Rails is now somewhat old hat.<p>And agreed that the Rails 2 to 3 jump was (and still is for many codebases) a tricky and difficult path.<p>However, I&#x27;d argue that doing your &#x27;startup&#x27; in [Rails&#x2F;COBOL&#x2F;PHP&#x2F;Logo&#x2F;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.<p>If scalability and speed is a problem, congratulations, you&#x27;re a success.<p>Rails is still good at giving you the tools to build decent CRUD-ish apps pretty fast and deployment is thankfully a solved problem.<p>Rails is not the new hotness, but it&#x27;s still great at getting prototypes out the door and can scale you a long way. I think I&#x27;m cool with that.<p>&gt; our front end has gone from Prototype to jQuery to Coffeescript to Angular to React with major productivity improvements each time<p>Also rewriting your front-end four times doesn&#x27;t seem that productive.

&quot;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. That’s more important than what framework lets you be most productive right now. If you’re Facebook, you can get away with using anything and people will still want to work for you, but most companies are not Facebook.&quot;<p>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&#x2F;framework, not fanboys who can only develop in X or Y.<p>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&#x27;ve got enough engineers, or you&#x27;re just a badass from the get-go and the code is solid all around regardless of what language or framework you used.<p>I can&#x27;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&#x27;ve created and the community that supports them.<p>As far as remarks about Ruby or language X being slow. It really doesn&#x27;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&#x27;t bother to learn about microservices. Not to mention the amount of engineers who haven&#x27;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.<p>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.<p>This post makes my blood boil, because it&#x27;s about language flame wars and fanboys.

&gt; you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now.<p>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.

I chose to use Node&#x2F;Express at my last startup and Ruby on Rails at my current one. Both are great platforms with fantastic communities behind them. For example, there is an amazing amount of Stack Overflow answers and folks watching for new questions.<p>It&#x27;s important to note that Express, the most popular Node framework, is a clone of Ruby&#x27;s Sinatra, not of Rails. That&#x27;s a great back-end when your front-end is iOS or React and you have a relatively simple data model. But it&#x27;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.<p>I haven&#x27;t run into any issues with Ruby&#x27;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&#x27;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.

The author cites a graph of declining Google searches for &quot;Ruby on Rails&quot; relative to &quot;Node.js&quot; and then follows up with the statement:<p><i>You can see how rails is losing mindshare to newer frameworks.</i><p>I don&#x27;t really think this proves anything. People who are already familiar with something aren&#x27;t going to perform a vanilla Google search for it. For example, if I&#x27;m looking for a car, I&#x27;m not likely to perform a search for &quot;automobile&quot; but after overhearing somebody mention something called a Model S I might search for that.<p>A quick anecdote- I first learned about RoR circa 2008 from a colleague and performed a Google search for &quot;Ruby on Rails&quot; to find out what he was talking about. Fast forward three years and I was writing several web applications in it and don&#x27;t recall ever performing that search again.<p>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.

&gt; Django for Python is largely a rails clone<p>Django was initially released in July 2005 (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Django_(web_framework)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Django_(web_framework)</a>).<p>Rails was initially released in December 2005 (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ruby_on_Rails" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ruby_on_Rails</a>).<p>Just a minor quibble. They basically grew in parallel and implemented similar feature sets, but the timing hardly allows for cloning.

I agree ruby is slow and it lost the race with javascript. And the lack of a corporate sponsor has a lot to do with this. At GitLab the company we think that having a company behind an open source project is a plus (although the OP was talking about a user such as Twitter instead of Ruby Inc.). We hope to do our part in helping ruby become faster, our new hire Yorick will spend 20% of his time on Rubinius <a href="http:&#x2F;&#x2F;yorickpeterse.com&#x2F;articles&#x2F;hello-gitlab&#x2F;" rel="nofollow">http:&#x2F;&#x2F;yorickpeterse.com&#x2F;articles&#x2F;hello-gitlab&#x2F;</a><p>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 <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;gitlab-org&#x2F;gitlab-ce&#x2F;blob&#x2F;master&#x2F;Gemfile.lock" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;gitlab-org&#x2F;gitlab-ce&#x2F;blob&#x2F;master&#x2F;Gemfile....</a> I don&#x27;t think that anything in the javascript world compares. But please show me I&#x27;m wrong, I love to learn.<p>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.

The point that Ruby is memory intensive vs other things like Nodejs and thus you are shooting yourself in the foot using it applies only to a very small subset of businesses, like Scribd, who require absolutely massive scale in order to be profitable. If your unit economics are different (and many are, substantially), Ruby is really not going to be the bottleneck in your scaling.

Couple of issues I have with this article<p>1 - This decisions seems based more on the fact that Rails isn&#x27;t as trendy as it used to be<p>2 - Some of these benchmarks for performance are pitting interpreted languages against compiled languages which will explain some of the performance difference<p>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<p>4 - You don&#x27;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

I&#x27;m learning Rails right now and this isn&#x27;t the first time I heard how slow RoR can be. Hell, there&#x27;s a whole site answering the &quot;Can rails scale?&quot; question (<a href="http:&#x2F;&#x2F;canrailsscale.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;canrailsscale.com&#x2F;</a>).<p>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&#x2F;framework displaces it (maybe Elixir&#x2F;Phoenix?) or because of poor&#x2F;no support from a big company, I wouldn&#x27;t look at it as a waste of time. Overall, I&#x27;m seeing a tried-and-true method of creating web applications and I&#x27;m enjoying it so far.<p>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.

&gt; Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.<p>Spot on. Biggest reason why I don&#x27;t think Ruby&#x2F;Python will grow bigger than what they are today is this. Meanwhile NodeJS&#x2F;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&#x2F;JavaScript.<p>Having said that, I&#x27;d probably use Java for a new company , why not?<p>Some people say &quot;bulb&quot; I&#x27;d say &quot;matured&quot;<p>Some people say &quot;verbose&quot; I&#x27;d say &quot;explicit than implicit&quot; (or code is written once to be read multiple times)<p>Some people say &quot;bloated framework&quot; I&#x27;d say &quot;stable and backward compatible without sacrificing speed and flexibility&quot; or &quot;does not have to reinvent my memory mental model&quot; (compare to different JS API programming style).<p>Some think Maven &quot;sucks&#x2F;bloated&quot; but I&#x27;d think nothing can touch it for the most part...(plus Maven&#x27;s idea is copied everywhere else..)<p>To each of his&#x2F;her own I suppose.<p>PS: I use JavaScript 100% to build 2 enterprise products as my day job

It will be interesting to see if [Crystal](<a href="http:&#x2F;&#x2F;crystal-lang.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;crystal-lang.org&#x2F;</a>) ever gets a port of Rails. Crystal currently has some serious limitations that I think would make it all but impossible to port (e.g. lambda support is weak), but perhaps those issues will be remedied. And if so, Crystal on Rails would be 4x to 20x faster than on Ruby.<p>On the other hand, I think [Phoenix](<a href="http:&#x2F;&#x2F;www.phoenixframework.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.phoenixframework.org&#x2F;</a>) could be the next big web thing. Not b&#x2F;c it is super fast (although still faster than Rails) but b&#x2F;c it is super stable and easily distributed.<p>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](<a href="https:&#x2F;&#x2F;medium.com&#x2F;javascript-scene&#x2F;what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;javascript-scene&#x2F;what-is-webassembly-the-...</a>).

Someone please correct me if I am wrong, but Node.JS is a server side javascript runtime environment, correct?<p>If that is the case, why do so many people insist on comparing a framework, such as rails to node.js? Wouldn&#x27;t the more relvant comparison be node.js vs ruby, or rails vs meteor.<p>So many people make such comparisons I feel like I&#x27;m the one who is crazy. Of course, I probably am, but that may have nothing to do with rails and node.js comparisons. :-)

The most compelling reason not to use Ruby for a new company or product in an existing company is that the talent of the average Ruby programmer has dropped drastically in recent years. Face it, Ruby is hitting that adoption stride where it&#x27;s attracting&#x2F;has attracted a lot of people who don&#x27;t care about the quality of code they write. JavaScript isn&#x27;t any better and is probably even worse in this regard.<p>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&#x27;t just dislike Java, they liked the like-minded individuals who seek out tools to make their lives better.

You should use whatever people you&#x27;re working with know and are comfortable with.<p>Looking at trends is almost useless, from your example Nodejs can&#x27;t be above Java for Jobs searching.<p>&quot;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. &quot; really? I&#x27;m not expert but the tech is a tool to create a product not the way around.

Using something just because it&#x27;s popular is absurd. You will be switching to next &quot;hip&quot; thing every project then?

I still think Beating the Averages is an incredibly relevant essay for language choice.<p><a href="http:&#x2F;&#x2F;www.paulgraham.com&#x2F;avg.html" rel="nofollow">http:&#x2F;&#x2F;www.paulgraham.com&#x2F;avg.html</a><p>I couldn&#x27;t be happier with Clojure and I don&#x27;t really know what else I could want.

&gt; A few frameworks are strong contenders to be the successor to rails. Node.js is in the lead.<p>Node.js isn&#x27;t a framework. What about comparing apples with apples?<p>Anyway, I think that the main change that&#x27;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.<p>Rails still has much higher productivity and tooling for back-end development than the Node.js frameworks I&#x27;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.

I think the graph of various languages by speed is rather misleading. Python is missing altogether, PHP is only represented by HHVM, which is faster than regular PHP but is not (so far as I know) a drop-in replacement for existing code bases written for the standard PHP stack... I guess I could quibble about the CLR languages being missing but they&#x27;re going to be in the vicinity of Java so it doesn&#x27;t really mislead about anything. But Python and stock PHP being missing is throwing out the languages most comparable to Ruby.

&gt; <i>I worry now that rails is past its zenith, and that starting a new company with rails today might be like starting a company using Java Spring in 2007.</i><p>What this misses is Rails was the first framework that really <i>got</i> the web. It&#x27;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 &quot;serious software engineer&quot; 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.<p>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&#x27;s not innovating the way it used to, because it is mature for it&#x27;s use case. That doesn&#x27;t mean it&#x27;s not well maintained.<p>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&#x27;s core use cases aren&#x27;t going away any time soon.

Article&#x27;s author seems very favorable of Node: which would be lower on my list the Rails as a server-side language.<p>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).<p>For now I&#x27;d look in the direction of Go, Erlang&#x2F;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).<p>So why not Node? It&#x27;s because of JS. The language is the biggest &quot;API&quot; 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.

So the new framework of choice now seems to be Node according to his graphs. I&#x27;m building in Node as we speak and I&#x27;m not loving the Promise pattern to solve callback hell. Will I get over it? Have others?

When he&#x27;s citing Node dominance, Javascript is mixed in there - and as we know, client side javascript is EVERYWHERE.<p>I don&#x27;t think we can draw any conclusion about node pulling away.<p>Django is SOLID, and if we went by say, dice.com data, it&#x27;s about 50% as popular making it a still safe choice. Around here (RTP, NC) it feels about as popular as rails - but that&#x27;s just a feeling. I think you probably have to add Flask+SQLAlchemy to that, but it&#x27;s a bit less common regionally.<p>Either are definitely still a solid choice for rapid application development.<p>Now, for whatever it means, when I&#x27;ve talked to IT shops, it&#x27;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&#x27;t as plugged in to things like CDNs and memcache.

I think the graph of framework searches doesn&#x27;t show what the author claims. First off, the Django line hasn&#x27;t moved much, and the node.js line <i>has</i>, but Django is pretty much concurrent with Rails, not one of the newer crop of frameworks. And secondly, while it shows a large drop for Rails searches, it doesn&#x27;t show anything else taking up that slack—so if Rails is being replaced (which is definitely possible) this graph doesn&#x27;t really indicate by what. Nose.js has increased, but not by as much as Rails dropped.<p>I definitely do agree that Ruby&#x27;s lack of corporate support hurt it quite a bit. Ruby didn&#x27;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.

Article might show a trend that rails jobs are declining, but that&#x27;s not true for my team. I&#x27;m looking to hire 12 ruby&#x2F;rails engineers between New York and Seattle offices.<p>New York: <a href="https:&#x2F;&#x2F;jobs.groupon.com&#x2F;careers&#x2F;engineering&#x2F;ruby-software-engineer-full-stack-glive-new-york-city-ny-united-states-10756&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jobs.groupon.com&#x2F;careers&#x2F;engineering&#x2F;ruby-software-e...</a><p>Seattle: <a href="https:&#x2F;&#x2F;jobs.groupon.com&#x2F;careers&#x2F;engineering&#x2F;senior-software-engineer-full-stack-glive-seattle-wa-united-states-10800&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jobs.groupon.com&#x2F;careers&#x2F;engineering&#x2F;senior-software...</a>

I think the technical aspects discussed in the article are there not to debate the relative merits of technologies but to support the main line of reasoning which is social in nature. It boils down to:<p>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.<p>2. Use the platform with solid corporate backing so that someone will support it and help it mature.<p>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.

Ruby is a super-readable language with a powerful syntax, and Rails (3+) used in Rails-like ways gives the user a similar amount of power over db and web delivery. Just because clarity of thought cannot be measured it doesn&#x27;t mean the tools that enable it are worthless, or worth less.<p>A &quot;faster&quot; language only gives a linear improvement in performance. It&#x27;s only worth it if a 5-10x increase in hardware cost crosses the line between profit and failure. If it doesn&#x27;t, I&#x27;ll choose the tools that get the job done with half the team size and lets them get home early every time.

One person&#x27;s &quot;old-hat dinosaur&quot; is another&#x27;s &quot;battle-hardened&quot;.<p>I pretty much tuned out when I saw the his first argument was popularity. Skimmed down to see his window is three years.<p>Good grief.

The only thing I&#x27;ll say in this thread is that many of these responses are extremely similar to the arguments people gave me when I chose RoR as the framework for my startup instead of java back in 2005.<p>That said, of course rails is viable for a new company. But the reality is, rails isn&#x27;t the quantum leap of productivity over other options like it was 10 years ago.

There are certainly reasons to eschew rails in a new startup, but &quot;nobody will be using it in three years&quot; isn&#x27;t one of them. At this stage in the game getting the app working is of paramount importance, and if you spend too much time plumbing for youtube volume you won&#x27;t survive three quarters, let alone three years.

The author seems to be comparing Node mindshare to Rails, but his Node framework of choice is Sails. It seems to me most production Node web apps are using Express or to a lesser extent Koa and Meteor. Is there some huge secret contingent of production Sails apps I don&#x27;t know about?

He&#x27;s comparing Google Searches of NodeJS (a language) to Google Searches for Rails (a framework). Technically speaking this is a huge flaw. Pragmatically speaking the author doesn&#x27;t critique the strengths or weaknesses of why Rails would be a weak choice. His opinions are weakly based solely on popularity. Rails and Django are incredible powerful tools given for a very particular job. Node is another beast entirely. It&#x27;s tooling and strengths are completely different because they both have different use cases.

&gt; 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.<p>If everyone thinks like that we&#x27;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&#x27;s a mere popularity contest then it&#x27;s winner takes all and we&#x27;ll all be writing javascript in the near future.

They have time to re-write front-end four times from jQuery to Coffeescript to Angular to React, but think backend needs to be &quot;future-proof&quot;ed for 3 years?

My comment on the article has not been accepted yet, so I&#x27;ll add it here...<p>So many things wrong here…where to start?<p>Indeed trends: you’re looking at relative growth but don’t show overall numbers. Here, let me help you with that: <a href="http:&#x2F;&#x2F;www.indeed.com&#x2F;jobtrends?q=rails%2C+node.js&amp;l=" rel="nofollow">http:&#x2F;&#x2F;www.indeed.com&#x2F;jobtrends?q=rails%2C+node.js&amp;l=</a><p>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”: <a href="http:&#x2F;&#x2F;www.indeed.com&#x2F;jobtrends?q=rails%2C+node.js&amp;l=" rel="nofollow">http:&#x2F;&#x2F;www.indeed.com&#x2F;jobtrends?q=rails%2C+node.js&amp;l=</a> . I guess that means node.js is garbage.<p>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.<p>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??<p>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.<p>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?<p>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!<p>Honestly, you need to get your facts straight before writing something like this. It’s like a parody article.

This is a great article. Unfortunately he&#x27;s dead on about all the Bootcamp&#x2F;Dev schools out there (and I attended one of the first). It has heavily diluted the market and Rails is almost the new HTML. I sensed this years ago and started moving into Go-lang and general DevOps technologies in order to stay in high demand (and it&#x27;s worked swimmingly).

I sometimes wonder about this very question from month to month and I always end up seeing Rails as a winner.<p>I believe the success behind rails and ruby ecosystems is due to the rails &quot;monopoly&quot; - it got so many things right along the way, from embracing REST, to migrations, generators, TDD, to the asset pipeline, turbolinks, supporting PG&#x27;s hstore and jsonb and so on...<p>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&#x27;s talk &#x27;Architecture, the lost years&#x27;), I am both productive and comfortable writing complex business logic in plain ruby and attaching it to Rails.<p>And finally there is testing. When I need to move from RSpec&#x27;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.<p>The article indicates that the next big thing in server-side development is Javascript, but hasn&#x27;t it been for the last 5 years?<p>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 &quot;V&quot;), and then came Angular V2 and before you even got the chance to play with it, you were using a &quot;useless&quot; framework. And then came React (which, btw is just the V, despite being (wrongly) promoted as an Angular alternative), but it doesn&#x27;t quite specify how to connect with the data itself so then there is Flux, and JSX and Babel, Typescript, ES6. And, let&#x27;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.<p>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.<p>It feels there is so much more serious&#x2F;strong &quot;competitors&quot; for the next server-side Language&#x2F;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&#x27;d go to Elixir&#x2F;Phoenix, exactly because it seems to be fixing ruby&#x27;s major issues while keeping rails&#x27; excellent choices.<p>But this moment hasn&#x27;t arrived yet. What I&#x27;m looking for, before betting on the next big thing, is success, and as a @andycroll said: &quot;If scalability and speed is a problem, congratulations, you&#x27;re a success.&quot;

Im betting on Elixir + Phoenix framework being the future, for many reasons. Mainly speed and concurrency while still maintaining the productivity of rails.

I think that should be titled &quot;why I wouldn&#x27;t use rails for a new company in Silicon Valley&quot;. Where I am in Houston Texas ruby is probably near 1% of the development jobs. .NET pretty much has a stranglehold on server side code and asp Mvc and node rule the front end. I really dislike this SV centric myopic view of the world.

&gt; Serious developers, particularly ones with CS degrees, look down on bootcamp programs as “programming light”. I’ve noticed a disturbing trend of experienced developers not wanting to work with rails now that it’s been “polluted” by this reputation.<p>In my book, this &quot;jackass filter&quot; is a feature, not a bug.<p>---<p>WRT performance, the actual performance in benchmarks of the language is, for the most part, thoroughly irrelevant in most web applications. You&#x27;re going to be spending most of your time waiting on I&#x2F;O and network calls. Making real-world applications fast consists mostly of in-memory caching, not blocking on I&#x2F;O, and doing things in parallel. That Node was designed primarily around nonblocking I&#x2F;O has far more bearing on real-world performance than any JS vs. Ruby benchmark.<p>I don&#x27;t love Ruby, but Rails removes a dozen time-consuming decisions from the space between &quot;starting an app&quot; and &quot;shipping an app&quot; 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&#x27;ve yet to see anything mount a serious challenge. Which is a shame, b&#x2F;c I don&#x27;t love Ruby, I don&#x27;t love Rails, but that it&#x27;s mature enough that most of the design WTFs have disappeared by now makes it hard to choose something else.

Despite all the naysayers I have kept with PHP and she&#x27;s matured into a fine lady who doesn&#x27;t let me down.