
Why I wouldn’t use Rails for a new company - g4k
http://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company
======
andycroll
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.

~~~
ken47
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
Could you elaborate on what you mean?

I'm not arguing; just curious.

~~~
ken47
New devs do not have a cache of the codebase in their mind, therefore their
mental compiler (because that's what you're utilizing any time you code in a
dynamic language) is more prone to make mistakes than devs who know what parts
of the codebase to "compile" when they make modifications.

Some may argue that tests can theoretically cover all these bases. I would
counter that in practice, tests almost never come close to serving as a poor
man's compiler.

And of course, not even a dev who is experienced with the codebase could
replace a true compiler, but I'd assume that this is deliberate trade-off, if
there were competent technical decision-makers involved

------
gt565k
"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
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!

~~~
StavrosK
They don't. They just force less disciplined devs to incur less technical debt
by making interfaces inviolable.

Personally, it would take a lot for me to switch a part of my monolith to a
microservice and lose the speed of having everything done in the same process
and the guarantees that having a single relational database offers. Having to
reconcile data that got off sync because it was in two different data stores
is not fun for anyone, and, to me, it's not worth it just to force yourself to
not call any private methods on the other service. I just expose a public ABI
and say "to interact with this part of the application, you may only call
these functions here".

~~~
gt565k
You can use the same data store with different services.

If you have a web application that handles most of the traffic on your site,
and you have some management task/process that hogs resources in the same
application, you're affecting your end users by running those processes on the
same service.

The idea of microservices is to separate components so one does not affect the
other, and you can scale individual components easily.

~~~
StavrosK
Define "application". You can easily have the task be a part of the same
codebase and run on a different process or even server. For example, my Django
maintenance commands run on a different server, and so do tasks, but they're
still part of the same monolithic codebase.

------
jph
> 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
agreed. why optimize for the future when that optimization may directly
block/slow your trajectory?

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

~~~
deedubaya
Those aren't rails specific issues.

If you want to run on old software that you don't have to upgrade or maintain,
you are going to pay for someone else to do it.

If you want your cake and to eat it too, you're unrealistic.

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

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

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

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

~~~
mooreds
Backlash against Struts and other java MVC frameworks that were configuration
heavy?

~~~
retbull
Jboss/Spring is making me want to slash my wrists right now I can see how it
could come about.

------
sytse
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....](https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/Gemfile.lock) 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.

------
wdewind
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
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
If your content is fairly static, everything will scale.

~~~
jshen
and you can often architect it so that most things are static! HN can be
fairly static, right?

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

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

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

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

~~~
dragonwriter
> Go to Microsoft Learning, you'll find lots of JavaScript tutorials (NodeJS
> or WinJS or Angular)

And also quite a bit of Python, including general language courses, Django,
Python/Flask/SQL, Python w/MongoDB, etc.

> When Microsoft decided to hire people behind IronRuby and IronPython, I
> thought they decided to adopt those languages but that didn't last long
> before they cut them loose...

Microsoft is still a significant backer of Python, not _just_ a PSF sponsor,
but also directly employing Python core devs, and doing a lot of direct
support for Python. [0]

IronPython and IronRuby weren't Microsoft adopting the Ruby and Python
languaegs, they were efforts to alternatives to the core implementations of
those languages tied to the .NET platform.

[0] See, e.g., [http://pycon.blogspot.com/2015/03/for-microsoft-python-
suppo...](http://pycon.blogspot.com/2015/03/for-microsoft-python-support-
extends.html)

------
transfire
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-...](https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-
a-new-era-61256ec5a8f6)).

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

~~~
dcre
I agree with you, but I suspect (not a node dev) the reason people talk this
way is that almost everyone uses Express as their server, and a lot of people
use NoSQL databases, which means they can live without an ORM, at least when
they start out. (That probably doesn't mean they don't end up building a layer
of abstraction over the database at some point.)

~~~
mercer
That's exactly how I'm using Node currently. While RoR would be smarter and
faster if budget/time was an issue, I currently have the luxury of building a
relatively simple site+CMS for a client with total freedom and a lot of time
on my hands.

After battling Rails' conventions and getting a bit sick of learning a lot of
things that are only useful in the Rails world, I figured it might be nice to
do everything almost from scratch (Express.js as a shortcut though). I'm using
RethinkDB without an ORM, although over time I suspect my approach will become
more ORM-like over time and I might just switch to one of the existing
RethinkDB ORM's.

It's loads of fun being able to understand most steps of the process of
building a complete website that includes authentication, a database, a CMS,
and whatnot, especially after relying on Rails' magic for a lot of things. I
guess I just really prefer the explicitness of it all.

That said, if money and/or time were an issue, or if the end product would
have to be worked on by other developers, I'd probably go for RoR or Django.
The amount of stuff it 'just' takes care of is much more than one might assume
at first, and the amount of pitfalls in the category 'not knowing what you
don't know' are not insignificant (XSS, for example).

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

~~~
volaski
"a significant part about what attracts us to a language is the quality of
people who use it." <= where did this theory even come from? I learned to
program because I wanted to build stuff. I couldn't care less about "quality"
of other people who's using a language, I only care about how productive it
makes me.

~~~
rubiquity
> * I learned to program because I wanted to build stuff. I couldn't care less
> about "quality" of other people who's using a language*

You're conflating "learning to program" with "using a specific programming
language."

~~~
volaski
OK then let me add "Rails" to that sentence if this makes you feel better. _I
learned to program Rails because I wanted to build stuff. I couldn 't care
less about "quality" of other people who's using it_

Rails was and is the most productive web development framework and that's why
I use it. I don't even know who's in rails community.

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

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

~~~
clivestaples
The article is about momentum not necessarily newness or hipness. Node.js is
only three years younger than Rails.

~~~
Killswitch
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
I have a great name for your browser: "Retro"

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

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

~~~
mattdeboard
It's a runtime for JavaScript. It's definitely not a framework.

~~~
Killswitch
V8 is the runtime.

~~~
mattdeboard
Er, I'm far, far from a JS expert let alone V8, but I thought V8 does the
compilation to machine code and Node serves as the process containing the
thread the program is running on, making Node the runtime, and V8 the engine.

That and nodejs.org calls it a runtime built on V8 :P

------
cwyers
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
Knock yourself out:
[http://benchmarksgame.alioth.debian.org/](http://benchmarksgame.alioth.debian.org/)

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

------
cies
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
So I take it your website doesn't use any JavaScript whatsoever? You seem
pretty against JavaScript.

------
davmar
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
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
Everyone forgets that Gevent has been around for years, and lets you write
completely synchronous looking async code.

~~~
vangale
I think a better way of looking at it is there isn't enough "cross
pollination" in big open-source frameworks and languages.

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

------
ajma
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-e...](https://jobs.groupon.com/careers/engineering/ruby-software-
engineer-full-stack-glive-new-york-city-ny-united-states-10756/)

Seattle: [https://jobs.groupon.com/careers/engineering/senior-
software...](https://jobs.groupon.com/careers/engineering/senior-software-
engineer-full-stack-glive-seattle-wa-united-states-10800/)

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

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

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

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

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

------
bigtunacan
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?

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

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

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

------
volaski
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?

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

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

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

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

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

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

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

~~~
WorldWideWayne
Maybe next time put it in terms of a fine wine or automobile.

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

