
DHH answers: What makes Rails a framework worth learning in 2017? - gavingmiller
https://www.quora.com/What-makes-Rails-a-framework-worth-learning-in-2017/answer/David-Heinemeier-Hansson?srid=tfS&amp;share=1
======
meesterdude
This reinforces what I see a lot too - people creating yet another XYZ, but
rarely I see someone go and create an integrated solution to streamline
development processes or make things easier or clearer.

There are a lot of vocal people who make it seem like you should be doing
everything in Go or Angular or what have you, but I want nothing to do with
either, and do not have problems that those are meant to solve. I love ruby,
and I love rails.

DHH regularly sounds the drum of rationality - in a community at large of
idealists and extremists. He is the reason I got into programming, and
constantly serves to remind me that what I'm doing is, in fact, perfectly
fine; and that everyone else puts up with a lot of nonsense for no great
reason.

There are other frameworks out there, but you'd be hard pressed to find one
with a leader that has such a sense of direction and reason for why the
framework does what it does, and does not.

~~~
ooqr
I am a rails dev. I inherited a legacy application. The biggest problem with
Ruby/Rails is that anything Ruby will allow, someone will do. Ruby is the
language I learned data structures and algorithms in, built my first
significant projects in. It has a generous wealth of helpful builtins. But it
makes me long for strictness, static typing, a language where not just
anything can completely modify any other.

~~~
knivets
This. Often, you can't find where this variable or function comes from. You
read the sources only to discover that there is no trace of this variable and
it is probably defined dynamically in some callback. You can only find this
kind of stuff with the help of debugger. The dynamism, which allows one to
create beautiful interfaces, and is often advertised as a programmer's friend,
is actually the enemy of the programmer who is going to read the code
afterwards.

~~~
ooqr
I've actually run into methods defined from names concatenated from multiple
strings, i.e. methods you can't even use grep over the whole codebase to find.
This has left me with a lingering vague fear ever since.

~~~
bitwize
I've seen worse.

A system that would load chunks of code out of MySQL and eval them in place.

Magic variables with magic meanings... _shudder_

~~~
kazinator
Sounds like the coder was might have been imitating the idea of SQL stored
procedures.

~~~
bitwize
Actually he was imitating Lotus Notes...

------
vinhboy
> formalizing conventions, eliminating valueless choices, and offering a full-
> stack framework that provides great defaults for anyone who wants to create
> a complete application

Maybe I've drank the kool-aid too much, but I agree with this whole-heartedly.

It reminds me of when I want to paint a room. I can go to Home Depot and spend
an hour picking out all the tools I need, or I can buy one of those pre-packed
toolkit and get to the actual painting immediately.

Rails + Heroku = My product will be ready to demo by end of the week.

Obviously this mentality only applies to people like me who wants to get
things done quickly. People who value craftsmanship and specificity should do
what pleases them. (That's not to say you can't do quality work with pre-
packed toolkits)

~~~
astrodust
In the last few months I've built a brand new Node + Express application, and
I've built a brand new Rails 5.x one.

ES6 has taken the edge off of some of the more obnoxious parts of JavaScript,
but it still has a long way to go to catch up to Ruby, and Express is a cheap
imitation of Rails.

It takes me over a day to get an Express application up and running. There's
dozens of dependencies to wrangle into place. There's hundreds of lines of
code to sketch in even the most basic of applications. So many directories to
create, so many new files you have to basically build by hand. There's
Gulpfiles to configure. There's a lot of work to integrate Passport. It's a
lot of work to get as far as "Hello, world".

Meanwhile rails new and some Gemfile dependencies get you almost all the way
there within an hour. Then you're making database migrations and laying in CSS
and layouts.

I love both Node and Ruby for different reasons, but the out-of-the-box
experience for Express is total garbage. You can't even parse a cookie without
installing a module for that.

Node is way easier to create real-time services, like a Socket.io server in
JavaScript is way less fuss than Ruby+EventMachine. It absolutely kills it
when writing thin JSON APIs, and in terms of performance it's ridiculous.
There's nothing preventing Node from having a Rails-like easy start for web
applications but the attitude of the community where making decisions for
people and having sane defaults is apparently against the rules.

~~~
tcfunk
> It takes me over a day to get an Express application up and running.

I feel so much better after seeing this sentiment here. I've tried to dip my
toe into the node.js world repeatedly only to feel like I'm trudging through
setup for hours.

Of course I may have incorrect memories of how difficult/easy it was to set up
my first rails app however long ago.

~~~
astrodust
I should also add it "only" takes me a day because I can crib from a half
dozen other Express projects I've created in the past and cherry-pick cut-and-
paste parts that I like.

As one example my web app Gulpfile has evolved significantly from the first
iteration and it would take multiple days to recreate all of that from
scratch.

The Rails Asset Pipeline might be obnoxiously rigid, but at least it _works_
without having to tear your hair out.

~~~
wcarron
Forgive me, but what apps do you work on that have such a complex and lengthy
gulpfile?

~~~
astrodust
Nothing exotic but even a routine web application can have 150-250 lines of
Gulp directives. Zero of this is provided for you.

Each chunk is fairly small, but they add up. You want linting, auto-restart on
changes, tests, your various asset chains to compile things correctly, etc.

~~~
wcarron
Ok, I see your point. I, too, hate writing boilerplate code. But I did three
things to resolve this: I built a `config.js` file, which contains the paths
to resource files in a more compact format, and is sourced into the gulpfile.
I then replaced long path strings with easier to read code.

I also threw my standard gulpfile into a git repo, so if I need it, it's
there.

Lastly, I built a yeoman generator. Now, not only is my gulpfile standardized,
but I have the rest of my skeleton application built in a matter of minutes.
All my favorite libraries/npm modules, custom scss files, basic routing to the
standard pages of a simple site, are all built out for me to my preferences
while I make a cup of coffee. You can even provide yourself command line flags
to determine whether or not to include tests, which preprocessors for html or
css you prefer, etc. Really a worthwhile investment.

Write once, utilize many times.

~~~
astrodust
Tools like Yeoman can help here, but they're also relatively obscure and
there's a lot of yak shaving involved in getting them working correctly.

In a sense complaining about this the Node world is like asking fish how they
can stand being wet all the time. It's just part of the terrain.

I'm not saying what Node is doing is fundamentally wrong, but that this almost
absurd aversion to making decisions for users is sometimes a bad thing.

For example, I'd love to be able to declare dependencies for an NPM module
that are open-eneded, like "any one of A, B, or C will do", but like it is
with Ruby, Python, etc. you must declare all or none.

I'm not trying to restrict choice, just cover the base condition of when you
don't care of providing a sane default.

To a degree Rails has this: The first thing I do in a new project is jettison
all the garbage I don't want (see you later turbolinks) and drop in all the
things I do want. It's actually just a few lines to manipulate, so I can
hardly complain.

In the Node world there's a lot of hand-holding required to get even the most
basic application up and running. I can see this getting cut down dramatically
if you had things like "npm install express +extras" where there was some way
of saying "plus whatever other stuff you think is a good idea", or even an
"express-fully-loaded" version of the package that comes with a bunch of stuff
out of the box.

I really like Gulp and _when configured_ it gives you an amazing amount of
control over your build process. Although the Rails Asset Pipeline system
works as a pretty good default out-of-the-box they really should steal some
ideas from Gulp on configurability for those occasions where you want to
change the default behaviour.

Vinyl.fs ([https://github.com/gulpjs/vinyl-
fs](https://github.com/gulpjs/vinyl-fs)) is an amazing thing that the Ruby
world desperately needs.

~~~
wcarron
Yup. I think, as you say, it's a part of the terrain of the ecosystem. Could
the makers of Express have created a more comprehensive boilerplate that
includes things like Helmet, Async, Moment, gulp, etc., etc.? Yeah, and I
definitely think it would be a good addition to the community if they had. On
the other hand, I do agree with the general sentiment that by forcing you to
include the dependencies you desire, the programmer exerts more control over
what is in the app, and it forces them to actually understand what they're
doing with each package.

In the end it boils down to: Start with a monolith and chisel away the stuff
you don't want - RoR, or start with a skeleton and add what you need as you
need it.

------
throwanem
Rails showed us all that web development didn't have to be PHP and Apache and
constant headaches. Node and Phoenix and the modern paradigm in general
wouldn't have come into existence, or achieved the popularity they have,
without an act like Rails to follow. That's awesome, and I respect it for
that.

But can it truly be said that Rails has a purpose today? Its default
performance remains lousy with any kind of load. Its convention-first approach
means Rails knowledge doesn't easily generalize, as can be seen in this very
comment thread from the experience of those who've approached the Node
ecosystem as though it were "Javascript on Rails". The "history? what
history?" attitude of its BDFL and his clique makes cause for trepidation out
of the prospect of maintaining a Rails app over a significant length of time.
And even by comparison with ES5, Ruby is a hot mess.

I get that DHH has to defend it. It's his baby, after all. But it's been a
long time indeed since Rails had anything unique to offer beyond an ideology
which is, in its own way, every bit as much a straitjacket as RMS' \- and
Rails' inheritors have innovated in ways that straitjacket makes it very hard
at best for Rails to match.

~~~
patsplat
Agreed. Would love to see DHH build an opinionated framework for node rather
than waxing poetic about Ruby.

~~~
wyaeld
This is the first time I've seen someone complain that Ruby is a worse
language than JS(ES5). Care to elaborate for those curious?

~~~
tracker1
JS is simply the language that runs in the browser... even with newer options
for compiled code coming close to being a reality, it'll be a while before
tooling catches up.

JS is actually a decent language, and imho with more recent advancements
better still. Combined with npm there is simply anything you might need
available (for the most part). Not that there aren't a lot of gems out there.

In the end, having one language to think about, rather than how to shoehorn
communications and logic between two languages is simply more difficult. I
went, similarly from C# to node, not because I didn't like C#, but because the
friction in writing JS on the server and the client was so reduced from two
differing languages throughout the day.

Similarly a lot of devs went to simpler data stores so they don't have to deal
with layers of ORMs that only half work, and can simply store and query basic
data forms. Mongo fits this development model well, early hiccups in the
technology aside.

In the end, it allows you to build web apps in one language, and not have to
write translations to get from one to the other on the client.

~~~
mvindahl
Absolutely agree.

I've helped maintain REST APIs in both Java and NodeJS at different points in
time.

Doing so in Java was always a painful iterative process; ask the ORM for data,
painstakingly map the data to Java DTOs created mostly for defining JSON
structure, pass it off to RESTEasy or some similar framework, see how the JSON
turned out. Adjust and repeat until satisfied. Yuck.

In NodeJS, by contrast, fire off the SQL to get the data, map into the JS
object that you need and return it.

Kind of funny how, years back, a selling point of GWT was that you could use
the same language across the stack. It wasn't a bad idea, just a poor choice
of language.

------
eranation
I completely agree on one aspect, anywhere I go, the kitchen sink is missing.
You want to compress responses? well, there is an npm / jar / pip library for
that. Want to have ORM? just npm / pip / "your package manager here" and you
are done.

You can say a lot about Rails but I like the idea that everything I commonly
need as a web developer is most likely already in the framework, and there is
usually a best practice way to do things. Options are great, but moving out of
plumbing and into generating value to customers is still having a value.

If you don't like opinionated, batteries included solutions then Rails is not
for you.

However there are other solutions that kind-of cloned some aspects of Rails.
Playframework (Scala has a lot more similarities to Ruby IMHO than to Java, at
least in philosophy). Also Spring Boot or JHipster (Spring boot + Yeoman -
super opinionated)

------
bobbytherobot
Maybe Rails has changed from when I last used it five years ago, but I dealt
with many of the issues DHH makes against other technology.

> That people spent hours, if not days, just setting up the skeletons. The
> basic build configurations.

I spent hours everyday getting the asset pipeline to work, or it would break
again, meaning I would have to fix it again.

> The vast majority of activity today is for yet another option on the a la
> carte menu.

Every week the developers want to switch out some module for another module
within Rails because it was the hot new thing.

Maybe I worked on a bad project. Maybe I didn't get it. Maybe it was a growing
pain that has passed. Rails was a pain in the ass to get to work. The ORM was
cool, but did it save me time or mistakes from writing SQL - no.

I would love other people's opinions who have stuck with Rails.

~~~
deedubaya
> I spent hours everyday getting the asset pipeline to work, or it would break
> again, meaning I would have to fix it again.

I used to have this problem too -- more so in the early days of asset
pipeline. Mostly when trying to use some client side framework. Rails is
working on (or maybe already available, I'm not sure) yarn/webpack support.

> Every week the developers want to switch out some module for another module
> within Rails because it was the hot new thing.

Replacing the batteries which are included can be painful at times. If you
want to use the new hotness in Rails, it comes at a price of extra work
getting it working... but it only seems painful when comparing to the included
batteries -- they just work. Support for different test frameworks, orms,
templating languages are pretty good anymore though and are easier to swap
out.

You'll definitely have a better experience with Rails if you forego the desire
to run the latest and greatest and just use what Rails already has.

~~~
throwanem
Until a new point release comes out and everyone forgets about the one you're
running. Then you get to find out how much of your code you'll need to rewrite
so it'll run with the Rails chefs' wild new menu. And there's no point even
trying with an app written for an earlier major version. Just give up now,
because the whole ocean's been boiled and recondensed since then, and now
occupies but few of the basins it once did.

Granted, it's been a couple years since I dealt with any Rails apps. That's in
large part by design, because every Rails app has a relatively high curation
cost just to keep it up to date with the latest and greatest, and you have to
do that if you want to be able to add features or usefully maintain anything
without undue agony, because the Rails community has the collective memory of
a goldfish and even less interest in maintaining continuity with the past.

I get that that's the big selling point, the drum DHH and his fans never stop
beating: "Rails is omakase." This is a fundamentally broken metaphor, because
sushi is dead by the time it gets to you, and all you have to do with it is
eat it; the history of the ingredients is of little consequence. Would that
software were so simple.

~~~
deedubaya
> Until a new point release comes out and everyone forgets about the one
> you're running

This is definitely a pain you'll feel with rails, and any other combination of
software pieces which you bring together.

For what it's worth, within the last month, I've touched rails 3.2, 4.0, 4.1,
5.0, and 5.0.1 apps which are running in production. It's possible to maintain
these apps on old releases, but the idea of never upgrading will be painful in
the end.

~~~
throwanem
It's worse in Rails because of the rate of change and the near-total lack of
interest in backwards compatibility. Granted that the change in question often
improves Rails' performance or stability, but that so much scope seems to go
on existing for such improvements is in itself concerning, and the larger
question, of whether it would be wiser to instead invest in a less volatile
and more stable platform, remains valid.

------
currywurst
I admire the way DHH writes .. confident and persuasive.

However, I'd just like to point out that in the same span of time JavaEE has
undergone significant simplification (omakase API standards, anyone ;)) and if
you check out the work of Adam Bien, you'll quickly find old myths of bloated
memory consumption and fiddly XML configuration debunked.

Java is also lucky to have a parallel full-featured stack in the Spring
ecosystem. Projects like JHipster do an opinionated take on how to wire things
up and take you to quickly to orbit.

So basically, I disagree with DHH that there is "Very little activity in
integrated solutions."

~~~
dceddia
I took his comment about "very little activity in integrated solutions" to
mean "[in the JavaScript world]" but maybe that's not what he meant.

I do think that's pretty true of the JS ecosystem though. There are things
like Sails, but most of the "new" stuff that comes out is build systems,
tools, small libraries, and view libraries.

As to why... it's anyone's guess.

My guess is that making a full-stack opinionated framework like Rails is a big
undertaking, and most people are focused on what they see as "quick wins" \--
solutions to the obvious surface-level pains like "npm is slow" and "making
forms with React is hard" that can gain traction quickly and rise to stardom
on Github.

Maybe this is cynical to mention, but fame and recognition (and maybe
interesting job offers) seem to be a big driving force behind the constant
influx of new and better JS libraries/tools.

~~~
headcanon
> As to why... it's anyone's guess.

I think its because recreating rails in javascript just doesn't make sense in
the current ecosystem. Either you are rewriting stuff like express from
scratch (and why are you doing that?), or you're building on top of those
modules and adding configuration conventions and scripts, in which case,
congratulations, you've just written Sails.

When Rails first got started, ruby didn't have anything close to the ecosystem
that JS enjoys today, so DHH et al. had to write most of the individual
components themselves, with the intention of making them all work together.

So in my view, its similar to how Humans and Gorillas evolved from a common
ancestor, but you won't see Gorillas becoming Human anytime soon.

~~~
bigtunacan
Personally I think Sails is pretty cool in it's own right. As far as
websockets go I feel like that is one area where Sails makes things dead
simple and I've not been amazed by the overcomplicated Rails 5 implementation
of websockets.

That said, I don't see Sails gaining a ton of traction even though it's been
around for quite some time yet, and with it's security settings and beta
status I don't feel great about building production apps with it yet.

~~~
headcanon
I certainly like sails, and can't levy too much criticism against it (except
its ORM left quite a bit to be desired, although I haven't looked at it
recently). I'm only asserting that it will never be Rails, partially because
of how and when each respective framework came to be.

------
newsat13
So, I have seen rails code and I did not fall in love with the code. Instead
what I saw just black magic and all sorts of conventions. Reminded me of perl.
You have to invest a lot of time knowing all the magic stuff.

~~~
pmontra
There isn't much black magic. Most of it is pretty sane naming conventions
which could be OK in any sw project, plus database schema autodiscovery. The
bonus is increased maintainability.

~~~
cies
> The bonus is increased maintainability.

It will never have strong-typed discipline though... (sad)

~~~
pmontra
They are talking about adding some optional type inference in Ruby 3.0. See
the rejection comments of [https://bugs.ruby-
lang.org/issues/9999](https://bugs.ruby-lang.org/issues/9999) This is the most
stong typing I'll accept for Ruby. There are plenty of other languages if
strong typing is important for a project. They usually look bad (not because
of strong typing) but if one really needs them...

------
dharamgollapudi
Its DHH, not DDH. Mods, please update the title.

~~~
gavingmiller
corrected - thanks

------
cutler
Maybe a more relevant question is whether Rails is worth learning if you're
looking for a job. Searching Indeed.com's API by title, which removes
duplicates, there are currently 133 Rails jobs in the USA compared with 763
PHP (excl. WP, Drupal etc.) and 467 Node.js. In the UK there are 104 Rails
jobs compared with 1013 PHP (excl. WP, Drupal etc.) and 230 Node.js. However,
if you deleve deeper it turns out that half of the Rails jobs are in London.
Outside the capital there are 22 PHP jobs to every Rails job (35 including WP,
Drupal etc.) and 3 Node.js jobs to every Rails job so it would appear that
unless you have a particular preference for the Ruby language Rails is not a
good bet in today's job market.

~~~
appleiigs
So you are saying that PHP is worth learning in 2017? I think it goes beyond
job posting counts.

~~~
cutler
Have you looked at Laravel recently? With Vue.js integrated into the framework
and adopting the best bits of Rails I'd say it's looking in better shape than
Rails right now.

------
elcapitan
Rails has become so much more enjoyable since all the hipsters left for
node.js. [What makes Rails a framwork worth learning in 2017]

------
mountaineer
DHH also answers a few other questions about Ruby and Rails in the same Q&A

[https://www.quora.com/session/David-Heinemeier-
Hansson/1?sri...](https://www.quora.com/session/David-Heinemeier-
Hansson/1?srid=pvwn&amp;share=1)

------
mark_l_watson
I have been thinking of rails lately. I used both Rails and Merb way back
when, but for many years now I have just used Ruby + Sinatra.

I wish that I had a more complex web app to do because it would be fun to get
reacquainted with Rails. That probably won't happen since I have been going it
the opposite direction, having updated a few Sinatra and PHP sites to be 100%
static, and using cloud storage and CDNs.

~~~
cyberferret
If you are familiar with Sinatra, have you checked our Padrino [0] ?? Padrino
gives you a lot of the Rails goodies without too much bulk added.

I've developed and deployed several 'real world' web apps in Padrino now. I
looked at Rails in the early days, but for some reason could never really get
to grips with it (probably because it was _too_ opinionated for me).
Sinatra/Padrino's DSL methodology seemed to sit better with me, and I ran with
it.

[0] - [http://www.padrinorb.com](http://www.padrinorb.com)

------
horsecaptin
Ember.js attempts to do what the front-end what Rails has done for server-side
application development. Worth a look, if you're trying to choose between
React / Angular / something else.

------
Glyptodon
The only thing I'd really take much issue with is the "provides great
defaults" statement made in passing. There are several things that are
defaulted more to what I'd call "lowest common denominator" than "great." For
example, sessions.

~~~
patsplat
This a great point that gets to the heart of the problem with the premise of a
full-stack framework. Defaults end up more "good enough" rather than "great"

~~~
Daishiman
But a collection of consistently good enough components is better than tying
together two dozen different things of wildly different quality and
conventions.

I hear this a lot about Django. The ORM is really good but "not as good as
SQLAlchemy". The templates are great but "Jinja is better".

The thing is that as an engineer I value that the components are incremental
improvements with sane defaults where change is deliberate and the benefits of
what I'm missing out on are truly, honestly irrelevant. There's really very
few times where I said to myself, "Oh of only my templating language had
better support for these idioms". I just write a decent workaround because
I've been using the same tool for years and it's maintainable and the total
number of workarounds is so small that there are no good reasons to switch to
an alternative even in the long term.

This is much better than the alternative of looking for 5 alternatives for the
same component, discarding the first 3, using one for a month until I find it
has fatal flaws, and finally settling for the last one.

~~~
patsplat
Once one critical component in the framework is no longer good enough it can
be very difficult to upgrade.

Frameworks aggregate many dependencies. Managing the dependencies that deliver
value while ignoring those that are irrelevant can net out as more productive.

------
hhandoko
> You get to use Ruby, which [...] remains the most extraordinarily beautiful
> and luxurious language I’ve yet to encounter.

I've used Ruby sporadically as gap-fill in small projects, but I didn't feel
the language has any qualities that sets it apart from others.

Perhaps I missed something, any Ruby devs care to comment?

~~~
mavelikara
This article might be helpful:
[https://martinfowler.com/bliki/HumaneInterface.html](https://martinfowler.com/bliki/HumaneInterface.html).
I use Ruby occasionally only, but agree with DHH's point. At least compared to
the languages I knew before I learned Ruby, I found it to be designed to be
aesthetically pleasing to humans. This might be even be the cause for the
parse ambiguities.

~~~
hhandoko
Thanks! I agree Ruby looks to be far user-friendly in this context.

Just to add, my work revolves around the JVM ecosystem, but mostly in Scala
and some Kotlin... Both already provide a nicer interface for Java :) e.g. in
the context of collections both have `list.head` or `list.first` and
`list.last`.

------
patsplat
Each user today commands a personal fleet of many devices. "You get to use
Ruby" is a weak justification for a monolithic architecture.

~~~
GavinMcG
Sorry, but I've really got no idea what you're saying here. What's the
connection between users having many devices and the monolithic architecture
bit?

~~~
patsplat
There was a moment in web development where a single "full-stack framework"
was possible, that moment has passed, and that moment was more rare and unique
than it seemed at the time. The future seems to be more about lambda
functions[1], api gateways, and many native clients.

Quoting DHH, the Rails pitch was use Ruby for everything:

> The core premise of Rails remains in many ways as controversial today as it
> was when it premiered. That by formalizing conventions, eliminating
> valueless choices, and offering a full-stack framework that provides great
> defaults for anyone who wants to create a complete application, we can make
> dramatic strides of productivity.

That premise is irrelevant today. A complete application today isn't just a
website. It's a website, a phone app, a car app, a TV, a kiosk, a
conversational bot, etc. Choosing even the highest common denominator across
all those platforms means eliminating unique opportunities to delight the
user.

If now the premise of Rails is that it's a great way to generate JSON on the
server, sure but that's a fraction of the stack. The selling point for Rails
is now simply an aesthetic choice between Javascript and Ruby. DHH admits as
much with his closing argument:

> Just look at some code. I dare you not to fall in love.

Since the core premise of Rails remains full-stack, plugins at best are a
cycle behind innovation. Conventions have to be explored elsewhere before they
can be formalized, and before choices can be exposed as valueless. At worse,
plugins are multiple cycles behind innovation due to pointless infighting.

This just seems way too slow, I'd rather get my hands dirty today.

[1] or process containers, let's not get bogged down in vendor details.

~~~
GavinMcG
Your first quotation is something you're seriously misreading, I think. It's
not about using Ruby for everything. It's about not spending time on minor
decisions that don't affect the outcomes you're pursuing. And that's what that
quote says – nothing about Ruby; everything about pruning down the pointless
decisions you need to make as a developer.

> A complete application today isn't just a website. It's a website, a phone
> app, a car app, a TV, a kiosk, a conversational bot, etc.

I disagree pretty strongly with that. A complete application can be any one of
those things. Sure, if you have a need for all of those at once, then Rails
isn't going to be your one and only tool. But it could still well be the tool
for your complete web application, and at the same time your API server for
(some/all) of the other tools.

> DHH admits as much with his closing argument

No, he says that Ruby's beauty is an _additional_ reason to use it. It's
hardly an admission that it's all that differentiates Rails from other
options.

------
spoiledtechie
This answer sounds a lot like what Microsoft's answer to Java was. C#.
Everything in this answer reminded me of c#.

------
rco8786
What does Ruby have to do with immutability

~~~
wrsh07
Let's consider the quote:

> You get to use Ruby, which, even in a world that has rediscovered the
> benefits of functional programming and immutability, remains the most
> extraordinarily beautiful and luxurious language I’ve yet to encounter.

He's saying there are other beautiful paradigms - especially of the FP
variety. However, Ruby is really, really damn elegant.

And he's right; it's a joy. [I say as a C++ dev]

------
blueside
I think Rails is always worth learning, but is it worth learning right now if
you want to find a job?

------
ahallock
Here's a reason: money. Rails is still very popular, so there's plenty of work
out there.

~~~
cutler
See my top-level comment about this. Rails' presence in the job market is
definitely declining and dwarfed by both PHP and Node.js.

------
holydude
What stack do you recommend if not rails for a person that dislikes JavaScript
(well rather ecosystem than the language / syntax itself) ? I love Rails and
Ruby do not take me wrong but I am not sure if the sole existence of Rails can
make Ruby relevant in 2017.

In terms of jobs prospects and similarity to Rails/Ruby what do you guys
recommend ? Java ?

------
vcryan
It's always important to study history :)

~~~
GavinMcG
Snarky, low-content comments really aren't valued highly here.

------
0xsnowcrash
Rails, as any backend system such as Drupal or Symfony, is inevitably a dead
end technology.

The web is increasingly moving frontend and the system of 2018 onwards will
simply be the M in MVC.

Note, I'm not saying Rails is not worth learning. I'm just saying it's now the
Cobol of web technology.

~~~
pyrophane
If I read your comment correctly, I believe you are suggesting that backends
will provide APIs, which would leave us with the MC in MVC, the controller is
still needed to map data structures to API endpoints.

My question to you is this: why do you believe that? I think we have all
witnessed a growth in popularity in front-end MVC frameworks, but are they the
correct solution to all problems?

~~~
whyileft
_> the controller is still needed to map data structures to API endpoints._

I mean, kind of. You don't really need much controller logic most of the time
anymore. Last Rails backend I wrote probably involved personally writing a few
lines of code here and there. Generally, I'm just pushing a JSON object back
and forth. Auth and emails can just be 3rd party. The vast majority of
controller type behavior ends up client side at this point. Partly, because
its way simpler to scale with you push as much processing to the client as you
can. Also, look at something like Firebase or Hoodie as examples of simple
stores that require no backend logic.

Its not that Rails and Symfony are useless, I use them all the time, its just
that they are kind of dated concepts. Heck even Wordpress solves a specific
problem on the backend enough to be useful sometimes. That said Drupal at this
point is such a dated concept(superseded by things like Rails and Symfony many
years ago) that is should no longer be used.

~~~
cutler
Well, I don't think anyone's taking much notice of that advice if you go by
job stats. Drupal is enjoying tremendous adoption and if you look at Drupal 8
code you'll discover it is built on Symfony components.

