
After reading “Rails is yesterday’s software”, I need to reply - D_Guidi
http://www.codethinked.com/it-takes-all-kinds
======
danenania
Moving on from Rails sounds great until you try to build a serious web app
with one of the alternatives. While I think that many of the architectural
criticisms are valid, Rails demonstrates the primacy of ecosystem and strong
conventions over language design and cs theory.

'Tomorrow's' languages and frameworks would do well to take heed. Winning this
war has as much to do with culture and marketing as algorithms and data
structures.

Clojure, for example, is a much stronger programming language than Ruby on
paper, but for a straightforward web app, you'll likely spend _at least_ twice
as long to get something working--and while it will be based on better
engineering principles, it will also take new engineers much longer to grok
since it doesn't follow any universal set of conventions.

With Rails, you end up in the weeds in the long run, but the alternatives put
you in the weeds right off the bat (with the promise of eventual salvation).
The reality of most product development (ymmv) is that the former is highly
preferable to the latter.

~~~
busterarm
It's all about how you prioritize the problems you need to solve.

At my current job we primarily use Wordpress. Why Wordpress? Because we have a
large and non-technical content team, 260+ websites and several tens of
thousands of pages of content that need to go up quickly.

We're just 4 developers - about 1 for every 8 content & marketing people we
have. We spend very little of our time on frontend. Tell me that you're going
to get that kind of leverage with another tool.

Wordpress is just about the last thing that you would pick as a developer or
ops person to base your tech stack, but in our case it is the right choice.

Aside: Coming from Rails and having spent six months deep in Wordpress core,
it's actually kind of awesome. Seemingly every problem is solvable.

~~~
askyourmother
WordPress is a pretty crazy codebase, yet, it seems sane compared to Rails.
Interesting that WordPress as a service are moving to a node.js backend from
PHP - even they chase shiny too

~~~
btdiehr
Is it not an advantage for average users to be able to do both the front end
and back end knowing only a single language?

~~~
askyourmother
The same advantage as just using a screwdriver to handle nails and screws? No.
Right tool on the server (hint: it's not JS nor node), right tool on the
client (JS if needs must)

------
blub
This is the old "use the right tool for the job" cop-out. The original post
went deeper than that. I would summarize it like this: can modern complex,
large-scale web apps be built with the tools we have today, be they Python,
Ruby or Javascript?

Or do we need an entire new class of tools which have traditionally been used
to build large scale systems in the past?

It's a multi-faceted question of type systems, tooling, packaging, dependency
resolution and others. And as web apps continue to evolve, my guess is that
the current tools will be considered lacking.

It used to be that picking "the right tool" meant choosing between Ruby,
Python, PHP, JS. In the future it might mean using (gulp) Java + WebAssembly
or a combination of other unusual tools. This would be quite game-changing for
most web developers. ;)

~~~
mbell
> The original post went deeper than that.

If there was depth, I missed it. The only two points I got from it were 'I
prefer static typing over duck typing' and 'avoid dependency hell'. The
original post didn't add anything new to either argument and both have existed
and been rehashed over and over again for decades.

~~~
collyw
And he didn't point out how any of his "todays languages" are any better at
avoiding dependency hell.

~~~
weberc2
Go statically compiles everything into a single binary. I'm not sure what is
meant by "dependency hell", but this at least simplifies the runtime story.

~~~
pdkl95
> simplifies the runtime

That has been a solved problem in ruby for a long time. Bundler[1] (or similar
tools) does the equivalent of static compilation by copying[2] all of the
dependencies into the project and statically loading[3] them.

[1] [http://bundler.io/rationale.html](http://bundler.io/rationale.html)

[2]
[http://bundler.io/v1.12/bundle_package.html](http://bundler.io/v1.12/bundle_package.html)

[3] [http://bundler.io/v1.12/man/bundle-
exec.1.html#ENVIRONMENT-M...](http://bundler.io/v1.12/man/bundle-
exec.1.html#ENVIRONMENT-MODIFICATIONS)

~~~
weberc2
I'm sure it helps, but you still have a runtime dependency on Ruby as well as
something to unbundle the bundle. Maybe this isn't a big deal, but it's not as
easy as a single static binary.

------
Benjamin_Dobell
Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x...
4.1.x -> 4.2.x

It was, and still is, a nightmare.

Technically speaking Rails itself upgraded in a reasonably straight-forward
way, just follow the documentation (well and a few blog posts here and there
for the things missed in the official docs). But all the additional Gems, and
dependencies of those Gems (and so on) made the process excruciating. Many
things broke in subtle ways at runtime (no compilation, so no compiler errors)
and there was no clear path to upgrade; because whilst Rails' upgrade path is
documented, there's a plethora of Gems that also needed to be upgraded
separately (some in contradictory manners).

You might wonder why I was so out of date in the first place. Two reasons:

1\. I inherited this code-base.

2\. I've attempted this (or a similar) upgrade about 5 other times in the
past; spending hours upon hours debugging crashes (or just weird behaviour)
with enormous stack-traces where my application's own code often doesn't even
appear in the stack trace. It's only now after making several failed (or
rather overly time consuming) attempts I was able to come up with a "workable"
upgrade path.

Gems dynamically generating methods left, right and centre, Gems replacing
methods of seemingly unrelated classes (when they definitely do _not_ need
to), and crazy "conventions" that hide all the actual logic make debugging any
sizeable Rails project a complete disaster. Don't even get me started on the
poor performance, much of which is to do with poorly designed Gems and not
even the Ruby interpreter's fault.

That said... I still turn to Rails when I want to get a new project (with
users, database, login, admin etc.) up and running quickly. It's a shame, but
in terms of development speed, it's hard to beat Ruby (and Rails). For small
projects Sinatra is very solid, and Padrino is interesting - but honestly I
can't wait for the day I can move to a compiled language and still achieve
this sort of development speed.

~~~
manifestsilence
I've found upgrade hell can apply to C#/dotnet stuff too. I work on a project
that has attempted to upgrade Entity framework versions multiple times and
keeps pushing it off because we get buried in compile time errors. It's a case
where Microsoft supported several different paths to architect an app and then
quietly deprecated half of them - database first vs. code first, POCOs vs.
ObjectContext, etc. and we happened to be on the losing side of history.
Compile-time errors are definitely easier to find, but the path to fixing them
can be just as bad. What I really long for is good documentation and a clear
path forward for each breaking change.

~~~
ktRolster
Indeed, Microsoft's lack of commitment to APIs is what inspired Joel's famous
essay:
[http://www.joelonsoftware.com/articles/APIWar.html](http://www.joelonsoftware.com/articles/APIWar.html)

IMHO .net has lost some stability with the recent packaging systems like NuGet
and chocolatey; they don't really encourage stability.

------
cdnsteve
"makes it easy to install 1,000 gems into your project without a single line
of configuration, is exactly why it’s hard to debug".

This "let someone else do the work, get it from a gem" mindset is what kills
long lived projects. It has nothing to do with the tools and everything to do
with experience.

You don't need 1000 gems. Managing anything more than core dependancies in a
project can easily create exponential bugs and consume all your resources to
fix. Remember left-pad?

This is true in any language and ecosystem and has nothing to do with
rails/gems/ruby. The same is with Python, JS, PHP.

Senior/Lead devs need to carefully curate what a projects foundation _is_. A
strong, well designed foundation means you have something solid to build on.
If you don't understand what's in your deps, haven't read their code, see how
often it's updated and how many people _actively_ use it, and can say you are
using _80% or more of the code in it_ then don't use it.

Writing your own code is often the best route since it fixes your exact use
case, no matter the language, libraries or frameworks being used.

~~~
toolz
I work on some really big projects in the wild for various clients in ruby on
rails and they have so many gems that often I find unused gems they are afraid
to remove them in case it actually is being used, but you know what? They were
moving forward with features - their user base was happy and their product
worked for the most part.

You know what kinds of projects I see fail? The ones who try to architect
everything using a core set of libraries and build everything themselves. I've
seen hugely funded projects with years of development burn for that very
reason.

I know I'm just a single datapoint, but it's worth mentioning that there
exists projects that absolutely will do better in the long run with just
installing all the gems.

~~~
Xylakant
> often I find unused gems they are afraid to remove them in case it actually
> is being used,

I've worked on code-bases of small to medium size where people were afraid to
remove self-written code because nobody knew if the code is actually called
somewhere. It's not actually the gem that's the problem - it's being diligent.
If you need a gem's function add it as top level dependency, don't rely on
some other gem depending on it. require the code explicitly everywhere you use
it. That way you can at least search your code base for it. Be equally
diligent when removing code: Remove all code that only this code depended on.
Other than that: Don't be afraid to break stuff.

------
hashkb
Author is being nice, but I'm happy to point out that author of replied-to
post is revealing they are a frustrated novice. All the focus on "Rails made
programming cool" tells me "I do things for dumb reasons." Clear case of
chasing the dragon.

------
rco8786
Reposting a reply I put on the original submission, but pertinent here as
well:

Use whatever tools/framework you want. Whatever it is you use, you will
eventually become [the original] OP. The reality is that every
language/framework has warts. As you use it and get deeper into it, you will
uncover these warts. Eventually, all you can see is the warts.

It's important to take a minute every once in a while and look at the thing
you built from a user's perspective. See what problem you've solved for
people, or just what cool new thing you've built. Staring at a bug backlog and
a mountain of tech debt will always get you down about your project, but
that's the reality of programming...bugs and tech debt.

------
noamsml
I feel like this is a terribly lacking reply. I'm not a trend-person by any
mean: I'm a deep-backend developer, and my main language right now is Java[1].
However, when I have to maintain rails apps, even well-written ones, I find
myself frustrated. I think ceding the advantages of a compiler is a
fundamental mistake. Compilers and static checkers make for better software
more easily; they don't replace tests, but they complement them and constitute
compilable documentation for your code, enhancing its maintainability
considerably.

[1] I write in Java because I work for a Java shop, but even if I had my
choice of languages, I'd probably be using either Swift or a compile-to-JVM
language.

------
ryanmarsh
Many of the complaints against Rails in this HN discussion are around code
base maintainability, gem proliferation, and amateurs.

Any tool that allows the rapid (almost effortless) accretion of complexity
will suffer these problems. It goes with the territory.

~~~
wvenable
I think that's a good point. JavaScript with Node is arguably worse than Rails
for exactly that reason.

------
lr4444lr
The author leaves the business needs completely off the table, even though it
would help his case. If you have a limited amount of time to launch your
product in your current round of funding, and you want a framework that helps
a small number of tech employees build working first generation critical
features reasonably quickly, handle a large number of tasks not critical to
the company's value proposition reasonably well, can be maintained and scaled
on a variety of PaaS options well long enough until the company is profitable
enough to move to the next phase of tech infrastructure, is Rails attractive
software? I'm not an expert with it, and I don't even enjoy using it, but I
believe it is.

~~~
jetheredge
I considered speaking to that, but then I felt like I was delving into
religious arguments. My framework is more efficient than your framework! I
felt it would have drawn people away from my main point, which is to think
deeply about the tools you choose, and everyone needs different tools.

------
n0us
Some software does become "yesterday's software." I'm looking at you Cold
Fusion, Flash, COBOL, the Abacus. I don't think Rails belongs in this group. I
recognize that it's a good framework even if I don't personally like.

~~~
estrabd
Interesting comment; I believe if you are going to implicate Cold Fusion, you
also need to rope in PHP.

My first exposure to web programming was HTMLScript at my university in the
mid 90s (now called MivaScript and is the language used to build the
MivaMerchant product). Soon after, I switched to PHP 3, but I found that I
preferred Miva.

I have not touched Miva in years after spending some time as a freelancer in
the late 90s, but because it is tied to a successful niche e-commerce
platform, the language survives. It is very similar to Cold Fusion minus the
enterprise level database support.

I worked with CF for a time in the late 90s/00s (when it was still a product
of Allaire) along side of ASP (pre .net), and I actually preferred it to both
ASP and PHP - mainly because the mixing of mark up and DSL blocks seemed
really unscalable.

PHP may have been seen as an evolution in web programming since it abstracted
the mixing of logic and presentation a bit more than Miva or CF, but in
retrospect I believe PHP was not an improvement. It made general web
programming easier, but software maintenance is easier in languages like CF
and Miva that embrace embedded mark up/logic.

The frameworks provided by Ruby, Python, Perl, and even TCL (among others)
seem to have reached a point where only blurring the lines between client and
server seem like the only logical paradigm change - and that's not to say it's
an improvement.

~~~
jsmith0295
This isn't really the case. There are modern web frameworks for PHP --
[https://laravel.com/](https://laravel.com/) is the best example

~~~
tim333
Also PHP still powers much of the web and has taken a step forward with PHP 7
which seems to run a good bit faster than Ruby and the like.

~~~
discordance
Mostly because of one application (Wordpress).

~~~
spdionis
It runs a bit faster because of wordpress? :)

Assuming you were answering to your GP, modern PHP is a totally fine language
to program in with a lot of upsides (that would take too muh to enumerate
here).

------
mberning
I personally love ruby and rails and still find it to be extremely effective
and adaptable to most web development tasks.

As people flee the platform a huge amount of opportunities are going to open
up for that still enjoy the platform. I can't wait.

------
willvarfar
The problem I feel with Ruby and RoR apps is that people bang gems together
without knowing how those gems do what they promise to do, what those gems
depend upon, what those gems monkey patch, what they _change_.

Further down the road, maintenance drowns you.

I've rallied against this mindset before, e.g. regards security
[http://williamedwardscoder.tumblr.com/post/43394068341/rubys...](http://williamedwardscoder.tumblr.com/post/43394068341/rubys-
principle-of-too-much-power)

I find large Python apps fairly unmaintainable too, but to a much lesser
degree.

------
dschiptsov
There is, perhaps, a law, such that any project with a strong tendency to pile
up more crap instead of reducing it to "just right, when nothing else could be
removed" (a-la 9P2000 protocol, and few foundation libs of Plan9) will end up
in a J2EE-like pile of collective stupidity.

At least, everything in nature tends to get reduced to a local optimum by a
straightforward optimization process of trial and error. There is no way to
make a reliable and efficient complex system by piling up more and more crap.

And, funny enough, JavaScript will be even worse - it already makes J2EE look
not that bad.)

~~~
TheOtherHobbes
This should be studied in comp sci. Instead of building compilers and
interpreters in the abstract, there should be a serious study of how
languages/frameworks are created and developed in the wild.

I suspect there are easily visible patterns and trends, and they tend to
repeat over and over.

The corollary is that specific languages can't fix cultural issues unless
they're designed to do that.

------
carsongross
I've got my problems with Rails: routing is overly complicated, the asset
pipeline can be tricky, and so on.

But Rails is very good at producing HTML and, in particular, partial chunks of
HTML. As the current thick-clients-in-javascript trend cools off (it's
happening, this was at the top of /r/webdev yesterday:
[https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_p...](https://www.reddit.com/r/webdev/comments/4iphv4/12_year_of_progress/))
people are going to migrate back to HTML as a transport for web apps, using
libraries like [http://intercoolerjs.org](http://intercoolerjs.org).
(Disclosure: I developed it)

Rails is well positioned for that.

~~~
VeejayRampay
The assets pipeline can be tricky, sure, but it's tackling an issue that is
really hard to get right. Routing in Rails on the other hand, I don't really
see what's so complicated about it. You define resources, you have namespaces,
constraints, the DSL is extremely nice and straightforward, I think it's
actually one of the huge successes of Rails as a framework.

~~~
carsongross
IMO the asset pipeline is not worth the complexity. CDNs + caching do a good
enough job of getting stuff to clients, so the complexity (and distinction
between dev mode and production mode) isn't worth it.

My problem with routing is that the default is an implicit semi-REST pattern,
and that routing a lot of verbs to the same controller method is tedious. I
prefer Sinatra's "ground up" model instead, although you can certainly write a
rails router that way (and sinatra has the same verb problem.)

But I concede that's a matter of taste.

------
0xfaded
Dynamic languages reduce the formal overhead required to develop new ideas.

I can't imagine that an "eliminate boilerplate via convention at the cost of
explicitness" mentality would have evolved independently in a world where
assurances are earned by proving extra properties to the compiler.

However mordern compiled languages now formalise the shortcuts afforded by
dynamic languages, e.g. type inference, generics, implicit conversions,
typesafe macros, type classes, etc.

Similarily conventions popularised by rails-esqe frameworks are being
formalised using the tools listed above.

I fall into the scala camp, but have used rails at a previous job. My guess is
I need 1.5x scala lines vs Ruby which I believe is a justified cost. Opinions
of course vary.

------
brightball
At the moment, the alternatives mentioned to Rails aren't actually
alternatives. You are still going to make major trade offs in productivity
compared to Rails...

Unless he's talking about Elixir and Phoenix, which IMHO is the future of web
development.

~~~
DevinTheDude
As someone who has never heard of Elixir/Phoenix, why do you think it's the
future. What does it do better than Rails? I'm looking to start a new web
application, and I'm open to new technologies.

~~~
brightball
Elixir is a nicer to work with language that Erlang that compiles down to the
Erlang VM. That gives it a better concurrency model and fault tolerance than
Go.

Rails core team members have been building Phoenix. It's syntax is built to be
extremely familiar to Rails but it's been built from the ground up to correct
a lot of core issues that come up long term with Rails. It's basically fast
Rails.

You get a very equivalent level of productivity with performance and fault
tolerance of Erlang. Benchmarks show performance on par with Go.

It's really fascinating. I've been programming professionally for about 17
years now and it's the first time I've been truly excited about a language for
a long time.

~~~
DevinTheDude
First, thanks for taking the time to answer my question, I'm at my day job (I
program at night) so I can't do much research

>correct a lot of core issues that come up long term with Rails.

I've never gotten to this point, what are some of these issues? From reading
comments here, it seems like dependency hell could be one, but what do you
think? I've had issues in my short time with outdated gems, but I don't know
if this is necessarily an issue with the framework/language.

~~~
brightball
Dependency hell is s big one.

Monolith syndrome is another and one of the huge perks of Elixir is that it
forces you to build in a way that makes separating out parts later on much
simpler.

Performance is "the" major one because it's one of those things that you just
can't overcome easily with Ruby. Usually that leads long term to refactoring a
part of your system in another language like Go just for performance sake.

The routing layer is one of the biggest issues that is incredibly difficult to
solve in non-compiled languages.

People are familiar with callback hell in JavaScript but the same thing
happens overtime from using all of those before/after callbacks, nesting from
inheritance, etc.

Rack middleware is great until you only want it on some of your requests. At
that point things end up in a top level controller that other controllers are
inheriting from which forces those parts to get hit after the router. Phoenix
has something called pipelines that basically lets you define your middleware
stack for sets of routes or even based on request matching like "accepts json"
vs "accepts html".

ActionCable has just been added to handle websockets but whether or not they
will actually scale remains to be seen. Phoenix has been built for it from the
ground up and it's very impressive. You can find the 2 million websockets on a
single server benchmark with some Googling.

RAM and CPU usage is better. Concurrent processes have built in supervisors
that know how to restart them on failures and know how to drop associated
concurrent jobs as well. It's as easy as Go routines but with fault tolerance.

Erlang eco system libraries are usable and bring a lot to the table so it's
not like starting from nothing. The "awesome-elixir" page on github is a great
reference.

It's functional programming with immutable data structures which forces you to
think about problems a bit differently, but also ensures a better concurrency
model since there is no such think as a mutex lock.

The built in hot code deploys from Erlang gives you zero downtime deploys on a
single machine. Although I haven't yet tried this, people have suggested that
this means you could deploy to with millions of connected websockets without
breaking the connections (in the same way that Erlang was built to do this
with phone systems without dropping calls).

It's a little bit mind blowing and as you can probably tell, I'm excited. ;)

~~~
DevinTheDude
Thanks a lot. I'm going to research this once I get home. You may have just
saved my future project time/money.

------
padseeker
I have to say I'm loving reading the thoughtful and insightful comments on
this thread.

With any programming language and/or framework you have to pick your poison.
Rails backloads a lot of big development obstacles that ultimately you may
never actually encounter in the life of your app. The issue regarding gems can
be aggravating. But the speed in which you can get your app built cannot be
understated. Rails is not a one size fits all, and you might eventually
outgrow rails (i.e. Twitter). Be grateful the framework got you to the point
you could outgrow it, rails helped you get there.

------
mpdehaan2
In the original article, he indicates Swift, Rust, and Go are tomorrow's
languages. The issue really is that the level of support in the various
frameworks, the eons of bug-crushing and feature additions, and the libraries
available, are going to be behind for some time. This is why I'd still gladly
pick Django today.

What is "the future" isn't really so interesting as what is productive.

Yes, performance matters a bit, but development time is usually much more
expensive than adding a few nodes to an autoscaling group, and not worth the
cost of using less fleshed out libraries.

~~~
weberc2
In my experience as a professional Python dev and a hobbyist Gopher, Go's
libraries are a lot less convoluted than Python libraries. In Python, you see
a lot of libs that try to do everything for everyone (think long args lists
and functions that try to guess the right thing to do based on arg types)
whereas Go libraries just kind of snap together neatly. Go tends to be more
productive for me than Python specifically because its philosophy values
simplicity and orthogonality over complexity and scope breadth.

> Yes, performance matters a bit, but development time is usually much more
> expensive than adding a few nodes to an autoscaling group, and not worth the
> cost of using less fleshed out libraries.

Sequentially, Go outperforms Python and other interpreted languages by a wide
margin (usually a factor of 10). Things get really interesting with Go because
it can be massively concurrent without messing around with large async
refactors. At work, we're hoping our first iteration (i.e., before any async
refactors) of our Python application to handle something like 5-10 concurrent
requests per machine (without degrading response times), but I'm confident a
single Go process could handle at least 10X that load with better response
times. This order-of-magnitude difference seems fundamentally different from
the perspective of "throwing hardware at the problem". Further, Go's library
story is fairly complete (for web services; GUIs and other domains are still
lacking)--at least it's been a long while since I've lacked a complete library
for some task.

~~~
mpdehaan2
Again, performance isn't everything.

Go has specialized a bit towards low-level operations, and I tend to strongly
dislike what it does with exceptions and the way those involved veto language
features.

As for libraries, I'm talking about things on the level of, say, Django or
ORMs.

~~~
weberc2
I don't disagree that there are other criteria besides performance, only that
Go services will likely cost an order of magnitude less than Python services,
and the development velocity is pretty much on par (and much better for
concurrent tasks, since Go is much more expressive here).

Go is heavily optimized toward performance and rapid development. Go also
takes a hard philosophical bent against redundant features, like exceptions,
under the "less is more" and "simple is better than complex" axioms; it's
actually the same philosophy that Python's zen espouses, except Go actually
adheres to it.

Regarding libraries, there are numerous web frameworks and several ORMs. I'm
unfamiliar with Django, but I will say that Go's standard HTTP library is a
tremendous improvement over Flask. Also, I've not yet found an ORM that saves
time or trouble over hand-coding SQL (in particular, SQLAlchemy is a real
bear).

------
aeze
Fully agree with the post. Any time you're making decisions based on some
dogma versus 'what is the best way to solve my current problem' you aren't
guaranteeing an optimal solution.

~~~
pwthornton
Depending on the project, I think you have to give weight to long-term
maintenance and on going development as well. If you're building SASS software
that people use daily and may be in the market place for a long time, you'll
need to balance both solving today's problems with being able to meet the
future.

It's possible in this scenario, going with a proven solution like Rails me be
it. I just wanted to point out that our solutions sometimes have to consider
future considerations as well or have to consider continual development of a
legacy product. Sometimes developers consider only whats best in the moment,
and that has negative long-term consequences.

~~~
aeze
Definitely!

------
qaq
The thing is in many cases you had to make a choice between performance and
productivity. With things like Elixir/Phoenix you don't really have to make
that choice. Maturity argument again is moot as you are building on top of
Erlang/BEAM that's very mature and has very good tooling. For people coming
from Ruby the syntax also makes transitioning less of a pain.

------
janvdberg
In the comments of that HN post this link was posted which I found highly
informative regarding the matter:
[https://speakerdeck.com/tehviking/surviving-the-framework-
hy...](https://speakerdeck.com/tehviking/surviving-the-framework-hype-cycle)

------
zacharypinter
It seems to me that a version of the Innovator's Dilemma might apply to
software frameworks as well.

By the time a project gets large enough it starts optimizing for its major
stakeholders. New use cases or new ways of rethinking common use cases come
along, and the small libraries that approach it from scratch have a narrowly-
defined advantage. If the advantage is significant enough (e. g. virtual dom
for browser UI), then new frameworks start being written around them, bringing
back some but not all of the features of the older frameworks.

At some point (different for each user/use case) the newer frameworks have
enough functionality that people start considering them over the older ones
for new projects. When enough of that happens, the older frameworks start
looking like yesterday's software.

------
lo_fye
PHP is the day before yesterday's software, but it still gets a shitload of
profitable work done.

------
agmcleod
I agree with this quite a bit. Even in my own projects, I love using Rails for
web stuff, but I would never use Ruby for games. It's a pain to distribute
working binaries, and really is not an ideal language for games.

------
shams93
I've seen the biggest benefit from a client heavy approach even with rails.
Make the api the core of your system, makes it easier to refactor down the
road into microservices. For a lot of web apps there is no real need for
server side templating, once you get beyond server templating its easier to
make native versions of your app or use xamarian to access the same api from a
common c# codebase for native. Place your business logic in the api and
there's really nothing for someone to steal from view source because your
clients are just REST wrappers.

------
ksec
Sometimes I wonder if Ruby and Rails is 5x faster then now by default and
allow really simple scaling without much thoughts, would it still get so much
critics?

Most of the time People will answer saying moving away from Rails as you scale
is a good problem to have. But the day Rails isn't fast enough or scale easy
enough is coming a lot quicker as the Internet Population expands.

And the good old saying of passing this to Morre's Law no longer works as we
haven't had much CPU improvement.

I am hoping JRuby with Graal and Truffle will fix that.

------
xaduha
Rails wasn't even the best choice when it appeared.

~~~
domador
What would you say was the best choice when Rails appeared?

Since then, has Rails been the best choice at any point, in your opinion?

------
methehack
Anyone finding any of this resonating really owes it to themselves to try
elixir / phoenix and, at the very least, keep an eye on it.

------
payne92
As more of the computational elements of UIs shift from server-side HTML to
client-side Javascript, server-side frameworks like Rails, Django, PHP, etc.
become less relevant.

Fast forwarding, many apps are (or will be) big JS blobs using
APIs/microservices back to the server. In that version of the future,
frameworks like Rails can get in the way more than they help.

------
vox_mollis
I've come to the conclusion that those who defend weak/dynamic type systems
and other unsafe toolchains simply buy into the fallacy of the uber-developer:
the belief that while other, lesser developers need static typing and
analysis, I'm so superior that _I_ will never introduce those class of bugs,
ever.

~~~
obstacle1
Could you point out where the author of this post even came close to
suggesting that Rails is for great developers who don't need static typing?

Or did you accidentally post this unrelated opinion in the wrong thread?

~~~
vox_mollis
I'm responding to the article that the author linked to, which does mention
static typing. This comment is an attempt at a hypothesis for why some
developers dismiss the importance of such features/tools.

------
mmedley
It simply boils down to what you're most proficient with. Depending on the
problem, you're likely to encounter some technologies are better suited than
others. That to me is where you'll get the most bang for the buck, being able
to decide on the right tool for the problem.

------
k__
why do most people only see the extremes?

you don't have to use bleeding egde libs instead of rails...

hapi instead of koa

react instead of cycle

ember instead of react

etc...

~~~
piotrkubisa
Because we do love them, just like Vim vs Emacs, PHP vs Ruby, Go vs Elixir,
jQuery vs React... But there is always something what I personally find very
positive between all these differences. Please look at Windows and the Linux -
some years ago we got used to installing a dual-boot environments and now we
may experience Canonical's Ubuntu on Windows with real Bash.

------
troxwalt
Great follow up article. Choose the right tool for the job.

~~~
melling
"Choose the right tool for the job"

What exactly does that mean? It's a vague response that people have used for
years when they don't want to explain why they chose a particular tool. In my
experience, many developers take the path of least resistance and use what
they are comfortable with and that's why "it's the right tool for the job".

~~~
Karunamon
Sometimes that's exactly what it means. The reason you see frameworks like
Rails catching on, slow and bloated as it can be (and I say this as someone
that _loves_ the RoR ecosystem), is that developer time is generally more
expensive than CPU time.

~~~
lubonay
Couldn't agree more. Business (the people who pay us to code) generally
doesn't care about performance if it's "good enough to ship". Time to market,
on the other hand, is a matter of life and death.

~~~
jjnoakes
Life and death also hang on other factors that swing the argument in the other
direction, like can you scale quickly if you are the next big thing, are you
stable, is your uptime acceptable, are there huge security holes that can tear
your company to the ground over night...

Speaking in generalities isn't very useful.

Each project has to weigh the pros and cons of each decision. It's basic
engineering.

