
Rails has won: The Elephant in the Room - mjbellantoni
http://www.akitaonrails.com/2016/05/23/rails-has-won-the-elephant-in-the-room
======
putzdown
This article is a superb example of bad writing, of bad thinking. I have no
skin in the Ruby/Rails game. I'm not a web developer. But I'm interested in
the fates of languages and the merits of major approaches that define many
jobs and decide the employability of millions, so I read it. The problem is:
what in the world is he saying? What is his thesis, and what reason does he
give us for believing his thesis? His opening section summarizes as: "I
started to read a rant. It made me mad so I wrote a rant. Then I read the
whole thing and felt better, so I wrote this." Okay, now try to summarize the
second section. Something about Rails and Basecamp. Wordpress. Apple crushed
Adobe. Finally: "Then there is the issue that Ruby's future is now tightly
coupled with Rails." What issue? What is the point of all this? Sorry, OP,
this is bad writing. It's bad thinking. It's saying "stuff" without knowing
why.

My advice: if you have skin in this game and need to make real decisions about
what platform/language you use, find an article that reasons soundly about
what the questions are and convinces you of its answers. Don't listen to this
one. And if this quality of thinking is diagnostic of how Ruby/Rails
developers think generally... well I'm glad that's a game my skin is safe
from.

~~~
tboyd47
I found it pretty coherent, actually. The author is trying to reset our focus
from the technical details of how Rails works to the bigger picture of how the
market for web technology has evolved over time. All the more important for
those of us with "skin in the game," which I'm guessing means coders, because
we tend to be myopic about our little world of symbols and tools, and often
get caught clueless when the rug gets pulled out from under us by market
forces that are indifferent to which design patterns are objectively better
than others.

~~~
justinwr
I concur. Coming from São Paulo, Brazil, I thought Akita's post was well
written and derived out of positive, lightly spoken, opinion. Breath of fresh
air against the backdrop of hostile tech machoism.

------
bascule
I've been using Rails for a decade now, across many jobs, and one thing I've
experienced fairly consistently is the worst Ruby web apps I have ever dealt
with are the ones that _weren 't_ written in Rails.

I've both seen and spent a lot of time rewriting overgrown Sinatra
monstrosities with assorted non-AR ORMs. These apps were generally riddled
with XSS since they didn't handle escaping correctly, often had unmaintainable
code that sometimes was thousands of lines long crammed into a single file,
and lacking any sort of basic structuring principles mixed parameter handling
with business logic all over the place.

I've seen several attempts to "build a better Rails" that's "more OO", but
even frameworks that solve the problems I've just described in the previous
paragraph have one huge drawback: Rails is a lingua franca for web development
in Ruby, and whatever incremental gains you get from having a better framework
are heavily outweighed by the costs of making people learn a new framework-
per-project, the lack of features and documentation, and the lack of the
library ecosystem that surrounds Rails.

At points I've tried to keep three ORMs/DB libraries in my head at a time: AR,
DataMapper, and Sequel, which just left me wishing I was dealing with AR (the
devil you know...)

ORMs need massive feature sets to jam the proverbial square peg of relational
databases through the round hole of objects, and AR is the only one I've used
that's both expressive enough to cover all the cases I'm interested in and
mature enough to even have a story around database concurrency, even if most
Rails developers are getting database concurrency wrong with AR (e.g.
[http://www.bailis.org/papers/feral-
sigmod2015.pdf](http://www.bailis.org/papers/feral-sigmod2015.pdf) ) At least
AR has _any_ story around things like optimistic and pessimistic locking and
lets you build apps where you can read an object and persist your changes
without silently clobbering another requests's database writes with your
locally cached copy of stale data.

tl;dr: if you want to do web development but dislike Rails, your best bet is
probably to switch to a different programming language than Ruby.

~~~
busterarm
I used Sequel once on a major project and as nice as it was, there was major
pain. Pain I wouldn't have had with ActiveRecord.

I seriously would have gotten the job done in half the time, with less
problems had I just used Rails...and I've written my own ORMs before - I have
somewhat of a clue.

~~~
bdcravens
I'm having the opposite experience, but I think that's because I'm working on
a legacy database that really doesn't follow conventions. Even when overriding
defaults in AR, I still found myself trying to hammer what I was doing into a
AR-shaped block, whereas Sequel feels like it lets me craft a resultset as I
desire regardless of what I'm starting with. But like I said, it's a legacy
database and it was originally driving an app where writing raw SQL was the
SOP, some of which really leans of higher-level SQL engine features for
function and performance.

------
braythwayt
I recall a lot of articles like this about J2EE. And then a lot like this
about MSFT technologies.

There was an essay pg wrote where he said that Microsoft was Dead
([http://www.paulgraham.com/microsoft.html](http://www.paulgraham.com/microsoft.html)).
He didn’t mean dead as in “Dead," he meant dead as in “Nobody is afraid of
them any more,” and the generalization of that is that it was no longer
relevant.

I think Rails is there. I think Rails is dead. Obviously, not dead as in dead,
but dead as in, it is no longer revolutionizing anything. It is no longer
making new things possible. People no longer adopt it and discover a
productivity dividend they didn’t expect. It no longer swings business
decisions (“How can we get this done in three months? What about using Rails?
Let’s try it.”)

I think that’s fine. I can quote “A new perspective is worth 80 points of IQ.”
I don’t think that’s true of Rails today, but then again, I don’t think that’s
what people want from Rails. If people want 80 points of IQ, they’re off
looking at Elixir and Phoenix.

Likewise, I can say that “A language that doesn’t change the way you think
about programming isn’t worth learning,” but who is learning Ruby and Rails in
order to change the way they think about programming? They’re trying to bang
out CRUD apps, and they don’t want to think about programming, that’s why they
value a stable community with widely adopted “best practices.”

When you have a stable, mature language and framework, you spend more time
thinking about your business and less time thinking about programming.

And thus, Rails (and sorry, but Ruby too) is not for people who want 80 points
of IQ or to change the way they think about programming. And thus, in the
sense of being influential, in the sense of disrupting anything or changing
anything Rails is dead.

It has matured. It is mainstream. It is plumbing, it is concrete, it is rebar,
it is infrastructure. Necessary and useful. But not something you want to
spend a lot of time thinking about, just something you use if it suits your
purposes.

~~~
pjc50
_“A new perspective is worth 80 points of IQ.”_

That's not how IQ works. It's not additive.

~~~
braythwayt
The quote is from Dr. Alan Kay. I think he knew that when he said, it, and
personally I think IQ is a racist, bullshit metric. But the general idea of
the quote is still meaningful, and the thing I am saying when quoting it is
that having gone mainstream, adopting Rails is no longer about adopting a new
perspective.

It’s tautological: You don’t get a new perspective, or an advantage, by
adopting the mainstream thing and using it the mainstream way with the
mainstream best practices, carefully writing your code to be familiar to the
mainstream programmers.

That’s not a bad thing, but it is a different thing from when Rails was first
popping up in Reddit’s old days and HN’s early days.

------
holografix
Ruby was the number 1 reason why about 6 years ago, fresh out of uni with a
Java/C background, I chose to learn Python and Django.

Ruby seemed rather useless outside of Rails and I really, __really __liked
what I saw in the Zen of Python.

Ie. less magic, explicit > implicit. Etc.

~~~
gamesbrainiac
I have to agree here. Its a good thing that Django doesn't have the kind of
overwhelming power that Rails has in the community, which is pretty awesome!
There's a lot of diversity, like flask, pyramid and others; although Django
does have a large part of the pie.

~~~
dec0dedab0de
I think he was saying thay Django has a relatively small part in the overall
Python pie.

~~~
elbear
As in web development plays a small part in everything Python. Python's
scientific use comes to mind as a strong alternative.

------
rosalinekarr
Rails isn't the fastest or the smartest framework. It has weird choices,
confusing aspects and some downright terrible defaults, but for me at least,
it is the _best_ framework and it has been for years for one simple reason:
DOCUMENTATION!

Every few years or so, a bunch of these articles come out shouting from the
roof tops, "Rails is dead!" and "Long live Rails!" They often like to praise
some new framework, like Hanami, as the answer to all our woes, but they never
seem to address documentation.

In my opinion, documentation is where Rails blows every other framework away.
I have never been forced to read Rails' source code to understand how
something works (I have read some of the source, but for fun, not out of
need), and I can't say that about any of the other framework I've worked with.
There's always some obscure method or class somewhere in them that does
something unintuitive that I always have to look up. In Rails, finding the
documentation on that method is as simple as a Google search, but in django,
expressjs, or any of the others I've encountered, that documentation usually
doesn't even exist at all.

Efficiency, scalability and reliability are all great, but when I'm starting a
web app from scratch, they're really not that important. I can worry about
those things once I have funding. In the meantime, I only need them to be good
enough, and Rails defaults are usually good enough.

What I really need when I'm starting a new project and I'm working on a
shoestring budget, is speed. I need to build something fast so I can get
funded. Once I'm funded, then I can think about implementing JRuby or
splitting code out into microservices or rewriting with another framework, but
by then, I'll have the money to take my time. Until then, Rails is the perfect
framework for me and I'll keep using it until it's not.

~~~
brightball
Elixir and Phoenix is what you're looking for. Most of the goodness of Rails
for productivity, without the long term bad decisions that come with it to
force eventual rewrites when the funding comes. There's a reason Rails core
guys have put so much time into it.

It gets every...single...dang...decision...right. I may never use another
language unless forced because it's what I've spent years trying to find.

~~~
base
Why does someone come to promote Elixir and Phoenix in every Ruby/Rails
article? The first times was nice to see someone showing an alternative, now
is almost like SPAM.

~~~
sn1de
Because the Elixir/Phoenix community is largely spawned from the Ruby/Rails
community. They are more likely to be continuing to follow what is going on
with Rails, even living in both worlds. There are many shared values and
experience. That historical affinity is probably why it shows up so much in
the same context. The Elixir/Phoenix community is more likely to respect and
understand what Rails is and isn't as opposed to the vast majority of
pretenders who say they are creating a framework inspired by, or to rival
Rails, but really have no clue and proceed to put up something nowhere near
the breadth or depth of Rails. Nobody who knows anything is going to come and
put up an advocacy post for a PHP framework as an alternative to Rails. They
know the Rails community has no interest in going that way. Elixir/Phoenix on
the other hand can say with a straight face: we understand Rails and why it is
successful and put forward Elixir/Phoenix as a legitimate way forward for
those who want to move to a more functional paradigm and the inherent
scalability advantages of a Erlang/OTA based foundation.

------
izietto
Periodically raise up such articles à la "Rails is dead, long live the Rails".
Rails has won in the past because it was so more pragmatic than its
alternatives, and in the end better designed, and still wins now because it is
more mature than its recent better designed competitors (Phoenix, Hanami, ..),
and its community is so a big speed up now.

> People think that because something is "technically superior" everybody else
> should blindly adopt. But this is not how the market works.

This is really the citation describing the web development of the last 10-15
years. No surprise it comes from DHH.

------
Bahamut
"But I would never, ever, begin a new business that depends solely on Angular
to survive. Why? Because Google doesn't need it. It didn't blink to give up
GWT, it didn't have to think twice to decide to rewrite Angular 2 in an
incompatible way to Angular 1, and so on."

This is just wrong - almost 3/4 of Google's web apps depend on Angular from
what I have heard from multiple Googlers. If a rare instance where an Angular
release failure occurs, it shuts down Google's development process
dramatically & costs millions in productivity.

That rewrite is aimed at making Angular vastly improved - that doesn't equate
to giving up on Angular, that is a poor analogy. In fact, Google decided to
start investing vastly more resources into the Angular team, rapidly hiring
and growing the team into a proper one, as opposed to it being a pet project
of the Adwords team. In the next year or two, that ambition will bear much
more fruit as mindshare grows with the realization of the technical problems
solved & improved upon by ng2 - if React doesn't gear up to evolve, we'll
probably see either a lot of defection to Angular, or a competitor that
disagrees with the complexity that Angular introduces appearing to swallow
React, just as React has done the same to grab disenchanted
Backbone/Angular/etc. users.

Otherwise, the article does a good job explaining a lot of things, but it is
very defeatist, as if it is futile to try to improve upon things. I can't say
I agree with that sentiment, it goes against the heart of
research/trailblazing/experimentation/etc.

It also makes some weak assertions, such as "One rarely benefits from big bang
rewrites from scratch.", which is a generality being applied to every single
situation, a fallacy. Confusing commonly accepted wisdom in development with
an overextension of their meaning can lead to bad conclusions, as well as bad
decision making.

~~~
educar
> This is just wrong - almost 3/4 of Google's web apps depend on Angular from
> what I have heard from multiple Googlers. If a rare instance where an
> Angular release failure occurs, it shuts down Google's development process
> dramatically & costs millions in productivity.

So you were quick to call somebody wrong based on complete heresay? Do you
have any conclusive proof that they use it? Gmail? Analytics?

~~~
ben_jones
Literally 5 seconds of Googling [1]. Turns out the app that allows Google's Ad
customers (i.e. their main source of revenue) to use the Google platform is
written in angular. It's also one of the oldest and largest Angular apps in
existence.

[1]:
[https://www.youtube.com/watch?v=62RvRQuMVyg](https://www.youtube.com/watch?v=62RvRQuMVyg)

~~~
educar
I also found
[https://www.madewithangular.com/#/categories/google](https://www.madewithangular.com/#/categories/google).
It's a far far far cry from OPs original assertion that 3/4 apps in Google are
made of angular.

~~~
Bahamut
The Angular team has said over 70% of web apps at Google use Angular, but I
can't recall what talks they have said that at off the top of my head. Various
members of the Angular team have told me this directy as well, and are pretty
open about that fact in general.

One told me about the broken release at one point last year bringing Google to
a halt until that got fixed, since Google runs off of the master branch of
Angular. Google has a lot of apps, most of them internal (I have seen some
external ones too, such as a Nexus site in the past, and Google Domains.
Google App Engine and Adwords also use it, as given in talks in the past - the
Angular team is grouped under the Ads group within Google). Your original
question for proof was completely misguided when accounting for that -
examples of external facing apps does not confirm or deny percentage, it was a
poorly conceived attack.

Certain apps like Gmail/Inbox go through very long development cycles and have
specialized requirements. An Angular team member has explained to me that
sometimes some teams think they can do better with vanilla JS - none of the
popular web frameworks really met Google's perf/business requirements for
those behemoth apps, although with the way Angular 2 is shaping, it likely
will hit the bar (the Angular team has managed to get a hello world app
smaller than a react-based one, and this is before they extract out the
template compiler to allow tree shaking of that for builds - very impressive
perf numbers were also thrown at Google I/O last week). Google has a lot of
resources they can throw at big consumer facing apps, so they can build
homespun frameworks if they need to (for big sites like YouTube, Inbox,
Calendar, etc.).

I should also detail that I'm not someone unknowledgable about Angular and how
it is used - I am one of the biggest Angular experts outside of Google, a core
maintainer of one of the three most largest third party Angular libraries &
involved in another top three most used third party library (UI Bootstrap and
UI Router, respectively) and a contributor to many projects across the
ecosystem. I am very aware of all of the things that are Angular's strengths,
and its shortcomings (especially 1, and 2 to a lesser degree...but nobody is
really an expert at 2 yet, excepting maybe Tobias Bosch on the Angular 2 team
with his crazy work on it).

~~~
educar
@Bahamut, thanks for your perspective! fwiw, we are big angular users as well.
I was only questioning it's usage in Google. I think I now know that it's used
a lot more than I thought inside google.

------
aswanson
I never thought I'd hear myself say this, but the ASP.NET MVC/IDE is a better
ecosystem than Rails now. No more missing bundle x, install devkit x,....just
install visual studio 15 and get to work.

~~~
brianwawok
As long as you agree with the choices Microsoft makes. If you have a different
opinion? Too bad.

~~~
Touche
Same with RoR, no?

~~~
gnuvince
Relevant username.

------
fieryeagle
I suppose this is how you gain fame these days, writing sensational counter-
arguments instead of coding? Oh right, the author is a 'Ruby Activist', he
couldn't help it. PHP has won, Node has won and now yet another language up to
debate? Having something with its own niche and cult doesn't mean anything if
it's not suitable for work. It does help populate shortcut-seeking approaches
such as Heroku and more CRUD apps than ever before so Rails has its places.

Here's a piece to deflate any ego issues
[http://www.paulgraham.com/identity.html](http://www.paulgraham.com/identity.html).

~~~
Ace17
The article you linked is pure gold ;thanks for sharing!

~~~
fieryeagle
Yeah, such a poignant read that cuts to the heart of the problem - our needs
to associate and express.

------
tariqali34
> Experienced people often forget the learning curve when they were themselves
> beginners, and at that time Rails was so attractive, so sexy. Remember that
> feeling? Of accomplishment in the face of the knowledge that some nice witch
> left super useful black magic behind?

As one of those beginner programmers who had graduated from a development
bootcamp, I fell in love with Sinatra much more than I did with Rails. Part of
that love may be due to our curriculum...we have to master Sinatra first
before you can start learning Rails. But I also liked the finer control that
Sinatra provided to me. I suppose you can translate this to the current
buzzword jargon of "hating Rails' magic", but writing out simple
authentication using Bcrypt is just as much an accomplishment as using the
Devise library.

But your bigger point still remains intact. Passion should take a backseat
towards choosing the right tool for the job. If you need Wordpress, use
Wordpress. If you need Rails, use Rails. And so on and so forth. I may not
like a certain tool...in fact, I may hate it, but I should still go ahead and
use it anyway. You're here to complete a job. And you should make sure you do
it well.

~~~
ascendantlogic
I too like Sinatra but in my time writing Rails for both my day job(s) as well
as various consulting gigs, I inevitably see Sinatra apps that start out with
the best of intentions but always end up being just a shitty, hand-rolled
version of Rails.

~~~
wyaeld
The amount of time I hear - Rails, you ain't gonna need it, followed 6 months
later by some version of "can we use this library to add a feature which OOTB
Rails would have given us if we used it".

What is bloat, and what is a useful feature you haven't quite grown into yet,
is all a matter of perspective.

I haven't yet found a project where you know 100% of what you're going to need
upfront, so having a bit of depth in the toolbox is serving me well.

------
grandalf
Rails was most influential in Rails v1 and v2, and after that it pretty much
stagnated. In spite of that, millions of dollars have been spent upgrading
Rails apps through subsequent versions, millions spent on developer training,
etc.

Sinatra picked up the REST torch from Rails (and from Camping) and sparked a
significant change in how web apps are built and a cultural shift from
monolithic frameworks to micro-frameworks.

Node and Flask picked up from there, and gathered steam because both the
Python and Node dependency management systems are less broken than Rubygems,
allowing more practical use of smaller, orthogonal modules.

Now Elm and React are focused on improving the reliability and reducing the
incidental complexity of web applications.

Aside from the occasional PR stunt rant from 37 Signals, Rails does not really
have a thought leadership role in the development community anymore, aside
from a loyal following of career rails programmers, who likely adopted Rails
after v3 and would have been just as happy with nearly any monolithic
framework and authoritative pundit.

None of this is good or bad. Who knows what the future has in store. Rails pre
v3 inspired a lot of the thinking that came after, but has not really embraced
any of the ideas that emerged subsequently.

I think the best analogy is Windows. It's a cash cow, it's not going to change
quickly, and many people consider it the only sensible tool for the job.

------
kinkdr
Nice read. I understand the sentiment but I find the "win declaration" a bit
too weird.

How can one say "Rails won"? It's not like people will stop making web
frameworks. Like any other software it will eventually be made obsolete by
something newer and better.

Maybe I am just nitpicking.

~~~
vonklaus
Yeah, I found that weird. However, if I think deeply about it, given the move
to micro-services and soa type architectures I can see elixir winning longer
term which is really railsy. regardless, rails has a ton of influence and some
great usecases, but I would say nodejs is about as vogue as rails was and will
dominate for another several years.

as a nodejs dev, it is super annoying managing the asynchornicity of node and
the horrifying dependencies. I suppose rails had stability issues as well. If
you read rails is a ghetto by zed shaw, it is interesting (albeit super
biased) look at how and why rails developed.

edit: As noted, elixir isn't comparable to rails the framework in that arena
is phoenix which is similar (at least in function). Thanks!.

~~~
jghn
Elixir isn't comparable to rails, it's comparable to ruby. Phoenix is the
thing comparable to rails

Edit: I don't mean comparable as similar per se, but that one set are
languages and the other are web frameworks

------
bdcravens
These days, I'm finding a lot of joy in taking parts of a Rails app that feel
clunky (meaning they usually aren't Basecamp-like, and I find myself using a
lot of magic and config to make it fit a Rails-shaped hole), extracting it out
as a stand-alone Sinatra app that uses Sequel instead of ActiveRecord,
gemifying it, and then pulling it back into the parent monolith as an engine.

~~~
girishso
Wow! I didn't know Rails engines can be written in Sinatra/Sequel. Wondering
how that works exactly.

~~~
bdcravens
Wrap your app in a class (extending Sinatra::Application or Sinatra::Base),
require (I gemified it for componentization) then mount in routes:

    
    
        mount MySinatraApp => '/some_path'
    

(you can also mount it as rack app in config.ru, but not sure if you'd get
access to things like authenticated session, etc)

~~~
girishso
Cool. A quick search landed me on [https://robots.thoughtbot.com/how-to-share-
a-session-between...](https://robots.thoughtbot.com/how-to-share-a-session-
between-sinatra-and-rails) it discusses sharing session using config.ru.

Even after using rails for so many years, learning something new every day!

------
tboyd47
> The most important change of all: 2010 saw the advent of the Walled Garden
> App Store, commercially available native applications for smartphone and
> tablets. Forget web development: mobile was getting it all.

This is the real elephant in the room. Everyone is looking for the "next
Rails." There will be no "next Rails" because the web is not what it was when
Rails came out. It's not "dead" or "dying," but it is just not the same.

> Experienced people often forget the learning curve when they were themselves
> beginners, and at that time Rails was so attractive, so sexy.

I always like to say Rails is for those kids who used to read the players'
guides and instruction manuals for video games first, so they know all the
secret moves and bonus areas before they even start playing.

Some people prefer the challenge and power of discovering and designing things
on their own, and they are never going to enjoy Rails because they'll be too
caught up negotiating with themselves about how they would have done it.

------
jaequery
If we are talking about frameworks, I believe Padrino is a much better
designed framework than Rails. It doesn't have any magic of Rails and
architected in a very elegant way. I just can't tolerate ActiveRecord, so
Padrino having Sequel support out of the box was definitely an important step
in going away from Rails. Also being built on top of Sinatra, it is also much
lighter and faster than Rails, another huge reason to switch.

Yes Rails wins the popularity contest, but it doesn't mean it's the best thing
for Ruby.

------
websitescenes
I'd agree that the initial approach of Rails is becoming dated but Rails is
quickly moving away from this. Consider Rails 5. Native web sockets and an API
mode make Rails an excellent backend for JS apps. You fail to recognize the
evolution of the framework and where it continues to fit in today. If you're
done with Rails it's probably because you failed to evolve with the framework.

------
mcguire
" _Basecamp-like apps are not too difficult to make, at least in terms of
architecture. You don 't need fancy super performant languages with super
duper highly concurrent and parallel primitives. Also a reality is that 80% of
the web applications are Basecamp-like (disclosure: my feelings for years of
experience in consulting)._"

Someone once wrote something like, "An engineer is a person who can do for
$1.50 what any damn fool can do for $5.00."

I admit I don't actually have much experience with Rails itself; we had a
couple of Rails apps that, after a couple of months of painful deployment and
uptime teething, we moved to JRuby running on the same architecture as the
rest of our apps. Then, after a couple of years of deferred maintenance and no
updates (and a long list of security vulnerabilities) we rewrote them as
plain, no framework, no ORM, Java and Javascript.

But this quote rubs me the wrong way. Building small to medium web apps is
what we do. A lot. We ought to be able to build them cheaply and quickly. But
we also ought to be able to build them to be efficient and to not waste
resources unnecessarily.

In my experience, Rails succeeded because it's easy to go from nothing to a
demoable proof of concept. And the Rails environment succeeded because it's
possible to teach someone up from nothing to building a pretty application in
six weeks.

So why are we still fascinated with a tool that makes something easy that
wasn't hard to begin with? That makes the first 10% trivial while leaving the
other 90% alone, if not making it harder? That is optimized for the wrong
thing?

 _And_ it soaks up resources like crazy?

------
pcarolan
Watching the Google IO keynote, I couldn't help noticing that their new
instant apps could be accomplished in open webtools if they would have focused
on browser integrations rather than native apps. I hope this doesn't mean
native apps are shutting the door on the original idea of pure webapps (
remember that iPhone 1 keynote? ). I think it would take a major new platform
doing exclusive html5/css3/js first and only to shift the paradigm. Then,
follow that up with mobile browser improvements to make payments, contacts,
hardware integrations better and we'd be on our way. Anyone know of a good app
that is web only? Unfortunately, I think as native apps continue to dominate,
there will be less incentive to build out mobile browser integration with open
web platforms.

------
jrbapna
As a rails / startup guy, I can run circles around developers who are using
Node/Angular/React/etc. The huge open source community with the infinite
number of gems and massive volume of documentation accumulated over years is
unparalleled. Sure, Rails may eventually be eclipsed but I see no reason to
switch now when my immediate goal is to ship fast with intense speed and fast
iteration while focusing on the much more pressing business validation and
business objectives of my company. Just my two cents on the topic.

------
ninjakeyboard
Where there is a need for dynamic languages, Ruby can be a good fit. For
example, Ruby is used in devops world where there is a bit of a split between
Ruby and Python. It's very short sighted to think that Ruby has no future.

------
vonklaus
I haven't used rails in about 3 years (when I first started programming) and I
only built 1 application which was a super shitty weekend instagram clone that
didn't really work well. I didn't want to use rails anymore because it didn't
feel like programming and nodeJS was getting hot.

The thing is, I knew fuck all about programming then and now, I have the
luxury of knowing _very slightly_ less than fuck all. Which gives me the
perspective that this article has, rails is pretty fucking awesome for
building a crud application that uses a relational datastore. The author
indicated ~80%.

Wordpress is also something I swore off when I was learning because it
straight up wasn't programming. I installed wordpress on a server for the
first time last week to setup a blog. I browsed a few thousand themes, it took
me a while to find a theme for _a blog_. The _just a blogging platform_ is
actually more ironic now, than it ever was.

So, I agree with the author the design patterns shape the community and then
the community shapes the design patterns. You can pretty much build any type
of app with any language if you are motivated and talented, however, from my
observation, the following languages seem to give you the highest leverage in
the domains the community has evolved them for:

PHP/Wordpress: Blogging sites & CMS building.

Node/JS: Applications and APIs typically with a noSQL database.

Ruby/Rails: Building CRUD apps with relational datastores.

Python: Data intensive applications & programming.

erlang/elixir: Never used this, but seems ideal for highly scalable concurrent
architecture and highly scalable process choreography.

So in essence, I agree with the author. I would love to switch from node to
Rails as I like the framework aspect where you can just get productive super
quick. I also see rails as going away, so I wouldn't make the time investment.
I think learning node was the right thing to do ~3 years ago, but I wish I
spent another 6 months using rails and got really comfortable with it first.

> This is not serious programming/you aren't a serious programmer

fairplay. I am a jr. web developer, explaining my conception of some
frameworks/communities/languages, so I agree with you that I am not a
particularly talented programmer (it isn't my core skillset) and I am not
solving hard problems in this arena(as I don't conetend that I am). I disagree
that I claimed any of the above was my definition of serious programming. Of
the hard problems I will work on/what I think needs to be solved, I have
spoken of at length elsewhere.

~~~
davidpatrick
It sounds like you are just trying to justify your decision for Node. I use
Node and Rails in production for different products/services. They both serve
different purposes well.

"Going away" was said about .NET and PHP and they don't seem to be going
anywhere, albeit they are less popular than they use to be.

Too many discussions on HN have this paranoia lurking around of whether or not
"I chose the right path". I find it unhealthy, and find that the longer life
of a product exposes the weaknesses of any language/framework.

~~~
vonklaus
Again, I am not trying to justify my decision, I think if you asked most
developers to give advice to a kid learning programming 3 years ago how to get
started(with the benefit of 3 years glance into the future) they would
probably lean towards node if it was between nodejs v ruby.

However, I totally agree _that the longer life of a product exposes the
weaknesses of any language /framework._ and there are multiple paths. Just
that, if you want to get good at writing software you probably need to pick a
starter language with a versatile community. People still write cobol, and
wherever there is code in production, there will be demand for a language, but
.NET and PHP are probably not growing in demand. I actually don't know about
.NET tbh.

However, there is such thing as choosing a path as, without extensive time
investment, skill and knowledgebase, it would be difficult to be a truly
capable python, .NET, javascript and rails dev.

It would be wise to be capable in those languages, but to be a master or
attempt mastery of the one most likely to embody your interests/career would
likely be a better move than being able to be less than mediocre in numerous
languages. I think we are largely in agreement, and I hope I didn;t
mischarachterize you.

I think rails is cool, and I now regret not learning it as I do like the
scaffolding nature and I am sure I could pick it back up quickly, I just do
not have a need to right now. Elixir looks super cool though and if I do learn
a new language that is markedly different it is a toss up between Go and
Elixir. I am messing around with python right now, but javascript and ruby are
pretty similar, and pyton seems _fairly_ similar. A functional language or a
compiled language will be a radical departure from what I am used to.

~~~
pjmlp
.NET is alive and well.

Enterprise only cares about Java and .NET as standard backend stacks,
regardless of the technology of the day HN posts how everyone is doing Go and
node.js.

~~~
vonklaus
i actually have been interested in Java because apache has open sourced what
seems to be the best collection of resources on the internet and they are
almost entirely written in java for the java ecosystem. I also think I would
learn a massive amount. I also am strongly considering Java and less strongly
C. What are your thoughts on Java in terms of:

* How much it would teach me about programming/software design, e.g. just as a general learning excercise?

* What does Java lend itself best to/is a typical set of programs a beginner could build after say 1 month?

* Is google planning on phasing Java out and using Go?

~~~
reitanqild
1\. Java has had huge amounts of open source code for years. (Case in point:
course provider sales representative telling my colleague somewhat annoyed
that Java people are the worst because "they are used to get everything for
free.)

2\. Im going to read that as "... 1 month after finishing studies".

I will recommend starting somewhere where you get good colleagues. When I
finished school I was sure I could never work with Java: it was hard and
unforgiving compared to VB and PHP that I had picked up on my own.

After getting introduced to ides and working build systems however I was
starting to get work done within a week and within a year I was confident
enough to make a real difference.

Also I picked up a feel for just how annoying it is to be left with
maintaining code based on abandoned commercial tools (old Delphi code).

3\. No idea, but IMO no way banks are leaving it anytime soon so plenty of
jobs and momentum for the next few years:-)

~~~
vonklaus
I mean, could I teach myself Java and build something interesting in a month.
Sounds like a no?

~~~
reitanqild
Depends on you as well as your definition of interesting.

I'd say you should start in a good team anyway because real life experience
IMO is crucial and getting on a good team is a way of getting it fast and as
painless as possible (I.E. without breaking _your_ bank.)

If you just want to make "something" go with whatever is less friction for you
(for me it was php), just be prepared that there will be friction in any
language as soon as you step outside of the tutorials.

Also keep in mind that if you get a good job you can do quite a lot on your
spare time. I used to code a utility program in php while commuting. It never
became a commercial success but a rewritten version became a major hit with
the church I belong to, was maintained and in use for years and gave me both
experience in sw architecture as well as bragging rights in job interviews for
several years. (Oh and it totally helped in getting my head ready for my paid
work in the morning as well as unwinding after work.)

But I also think Java has come a far way towards beginner-friendly. If you do
just accept that in Java land IDEs are a must. Getting used to IDEs was were
Java "clicked" for me. Use either Netbeans (all features free, my preferred
choice), IntelliJ (lots of features free) or Eclipse (all features you'll ever
want is free but takes some getting used to, I would never picked it as my
first IDE if it wasn't the preferred choice on my first team and they where
happy to help me up to speed.) And dismiss everyone who tells you that one of
them is crap or way better: it is just a matter of preference in most cases.
(Notable exception: android development where IntelliJ is the officially
supported alternative.)

Also learn to use Maven or gradle.

------
glasz
> Rails can now be considered a "problem" for the very same reasons that made
> it popular in the first place. And this is bound to happen to any
> technology.

so, we won't be jobless anytime soon.

------
singularity2001
Why can't ruby?
[http://poignant.guide/book/chapter-7.html](http://poignant.guide/book/chapter-7.html)

------
jeffehobbs
There’s a lot of personification and anthropomorphism of technology in this
piece that distracts. Use the best tool for the job.

~~~
Jeff_Dickey
Agreed, but I'll just point out that works both ways. Devs "identify" with
their default tool of choice, and too many coulda-been-GREAT tools try to be
the Swiss Army Nuclear Ginsu Chainsaw of Code rather than the sweet hammer
they started out as. Sometimes this happens to dominant tools in a category
(such as Rails within Ruby); other times, it's happened to entire languages
(PHP, VB, and many others; I once had to maintain a terminal emulator written
in _COBOL_.)

As Larry Wall and countless others have noted, great programmers are
creatively lazy. Mediocre-to-average devs are lazy in less creative ways, like
sticking to one language/toolchain for years and not diversifying. Anything
that lives, including your career, either grows or it dies. Anything that
grows within an impenetrable walled garden will eventually crush itself to
death within those walls. It's sad when I see people do that to their careers,
and over nearly 40 years in this craft, I've had ringside seats to multiple
such bouts.

------
EpicEng
I'm sure I'm going to get piled on here, but whatever. I don't understand why
those who spend most of their time writing web apps / CRUD apps focus so much
on the tools they use to do it. "This framework's the best!" "No, this one is
obviously better!" "My design pattern is better than your design pattern!"

I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in
my area. I work at a lower level; robotics, image processing/analysis, and
general systems level stuff. We worry about what technologies we use for a
given task as far as it impacts our design goals, i.e., "which technology is
best suited for the job" (and there are more options nowadays than there used
to be). Our customers couldn't care less about how we got there as long as the
final product kicks ass.

Once we arrive at a conclusion we move on and spend the remaining 99% of
development solving actual problems. Hard problems. Often times unsolved
problems. Our number one priority is reliability and accuracy (ok, that's two
priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant.
What matters is that _we built a system which works as it is supposed to and
was engineered correctly._

I don't understand this 'programming for programming's sake' mentality. At the
end of the day these are just tools, not an end goal. Help me to understand.

~~~
jasonpeacock
FTFY: "I don't understand why those who spend most of their time __using
tools__ focus so much on the tools they use to do it."

It should be more self-evident now.

When there are many tools which meet the minimum requirements for doing a job,
then the focus becomes not on which tool can do the job, but which tool you
feel does the job the best (or you enjoy using). Carpenters argue about the
best saws/drills, artists argue about the best brushes/paints, musicians argue
about the best instrument maker.

You're right, customers don't care about what tool was used to build
something, but they care that you can do your job well and good tools help you
do that.

~~~
jeffdavis
"Carpenters argue about the best saws/drills, artists argue about the best
brushes/paints, musicians argue about the best instrument maker."

Is that actually true? I can't think of a single example of such an argument.
I have heard recommendations, and heard various trendy tools being promoted
(at least for music), but never an argument.

I think it has to do with transferability of skill. In music, carpentry, and
painting, skill readily transfers to different tools even if it causes
annoyance or a stylistic change in the result.

The stakes are much higher for web development; at least that's the
perception. Skills probably transfer better than people think, but it's scary
to have 10 years of experience and a high billing rate and then go back to
"hello world".

It's much more comfortable to try to promote what you already know so that you
don't have to do that. And it also avoids wasting time on a new framework that
seems promising but never gets critical mass.

~~~
mpeg
I've never had a problem moving to another language, I'll never understand why
people pigeonhole themselves into categories like "rails dev" or "java dev".

The fundamentals are transferable, I don't even mention specific technologies
or stacks these days if I don't have to.

~~~
dragonwriter
Well, two things. Lots of people are good on the mechanics of a particular
stack and weak on the fundamentals, making the description accurate.

And lots of people hire based on the assumption that expertise in a particular
stack is the most important thing (perhaps in part as a result of the
preceding point).

~~~
mpeg
Definitely, which is how you end up with half of NPM's package repository.

