15 ms·

Why I wouldn’t use Rails for a new company

140 points by g4k 11y ago

romanovcode 11y ago
Using something just because it's popular is absurd. You will be switching to next "hip" thing every project then?
- olouv 11y ago
  One upside is clearly that it helps attract raw talent more easily with a hot/trendy stack, and to me, it's a more exciting adventure overall (more risky though).
  - jskulski 11y ago
    Talent that comes in because a stack is hot/trendy are there by virtue that they lack the experience to know it's nothing knew. They haven't seen other hot/trendy stacks fail yet. Meaning they probably also lack experience to make decisions that avoid turning greenfields into a muddy hell. No thanks.
    - Killswitch 11y ago
      I agree, lets not use hot and trendy, who needs any of that? Rails? TO TRENDY! Lets use Fortran and COBOL!
- misiti3780 11y ago
  it depends what you mean, but i probably disagree - popular frameworks have more stack overflow answers, better docs, more bug fixes, and bigger ecosystems in general 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
  - romanovcode 11y ago
    Not sure about the cheap aspect tho, in my area rails developers are one of most well paid.
    - misiti3780 11y ago
      fair enough - if you really want to save money - youd go with php
      - Killswitch 11y ago
        Worthwhile PHP developers are not cheap either. Unless you mean WordPress developers. (no, they're not PHP developers, they're WordPress developers. They only know WordPress)
- clivestaples 11y ago
  The article is about momentum not necessarily newness or hipness. Node.js is only three years younger than Rails.
  - Killswitch 11y ago
    shhhhhh, it's to new and trendy. 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!
    - prewett 11y ago
      I have a great name for your browser: "Retro"
  - djur 11y ago
    Node.js was first released in 2009, Rails in 2004 -- five years, not three.
- calebm 11y ago
  That's kind of like saying it's absurd to switch to a new social network because it is popular... as with social networks, languages/platforms are more useful when more people use and contribute to them. Good libraries cover a multitude of language feature sins.
- volaski 11y ago
  Apparently they did. They went from jQuery to coffeescript to Angular to React, according to the post.
- keypusher 11y ago
  Note the part where they rewrote their frontend everytime a cool new framework came out.
wdewind 11y ago
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.
- jshen 11y ago
  You can also scale ruby fine if the content is fairly static. It's only if it's massive scale and dynamic when you start to run into problems.
  - tobltobs 11y ago
    If your content is fairly static, everything will scale.
    - jshen 11y ago
      and you can often architect it so that most things are static! HN can be fairly static, right?
  - nathancahill 11y ago
    You can scale anything[0] if your content is fairly static. [0] https://github.com/avleen/bashttpd https://github.com/avleen/bashttpd
- romanovcode 11y ago
  AFAIK Nodejs is pretty damn memory intensive and does not do CPU tasks good as well. I believe Nodejs popularity is pure overhype. 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)...
  - mercer 11y ago
    From what I understand one of the main value propositions of Node in regards to async is that async is the default in the entire ecosystem. In fact, I vaguely recall Node's creator explain that he chose javascript precisely because it didn't already have an existing server-side ecosystem, so it could be async everywhere from the start. But by all means correct me if I'm wrong.
davmar 11y ago
So the new framework of choice now seems to be Node according to his graphs. I'm building in Node as we speak and I'm not loving the Promise pattern to solve callback hell. Will I get over it? Have others?
- 0x0 11y ago
  There was a pretty elegant post on how Python's coroutines can replace callback hell with almost-synchronous-looking async code on HN the other day: https://news.ycombinator.com/item?id=10220712 https://news.ycombinator.com/item?id=10220712 Wonder if something similar will catch on in the node ecosystem?
  - lastofus 11y ago
    Everyone forgets that Gevent has been around for years, and lets you write completely synchronous looking async code.
    - vangale 11y ago
      I think a better way of looking at it is there isn't enough "cross pollination" in big open-source frameworks and languages.
  - M2Ys4U 11y ago
    promises, async functions and generators will make writing async code look more sync in javascript/node. Whether or not this is a good thing or not, I'm undecided.
  - supster 11y ago
    Yeah ES7 has async and await which are pretty similar to that source: http://www.sitepoint.com/simplifying-asynchronous-coding-es7-async-functions/ http://www.sitepoint.com/simplifying-asynchronous-coding-es7...
- hayksaakian 11y ago
  ES6 has yield https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/yield https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
jph 11y ago
> 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. 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.
- kbar13 11y ago
  agreed. why optimize for the future when that optimization may directly block/slow your trajectory?
  - LoSboccacc 11y ago
    Because you have to maintain the app against known vulnerabilities. And in even a single year previous version of out app had multiple gems with vulnerabilities having to do a major version upgrade and I had to scrap the whole thing because older gems with fixes where unavailable or didn't build on modern rail/os 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.
    - scott_karana 11y ago
      If all your old gems had vulnerabilities, what makes you think bleeding edge ones didn't? Spoiler: the difference is, the new ones' bugs just aren't widely known yet.
    - mszyndel 11y ago
      > you need to stay bleeding edge all the time to have a chance to long term maintenance yeah, github is a perfect example or that, right? </irony>
    - deedubaya 11y ago
x5n1 11y ago
Despite all the naysayers I have kept with PHP and she's matured into a fine lady who doesn't let me down.
- WorldWideWayne 11y ago
  Maybe next time put it in terms of a fine wine or automobile.
  - scott_karana 11y ago
    Why? "Fine lady" implies that he and she work together, which probably fits the "ecosystem" of programming languages and programmers better. Unlike a mainly static inanimate asset like a car.
    - deleted 11y ago
      [deleted]
  - x5n1 11y ago
    Neither of those would fit the premise. But thank you PC person, I will tune my language in the future to meet societal obligations.
    - WorldWideWayne 11y ago
      You edited it to say that. Before it said something about a "hot blonde that was too expensive to touch". And I'm not PC at all and I didn't downvote you, but it's still good advice.
  - emj 11y ago
    fine partner?
- jskulski 11y ago
  I've worked in PHP since 2000 or so. 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.
andycroll 11y ago
I can definitely accept that Rails is now somewhat old hat. 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.
- kylnew 11y ago
  > If scalability and speed is a problem, congratulations, you're a success. 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.
  - mooreds 11y ago
    Right. Just finding something that you can build on (and get started yesterday) with the team you have. Of course, it doesn't hurt to pick from one of the top 10 languages so that, if you do succeed, you have a talent pool to pull from. But this is definitely a case of the perfect being the enemy of the good.
- ken47 11y ago
  I know static vs. dynamic typing was not covered in the article, but all things equal, it should be easier to onboard new devs into a statically typed codebase.
  - borkabrak 11y ago
edwinnathaniel 11y ago
> 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. 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
- chc 11y ago
  When people say Java is "verbose," they usually mean it is relatively hard to read, so I don't see what you mean by "code is written once to be read multiple times." The problem with Java's verbosity is that the code is typically full of noise and redundancy.
- dragonwriter 11y ago
  > > 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. > 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: https://www.python.org/psf/members/#sponsor-members https://www.python.org/psf/members/#sponsor-members
  - edwinnathaniel 11y ago
    I don't know what those sponsors do but I don't see any advancement in the Python world to be honest. 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...
Thaxll 11y ago
You should use whatever people you're working with know and are comfortable with. 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.
rubiquity 11y ago
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's attracting/has attracted a lot of people who don't care about the quality of code they write. JavaScript isn't any better and is probably even worse in this regard. 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.
- dragonwriter 11y ago
  > 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. 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.
  - rubiquity 11y ago
    A lot of companies basically hire in that way when their hiring means are through recruiters/job ads. Very few companies have the time/diligence or live in an area with enough of a developer pool to be finnicky about who they hire. Obviously there are ways (remote) to offset this but none of this addresses the fact of my initial statement.
    - ianstormtaylor 11y ago
      If your going with a don't "be finnicky about who [to] hire" hiring strategy, your company will have way bigger issues than programming framework choice, so it won't really matter.
- spdionis 11y ago
  Apparently ruby is going to be the next PHP?
jacinda 11y ago
> Django for Python is largely a rails clone Django was initially released in July 2005 (https://en.wikipedia.org/wiki/Django_(web_framework) https://en.wikipedia.org/wiki/Django_(web_framework)). Rails was initially released in December 2005 (https://en.wikipedia.org/wiki/Ruby_on_Rails 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.
- astrodust 11y ago
  CakePHP is a clone, or at least so heavily inspired by it may as well be. Django does its own thing, and while it has borrowed ideas, it is an entirely different beast.
  - jacinda 11y ago
    Agreed.
- anjc 11y ago
  Does anybody know which framework they were both inspired by at the time? I'd guess that the concept of MVC has been around for a long time but what kicked off the popularity in 2005? CakePHP was released before both of them, in 2005 too.
  - chc 11y ago
    Cake was released first, but I'm not sure that it looked much like later Cake did. It's been too long to remember.
  - mooreds 11y ago
    Backlash against Struts and other java MVC frameworks that were configuration heavy?
    - anjc 11y ago
      Yeah that makes sense
estsauver 11y ago
I still think Beating the Averages is an incredibly relevant essay for language choice. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html I couldn't be happier with Clojure and I don't really know what else I could want.
- dunkelheit 11y ago
  Reddit guys took the advice of this article to heart but fairly quickly had to rewrite the code in python. 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.
jowiar 11y ago
> 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. 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.
dkrich 11y ago
The author cites a graph of declining Google searches for "Ruby on Rails" relative to "Node.js" and then follows up with the statement: 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.
- Killswitch 11y ago
  Just devils advocate here but I highly doubt you never performed a search for rails again. I am very proficient in NodeJS, but I'm searching daily with the term for helping fix a bug I have. I am having an issue with es6 classes, I don't search "classes" or "programming classes" I search "es6 classes node.js" Boom, Node.JS now has a search term in trends.
  - molecule 11y ago
    When developing Rails applications, I rarely, if ever, include 'Rails' in my search terms, but rather drill down to the applicable component library: ActiveRecord, ActionController, Haml, Rack, etc.
    - geebee 11y ago
      This is a good idea, because it also avoids all those transportation or mining related results you often get with general "rails" or "ruby" searches. 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.
shruubi 11y ago
Couple of issues I have with this article 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
- mattdeboard 11y ago
  You were way more articulate in your response than I was. These really popular frameworks are "mostly static" because they have been out for years, battle-tested in production and improved for years.
  - Aeolun 11y ago
    PHP is not so static, has remained backwards compatible for many years, and people still bitch about it every chance they get. It's just something developers do. 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.
dunkelheit 11y ago
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: 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.
- volaski 11y ago
  If a company itself is "hip", it doesn't need to worry about "looking hip" to developers. If I was starting a company, I would focus on the productivity NOW rather than worrying about how hip it will make me look in 3 years. And from my experience Rails is THE most productive framework on the market at the moment. I really tried to like node and have built several apps with it but I didn't even feel half as productive as using rails
cies 11y ago
Article's author seems very favorable of Node: which would be lower on my list the Rails as a server-side language. 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.
- Killswitch 11y ago
  So I take it your website doesn't use any JavaScript whatsoever? You seem pretty against JavaScript.
bigtunacan 11y ago
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't know about?
- mercer 11y ago
  Just a small correction: Sails is actually built on top of Express.js.
- Killswitch 11y ago
  Most people who come to Node from other languages are running monolithic apps and are looking to replace those apps with the same MVC structure, just in their new language. Sails is one of those frameworks. Express and Koa on the otherhand are not so much setup for that. You have to do a lot of work to get Express and Koa to be a monolithic app.
  - deleted 11y ago
    [deleted]
arturhoo 11y ago
I sometimes wonder about this very question from month to month and I always end up seeing Rails as a winner. 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."
danmaz74 11y ago
> A few frameworks are strong contenders to be the successor to rails. Node.js is in the lead. 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.
- Killswitch 11y ago
  > Node.js isn't a framework. What about comparing apples with apples? What would you call it? Because it's not a language either. JavaScript is the language.
  - danmaz74 11y ago
    Evidently, "framework" suffers from semantic overload here. The article itself says that "Node.js suffers from fragmentation with a half dozen frameworks competing".
    - Killswitch 11y ago
      So how would we describe Node.js in this sense? It's not a framework, and it's not a language.
      - spdionis 11y ago
        Platform?
        Killswitch 11y ago
        I'm going to start calling it a doohicky.
  - 11y ago
snake117 11y ago
I'm learning Rails right now and this isn't the first time I heard how slow RoR can be. Hell, there's a whole site answering the "Can rails scale?" question (http://canrailsscale.com/ http://canrailsscale.com/). 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.
- xentronium 11y ago
  Rails eliminates a lot of choice and this is a huge deal. Hooking up db and setting rake tasks migrations for sinatra project might feel novel the first time you do it, but not really after that. 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.
  - nemild 11y ago
    Rails, Sinatra, Express developer here - each tool has different characteristics that make it better for some things and worse for others. 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.
gt565k 11y ago
"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." 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.
- dunkelheit 11y ago
  I'm curious, how would microservices architecture make the application faster? In my experience monoliths are faster (but they are indeed a pain to maintain) - instead of making the rpc request with all the overhead it implies, you can just pass objects in memory directly!
  - gt565k 11y ago
    Microservices allow you to scale individual components of your system and reduce technical debt by isolating them. 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.
transfire 11y ago
It will be interesting to see if [Crystal](http://crystal-lang.org/ http://crystal-lang.org/) 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. On the other hand, I think [Phoenix](http://www.phoenixframework.org/ 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-dawn-of-a-new-era-61256ec5a8f6 https://medium.com/javascript-scene/what-is-webassembly-the-...).
jimworm 11y ago
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't mean the tools that enable it are worthless, or worth less. 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.
nothrows 11y ago
He'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'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's tooling and strengths are completely different because they both have different use cases.
dankohn1 11y ago
I chose to use Node/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. 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.
mattdeboard 11y ago
One person's "old-hat dinosaur" is another's "battle-hardened". 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.
mpdehaan2 11y ago
When he's citing Node dominance, Javascript is mixed in there - and as we know, client side javascript is EVERYWHERE. 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.
mcphage 11y ago
I think the graph of framework searches doesn't show what the author claims. First off, the Django line hasn't moved much, and the node.js line has, 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't show anything else taking up that slack—so if Rails is being replaced (which is definitely possible) this graph doesn't really indicate by what. Nose.js has increased, but not by as much as Rails dropped. 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.
xacaxulu 11y ago
This is a great article. Unfortunately he's dead on about all the Bootcamp/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's worked swimmingly).
neoCrimeLabs 11y ago
Someone please correct me if I am wrong, but Node.JS is a server side javascript runtime environment, correct? 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. :-)
- nazka 11y ago
  If you want a real apple to apple comparison: Node.js = Rake, Sails.js = Ruby on Rails. 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...).
  - pfg 11y ago
    You probably mean rack. Rake is Ruby's version of Make.
    - mercer 11y ago
      Rack is actually best compared to Node's 'connect' middleware. So Node + connect + Express offers a very barebones framework (similar to Sinatra for Ruby, as I understand it). And while there are efforts to create bigger, more rails-like frameworks that build on top of node (and usually connect, and sometimes even express), as far as I can tell there's nothing quite ready to be compared to RoR.
- throwaway3453 11y ago
  It's possible that Node's culture of modules vs Rails' monolith design leads people to make these comparisons. News of Ruby outside of Rails being so infrequent certainly doesn't help either.
- meowface 11y ago
  It has some web "framework" components as well, though mostly in the same way Go has them. Otherwise, I agree.
reedlaw 11y ago
> 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. 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.
sytse 11y ago
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 http://yorickpeterse.com/articles/hello-gitlab/ http://yorickpeterse.com/articles/hello-gitlab/ 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.lock 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.
erichmond 11y ago
The only thing I'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. 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.
cwyers 11y ago
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're going to be in the vicinity of Java so it doesn't really mislead about anything. But Python and stock PHP being missing is throwing out the languages most comparable to Ruby.
- robmccoll 11y ago
  Knock yourself out: http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/
volaski 11y ago
They have time to re-write front-end four times from jQuery to Coffeescript to Angular to React, but think backend needs to be "future-proof"ed for 3 years?
tsotha 11y ago
There are certainly reasons to eschew rails in a new startup, but "nobody will be using it in three years" isn'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't survive three quarters, let alone three years.
S_A_P 11y ago
I think that should be titled "why I wouldn't use rails for a new company in Silicon Valley". 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.
ajma 11y ago
Article might show a trend that rails jobs are declining, but that's not true for my team. I'm looking to hire 12 ruby/rails engineers between New York and Seattle offices. New York: https://jobs.groupon.com/careers/engineering/ruby-software-engineer-full-stack-glive-new-york-city-ny-united-states-10756/ https://jobs.groupon.com/careers/engineering/ruby-software-e... Seattle: https://jobs.groupon.com/careers/engineering/senior-software-engineer-full-stack-glive-seattle-wa-united-states-10800/ https://jobs.groupon.com/careers/engineering/senior-software...
spacesword 11y ago
Im betting on Elixir + Phoenix framework being the future, for many reasons. Mainly speed and concurrency while still maintaining the productivity of rails.
dasil003 11y ago
> 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. 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.
headius 11y ago
My comment on the article has not been accepted yet, so I'll add it here... 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= 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= 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.

140 points by g4k 11y ago

romanovcode 11y ago

Using something just because it's popular is absurd. You will be switching to next "hip" thing every project then?

olouv 11y ago
One upside is clearly that it helps attract raw talent more easily with a hot/trendy stack, and to me, it's a more exciting adventure overall (more risky though).
- jskulski 11y ago
  Talent that comes in because a stack is hot/trendy are there by virtue that they lack the experience to know it's nothing knew. They haven't seen other hot/trendy stacks fail yet. Meaning they probably also lack experience to make decisions that avoid turning greenfields into a muddy hell. No thanks.
  - Killswitch 11y ago
    I agree, lets not use hot and trendy, who needs any of that? Rails? TO TRENDY! Lets use Fortran and COBOL!
misiti3780 11y ago
it depends what you mean, but i probably disagree - popular frameworks have more stack overflow answers, better docs, more bug fixes, and bigger ecosystems in general 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
- romanovcode 11y ago
  Not sure about the cheap aspect tho, in my area rails developers are one of most well paid.
  - misiti3780 11y ago
    fair enough - if you really want to save money - youd go with php
    - Killswitch 11y ago
      Worthwhile PHP developers are not cheap either. Unless you mean WordPress developers. (no, they're not PHP developers, they're WordPress developers. They only know WordPress)
clivestaples 11y ago
The article is about momentum not necessarily newness or hipness. Node.js is only three years younger than Rails.
- Killswitch 11y ago
  shhhhhh, it's to new and trendy. 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!
  - prewett 11y ago
    I have a great name for your browser: "Retro"
- djur 11y ago
  Node.js was first released in 2009, Rails in 2004 -- five years, not three.
calebm 11y ago
That's kind of like saying it's absurd to switch to a new social network because it is popular... as with social networks, languages/platforms are more useful when more people use and contribute to them. Good libraries cover a multitude of language feature sins.
volaski 11y ago
Apparently they did. They went from jQuery to coffeescript to Angular to React, according to the post.
keypusher 11y ago
Note the part where they rewrote their frontend everytime a cool new framework came out.

wdewind 11y ago

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.

jshen 11y ago
You can also scale ruby fine if the content is fairly static. It's only if it's massive scale and dynamic when you start to run into problems.
- tobltobs 11y ago
  If your content is fairly static, everything will scale.
  - jshen 11y ago
    and you can often architect it so that most things are static! HN can be fairly static, right?
- nathancahill 11y ago
  You can scale anything[0] if your content is fairly static. [0] https://github.com/avleen/bashttpd https://github.com/avleen/bashttpd
romanovcode 11y ago
AFAIK Nodejs is pretty damn memory intensive and does not do CPU tasks good as well. I believe Nodejs popularity is pure overhype. 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)...
- mercer 11y ago
  From what I understand one of the main value propositions of Node in regards to async is that async is the default in the entire ecosystem. In fact, I vaguely recall Node's creator explain that he chose javascript precisely because it didn't already have an existing server-side ecosystem, so it could be async everywhere from the start. But by all means correct me if I'm wrong.

davmar 11y ago

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

0x0 11y ago
There was a pretty elegant post on how Python's coroutines can replace callback hell with almost-synchronous-looking async code on HN the other day: https://news.ycombinator.com/item?id=10220712 https://news.ycombinator.com/item?id=10220712 Wonder if something similar will catch on in the node ecosystem?
- lastofus 11y ago
  Everyone forgets that Gevent has been around for years, and lets you write completely synchronous looking async code.
  - vangale 11y ago
    I think a better way of looking at it is there isn't enough "cross pollination" in big open-source frameworks and languages.
- M2Ys4U 11y ago
  promises, async functions and generators will make writing async code look more sync in javascript/node. Whether or not this is a good thing or not, I'm undecided.
- supster 11y ago
  Yeah ES7 has async and await which are pretty similar to that source: http://www.sitepoint.com/simplifying-asynchronous-coding-es7-async-functions/ http://www.sitepoint.com/simplifying-asynchronous-coding-es7...
hayksaakian 11y ago
ES6 has yield https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/yield https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

jph 11y ago

> 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. 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.

kbar13 11y ago
agreed. why optimize for the future when that optimization may directly block/slow your trajectory?
- LoSboccacc 11y ago
  Because you have to maintain the app against known vulnerabilities. And in even a single year previous version of out app had multiple gems with vulnerabilities having to do a major version upgrade and I had to scrap the whole thing because older gems with fixes where unavailable or didn't build on modern rail/os 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.
  - scott_karana 11y ago
    If all your old gems had vulnerabilities, what makes you think bleeding edge ones didn't? Spoiler: the difference is, the new ones' bugs just aren't widely known yet.
  - mszyndel 11y ago
    > you need to stay bleeding edge all the time to have a chance to long term maintenance yeah, github is a perfect example or that, right? </irony>
  - deedubaya 11y ago

x5n1 11y ago

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

WorldWideWayne 11y ago
Maybe next time put it in terms of a fine wine or automobile.
- scott_karana 11y ago
  Why? "Fine lady" implies that he and she work together, which probably fits the "ecosystem" of programming languages and programmers better. Unlike a mainly static inanimate asset like a car.
  - deleted 11y ago
    [deleted]
- x5n1 11y ago
  Neither of those would fit the premise. But thank you PC person, I will tune my language in the future to meet societal obligations.
  - WorldWideWayne 11y ago
    You edited it to say that. Before it said something about a "hot blonde that was too expensive to touch". And I'm not PC at all and I didn't downvote you, but it's still good advice.
- emj 11y ago
  fine partner?
jskulski 11y ago
I've worked in PHP since 2000 or so. 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.

andycroll 11y ago

I can definitely accept that Rails is now somewhat old hat. 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.

kylnew 11y ago
> If scalability and speed is a problem, congratulations, you're a success. 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.
- mooreds 11y ago
  Right. Just finding something that you can build on (and get started yesterday) with the team you have. Of course, it doesn't hurt to pick from one of the top 10 languages so that, if you do succeed, you have a talent pool to pull from. But this is definitely a case of the perfect being the enemy of the good.
ken47 11y ago
I know static vs. dynamic typing was not covered in the article, but all things equal, it should be easier to onboard new devs into a statically typed codebase.
- borkabrak 11y ago

edwinnathaniel 11y ago

> 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. 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

chc 11y ago
When people say Java is "verbose," they usually mean it is relatively hard to read, so I don't see what you mean by "code is written once to be read multiple times." The problem with Java's verbosity is that the code is typically full of noise and redundancy.
dragonwriter 11y ago
> > 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. > 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: https://www.python.org/psf/members/#sponsor-members https://www.python.org/psf/members/#sponsor-members
- edwinnathaniel 11y ago
  I don't know what those sponsors do but I don't see any advancement in the Python world to be honest. 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...

Thaxll 11y ago

You should use whatever people you're working with know and are comfortable with. 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.

rubiquity 11y ago

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's attracting/has attracted a lot of people who don't care about the quality of code they write. JavaScript isn't any better and is probably even worse in this regard. 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.

dragonwriter 11y ago
> 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. 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.
- rubiquity 11y ago
  A lot of companies basically hire in that way when their hiring means are through recruiters/job ads. Very few companies have the time/diligence or live in an area with enough of a developer pool to be finnicky about who they hire. Obviously there are ways (remote) to offset this but none of this addresses the fact of my initial statement.
  - ianstormtaylor 11y ago
    If your going with a don't "be finnicky about who [to] hire" hiring strategy, your company will have way bigger issues than programming framework choice, so it won't really matter.
spdionis 11y ago
Apparently ruby is going to be the next PHP?

jacinda 11y ago

> Django for Python is largely a rails clone Django was initially released in July 2005 (https://en.wikipedia.org/wiki/Django_(web_framework) https://en.wikipedia.org/wiki/Django_(web_framework)). Rails was initially released in December 2005 (https://en.wikipedia.org/wiki/Ruby_on_Rails 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.

astrodust 11y ago
CakePHP is a clone, or at least so heavily inspired by it may as well be. Django does its own thing, and while it has borrowed ideas, it is an entirely different beast.
- jacinda 11y ago
  Agreed.
anjc 11y ago
Does anybody know which framework they were both inspired by at the time? I'd guess that the concept of MVC has been around for a long time but what kicked off the popularity in 2005? CakePHP was released before both of them, in 2005 too.
- chc 11y ago
  Cake was released first, but I'm not sure that it looked much like later Cake did. It's been too long to remember.
- mooreds 11y ago
  Backlash against Struts and other java MVC frameworks that were configuration heavy?
  - anjc 11y ago
    Yeah that makes sense

estsauver 11y ago

I still think Beating the Averages is an incredibly relevant essay for language choice. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html I couldn't be happier with Clojure and I don't really know what else I could want.

dunkelheit 11y ago
Reddit guys took the advice of this article to heart but fairly quickly had to rewrite the code in python. 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.

jowiar 11y ago

> 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. 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.

dkrich 11y ago

The author cites a graph of declining Google searches for "Ruby on Rails" relative to "Node.js" and then follows up with the statement: 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.

Killswitch 11y ago
Just devils advocate here but I highly doubt you never performed a search for rails again. I am very proficient in NodeJS, but I'm searching daily with the term for helping fix a bug I have. I am having an issue with es6 classes, I don't search "classes" or "programming classes" I search "es6 classes node.js" Boom, Node.JS now has a search term in trends.
- molecule 11y ago
  When developing Rails applications, I rarely, if ever, include 'Rails' in my search terms, but rather drill down to the applicable component library: ActiveRecord, ActionController, Haml, Rack, etc.
  - geebee 11y ago
    This is a good idea, because it also avoids all those transportation or mining related results you often get with general "rails" or "ruby" searches. 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.

shruubi 11y ago

Couple of issues I have with this article 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

mattdeboard 11y ago
You were way more articulate in your response than I was. These really popular frameworks are "mostly static" because they have been out for years, battle-tested in production and improved for years.
- Aeolun 11y ago
  PHP is not so static, has remained backwards compatible for many years, and people still bitch about it every chance they get. It's just something developers do. 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.

dunkelheit 11y ago

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: 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.

volaski 11y ago
If a company itself is "hip", it doesn't need to worry about "looking hip" to developers. If I was starting a company, I would focus on the productivity NOW rather than worrying about how hip it will make me look in 3 years. And from my experience Rails is THE most productive framework on the market at the moment. I really tried to like node and have built several apps with it but I didn't even feel half as productive as using rails

cies 11y ago

Article's author seems very favorable of Node: which would be lower on my list the Rails as a server-side language. 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.

Killswitch 11y ago
So I take it your website doesn't use any JavaScript whatsoever? You seem pretty against JavaScript.

bigtunacan 11y ago

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't know about?

mercer 11y ago
Just a small correction: Sails is actually built on top of Express.js.
Killswitch 11y ago
Most people who come to Node from other languages are running monolithic apps and are looking to replace those apps with the same MVC structure, just in their new language. Sails is one of those frameworks. Express and Koa on the otherhand are not so much setup for that. You have to do a lot of work to get Express and Koa to be a monolithic app.
- deleted 11y ago
  [deleted]

arturhoo 11y ago

I sometimes wonder about this very question from month to month and I always end up seeing Rails as a winner. 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."

danmaz74 11y ago

> A few frameworks are strong contenders to be the successor to rails. Node.js is in the lead. 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.

Killswitch 11y ago
> Node.js isn't a framework. What about comparing apples with apples? What would you call it? Because it's not a language either. JavaScript is the language.
- danmaz74 11y ago
  Evidently, "framework" suffers from semantic overload here. The article itself says that "Node.js suffers from fragmentation with a half dozen frameworks competing".
  - Killswitch 11y ago
    So how would we describe Node.js in this sense? It's not a framework, and it's not a language.
    - spdionis 11y ago
      Platform?
      - Killswitch 11y ago
        I'm going to start calling it a doohicky.
- 11y ago

snake117 11y ago

I'm learning Rails right now and this isn't the first time I heard how slow RoR can be. Hell, there's a whole site answering the "Can rails scale?" question (http://canrailsscale.com/ http://canrailsscale.com/). 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.

xentronium 11y ago
Rails eliminates a lot of choice and this is a huge deal. Hooking up db and setting rake tasks migrations for sinatra project might feel novel the first time you do it, but not really after that. 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.
- nemild 11y ago
  Rails, Sinatra, Express developer here - each tool has different characteristics that make it better for some things and worse for others. 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.

gt565k 11y ago

"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." 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.

dunkelheit 11y ago
I'm curious, how would microservices architecture make the application faster? In my experience monoliths are faster (but they are indeed a pain to maintain) - instead of making the rpc request with all the overhead it implies, you can just pass objects in memory directly!
- gt565k 11y ago
  Microservices allow you to scale individual components of your system and reduce technical debt by isolating them. 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.

transfire 11y ago

It will be interesting to see if [Crystal](http://crystal-lang.org/ http://crystal-lang.org/) 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. On the other hand, I think [Phoenix](http://www.phoenixframework.org/ 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-dawn-of-a-new-era-61256ec5a8f6 https://medium.com/javascript-scene/what-is-webassembly-the-...).

jimworm 11y ago

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't mean the tools that enable it are worthless, or worth less. 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.

nothrows 11y ago

He'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'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's tooling and strengths are completely different because they both have different use cases.

dankohn1 11y ago

I chose to use Node/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. 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.

mattdeboard 11y ago

One person's "old-hat dinosaur" is another's "battle-hardened". 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.

mpdehaan2 11y ago

When he's citing Node dominance, Javascript is mixed in there - and as we know, client side javascript is EVERYWHERE. 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.

mcphage 11y ago

I think the graph of framework searches doesn't show what the author claims. First off, the Django line hasn't moved much, and the node.js line has, 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't show anything else taking up that slack—so if Rails is being replaced (which is definitely possible) this graph doesn't really indicate by what. Nose.js has increased, but not by as much as Rails dropped. 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.

xacaxulu 11y ago

This is a great article. Unfortunately he's dead on about all the Bootcamp/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's worked swimmingly).

neoCrimeLabs 11y ago

Someone please correct me if I am wrong, but Node.JS is a server side javascript runtime environment, correct? 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. :-)

nazka 11y ago
If you want a real apple to apple comparison: Node.js = Rake, Sails.js = Ruby on Rails. 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...).
- pfg 11y ago
  You probably mean rack. Rake is Ruby's version of Make.
  - mercer 11y ago
    Rack is actually best compared to Node's 'connect' middleware. So Node + connect + Express offers a very barebones framework (similar to Sinatra for Ruby, as I understand it). And while there are efforts to create bigger, more rails-like frameworks that build on top of node (and usually connect, and sometimes even express), as far as I can tell there's nothing quite ready to be compared to RoR.
throwaway3453 11y ago
It's possible that Node's culture of modules vs Rails' monolith design leads people to make these comparisons. News of Ruby outside of Rails being so infrequent certainly doesn't help either.
meowface 11y ago
It has some web "framework" components as well, though mostly in the same way Go has them. Otherwise, I agree.

reedlaw 11y ago

> 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. 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.

sytse 11y ago

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 http://yorickpeterse.com/articles/hello-gitlab/ http://yorickpeterse.com/articles/hello-gitlab/ 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.lock 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.

erichmond 11y ago

The only thing I'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. 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.

cwyers 11y ago

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're going to be in the vicinity of Java so it doesn't really mislead about anything. But Python and stock PHP being missing is throwing out the languages most comparable to Ruby.

robmccoll 11y ago
Knock yourself out: http://benchmarksgame.alioth.debian.org/ http://benchmarksgame.alioth.debian.org/

volaski 11y ago

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

tsotha 11y ago

There are certainly reasons to eschew rails in a new startup, but "nobody will be using it in three years" isn'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't survive three quarters, let alone three years.

S_A_P 11y ago

I think that should be titled "why I wouldn't use rails for a new company in Silicon Valley". 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.

ajma 11y ago

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

spacesword 11y ago

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

dasil003 11y ago

> 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. 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.

headius 11y ago

My comment on the article has not been accepted yet, so I'll add it here... 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= 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= 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.