
Today I accept that Rails is yesterday’s software - zimbu668
https://medium.com/@deathdisco/today-i-accept-that-rails-is-yesterday-s-software-b5af35c9af39#.q7gtv9q9v
======
calcsam
Being "yesterday's software" is a necessary step. It's the final part of the
Gartner hype cycle: maturity.

[https://speakerdeck.com/tehviking/surviving-the-framework-
hy...](https://speakerdeck.com/tehviking/surviving-the-framework-hype-cycle)

~~~
tra3
Here's the video:
[https://www.youtube.com/watch?v=0MojR1XUEc0](https://www.youtube.com/watch?v=0MojR1XUEc0)

As an aside, how do people consume slide decks? It doesn't seem as interesting
without the associated lecture...

~~~
mcknz
Decks are only consumable if they have:

    
    
       1. extensive speaker notes included as an addendum
    
       2. all of the content on the slides (which usually makes for a bad presentation)
    

Some presenters will have 2 versions of their decks -- one minimal version for
the presentation, and one extended or enhanced version for later reference.

~~~
brhays
I've been pestering the SpeakerDeck folks to allow me to paste in my notes,
even slide by slide. I have extensive notes but it makes for an ugly export.
It'd be awesome if I could tag it as metadata somehow.

------
rahimnathwani
The article seems to be lamenting three things:

1) Batteries-included web frameworks (like Rails and Django)

2) Interpreted languages without strict typing (like Ruby and Python)

3) Programmers relying on large numbers of dependencies (e.g. ruby gems), and
the resulting difficulty in reasoning about the software

The last paragraph then goes on to suggest that different languages are
required. This seems wrong. If you want to write web software you can reason
about, you can still use web frameworks (maybe Flask or Sinatra) and you can
still use third party packages (gems or things from pypi).

If you import a library (left pad or whatever) and call it from your code,
then you can still reason about what's going on. The problem comes when you
rely on adding packages that just talk directly to your framework (like Django
middleware). Once you do that a few times, you really don't know what's going
on between a web request hitting your server, and your own code running.

~~~
vosper
> The problem comes when you rely on adding packages that just talk directly
> to your framework (like Django middleware). Once you do that a few times,
> you really don't know what's going on between a web request hitting your
> server, and your own code running

I think this is where the lack of strict typing can make things harder to
figure out. Especially if you're trying to understand middleware functions
with opaque signatures (like __kwargs in Python). IDEs like PyCharm do their
best at providing "Find all references", "Go to defintion" etc, and that
helps, but it's not quite the same. Putting the info in the docstring is
better than nothing, but it's still harder to parse (and maybe not machine
parseable) and who knows if it's really correct?

Personally I'm really hoping mypy or type-hinting really takes off in Python
3, and makes everyone's life easier.

~~~
elcapitan
But is that really a problem of non-strict typing, or rather a problem of
metaprogramming? I could imagine even a very strongly typed system in Haskell
or Scala would probably be hard for an IDE to support if it uses a lot of
complex abstractions to create internal DSLs (like Rails and I guess Django as
well do).

~~~
vosper
I can't speak for Rails, but at least with Python (primarily Flask) it's not
internal DSLs that have caused me problems. I don't think Flask attempts to be
a DSL at all, actually. From what little I've seen of Django it isn't trying
to be a DSL either (unless I'm misunderstanding that term). It's more when I
have 2 or 3 Flask libraries or middleware and they each are documented as if
they exist in a vacuum but I want to use them all together and I wish it was
easier to see that all 3 have functions that take a Flask Blueprint object, so
they're probably all related, or that these functions work with URL objects,
etc...

It's a general complaint about Python and the tooling I suppose, not specific
to web application frameworks.

~~~
crdoconnor
>From what little I've seen of Django it isn't trying to be a DSL either
(unless I'm misunderstanding that term).

Django bundles two DSLs - the ORM (filter, etc.) and the templating language.

>I don't think Flask attempts to be a DSL at all

Flask bundles jinja2 and sqlalchemy which perform the same purpose.

~~~
vosper
Thanks, now I have a better idea of what constitutes a DSL. It had occurred to
me that the ORM might be one, but I forgot about Jinja2 which clearly is.

Though, being pedantic, Flask doesn't bundle SQLAlchemy (though it's what you
end up using) unless things have changed recently.

------
icpmacdo
I am thinking about completely stopping reading Hacker News. I enjoy the
community a lot but every time I am learning something new I read about how
its old and shitty and will cause hair loss when you try and invest any time
in it. It puts the breaks on actually learning with the distraction of going
and trying to find that new ambiguous stack that the author is hinting at.

~~~
xutopia
Rails has a bright future ahead despite what this article states.

Consider for a moment that most projects just need to figure out product-
market fit before we know where to throw the money to scale. Rails remains to
this day the tool I go to for building web applications because it's so well
suited for building something quickly. Sure the effort to make it scale is
present but I see any scaling effort as big regardless of framework or
language.

~~~
davidw
> Rails remains to this day the tool I go to for building web applications
> because it's so well suited for building something quickly. Sure the effort
> to make it scale is present but I see any scaling effort as big regardless
> of framework or language.

This is why I continue to use Rails despite being interested in this that and
the other new thing. It's very productive in terms of getting something up and
running.

I mean, heck, Twitter started with Rails, and despite some hiccups, managed to
grow. And Twitter is pretty much the poster child for something that has to
scale massively. Odds are, you won't have the same problem.

~~~
marshray
Twitter is the poster child for dumping Ruby.

Even if Rails is God's gift to CRUD app prototyping at some point you have to
ask if building a tech stack on something that is going to fail hard as soon
as you get popular is providing a good service to those who are paying you for
the quality workmanship.

~~~
adamors
Getting to market quickly is often more important than contemplating about
handling Twitter like traffic.

Also, I haven't heard of an application that never had to be rewritten
partially/optimised after X years in production. Some problems just don't
present themselves in the first couple of years.

~~~
shimon
Your statement is too cautious. At the start of a project, getting to market
quickly is VIRTUALLY ALWAYS more important than handling Twitter-scale
traffic. People are simultaneously confident their idea will be popular and
afraid of failure, so we have a strong tendency to over-engineer for scale.

If it _does_ scale, don't be surprised if you have to toss out your v1 and
rebuild. The difference between a good framework and a bad one isn't about
whether it survives scaling; it's about the details of when it fails, how it
fails, and whether you can fix it incrementally or if you're signing up for a
rewrite-while-hair-on-fire.

~~~
marshray
> it's about the details of when it fails, how it fails, and whether you can
> fix it incrementally or if you're signing up for a rewrite-while-hair-on-
> fire.

So the important questions are:

1\. Does Rails performance degrade gracefully under load?

2\. Can you gradually shift away from a quick-and-dirty Rails-based
implementation to something more scalable without the dreaded "rewrite-while-
hair-on-fire" scenario?

In my experience, the answer to both of these is 'no'.

(But these challenges are hardly unique to Rails.)

~~~
pmontra
Given the example of Twitter I'd say that the answer to the second question is
yes. They rewrote the Ruby (not Rails) backend and continued serving tweets.
Did they have theirs hairs on fire? Maybe, but I don't think you're never in
hurry when you rewrite parts of a popular service.

About question number one: no idea, but you can add more machines and scale
horizontally. Then you might ask if you want more efficient code between the
web server and the database. You can optimize up to C. Finally, Twitter is
still using Rails for the front end AFAIK, so it shouldn't be so bad.

------
mooreds
So, Rails has warts. What system that is used to build real world software
doesn't? I've built systems in a number of languages and frameworks and they
all had warts and issues.

How much research has the author done to find other solutions? The plea at the
end seemed very lazywebish to me. Or maybe ghost of Christmas Future-esque?

------
btilly
The problem comes from this.

1\. The costs of any layer of abstraction and magic that we have internalized
seem free to us. So we feel free to add a more marginal one.

2\. We have little visibility into any layer of the stack above or below ours.

3\. As people migrate between languages, they take what they did previously
and recreate it. Only "better".

As a result, complexity grows over time. And programmers are really bad at
noticing/correcting it. And when they try, they will come up with different
prescriptions. Often opposing ones. Explicit is good. (Go.) Don't let people
mutate state. (Functional languages.) Convention over configuration. (Rails.)
Move work from programmers to IDEs and tooling. (Java.) Make programmers
productive so more gets done with less code. (Most scripting languages from
Perl on.)

Over my lifetime, I've watched the resulting slide into complexity. Reading up
on history I recognize that it had been going on for decades before I learned
how to program. And it shows every sign of continuing to accelerate going
forward.

------
tootie
Just use Java people. You can bootstrap a Spring project in 10 minutes and it
will have every feature (ORM, security, caching, MVC) available with just a
maven dependency or you can roll your own and it will work fine. Strong
typing, good performance, sensible stack traces (if you don't overdo
annotations) and all the testing and monitoring tools you could ever dream of.

~~~
humbleMouse
This comment is what I feel like replying with to every article about some
"fast iterating" language. IMO the only reason to use rails if you don't
actually understand how web development actually works. Why would you pick a
slower language and platform like ruby/rails when java/spring is right there
available to anyone?

~~~
olavgg
And Grails is very similar to Rails, and you get the full power of the
JVM/Spring technology stack. And Groovy is a fantastic language that gives you
the flexibility everyone like to dream about.

~~~
vorg
> you get the full power of the JVM/Spring technology stack. And Groovy

If Groovy and Grails are technology "to dream about", one wonders then why
VMware (the Spring backers) retrenched their 6 developers working on Grails
and (what is now Apache) Groovy early last year, and why Sun Microsystems (the
JVM backers before Oracle) wanted nothing to do with Groovy in its day
(despite supporting the JRuby and Jython developers).

~~~
humbleMouse
Internal politics? Budget constraints? Bad management? Idk

------
mml
While it's true that Rails is sinking under the weight of its own cleverness,
and is clearly the old hotness, this has nothing to do with Ruby the language.

Rails' problems are its own, and Ruby's limitations and problem domain are
well known.

This is a terrible blog post by someone without much perspective. I award it
no stars.

~~~
MaxfordAndSons
The author of the post at no point blames Ruby for Rails' failings... But also
I'd contest your argument that they're unrelated. Ruby is what enables the
too-clever metaprog that make Rails stack traces so opaque. Also Rails has
almost certainly been the single largest drive of Ruby's growth and popularity
- observe the significant overlap of core contributors to both projects.

------
tunesmith
I've been doing enterprise backend development (java/spring, scala, akka) for
a while and occasionally miss the practice of sitting down and creating a
fullstack app myself, which I used to do with php and crappy html. But then I
sit down and try to work with existing Ruby/Rails codebases and hit a mental
block.

I guess example #1 is method_missing. I get it, it's a huge time-saver and
lets you do all kinds of cool things like specify a default behavior for an
API if someone sends a random command, or, define the behavior of a method
dynamically by the name of the phantom method. But then the rest of me is
reflexively saying, "Seriously??" And I get that Spring Data does sort of the
same thing, but at least there it's limited by domain. If I'm in a Ruby
codebase that is taking regular advantage of that, my first instinct would be
find calls that eventually go to method_missing, and then just define the damn
method somewhere so that my IDE's "Find Usage" will work again. How the heck
do you explore a codebase quickly if your IDE doesn't work?

I guess for me it just reinforces the same rules of thumb. Dynamic languages
are fine if you're prototyping or doing an MVP. But as soon as you find that
your codebase is being read/maintained more often than it's being written
(which will happen sooner than you think), or as soon as you start finding
weird production runtime bugs that don't happen in your local environment,
you're better off with something strong or static or compiled.

As for how to get that safety full-stack these days, I'm still poking around.
Scalajs seems interesting, or Angular2 with Typescript, or something that uses
RxJs...

~~~
abc_lisper
How about writing tests that enforce invariants?

I have been doing clojure dev for a little bit, and here's what I do -

\- Run tests in the background continuously (lein expectations will give you
that. or you can write your own shell script)

\- Do small checkins, frequently to git

\- Write tests that enforce invariants. Haven't gotten to test check yet - but
I guess that would be even better.

The trouble with types is they push you into a corner early, and after a while
people will be coding to zombie constraints - the constraints that were there
before, but not true anymore. They are also verbose, and need tooling to get
you out of the corner. If the requirements change a little bit, it could be
that, your old solution goes against the grain of the new problem, which is
very hard to get rid of without rewriting the code.

With dynamic languages, I find that I think more about the problem, than
trying to do constraint satisfaction with other entities in the code, not to
mention the language itself.

~~~
tunesmith
I've honestly never felt like types have gotten in the way. I also write
plenty of tests with plenty of mocking, it's just that the type system means
we don't have to write tests for the things the type checker checks for.

I'm having trouble thinking of a time when I felt something akin to what you
describe with zombie constraints. If anything, having a good type system makes
it easier to rip out code that isn't used anymore. And Generics can help with
keeping your solution from getting too specific.

~~~
abc_lisper
The only dynamic language I used in production code is Clojure, hence my
perspective is probably skewed by it.

> I'm having trouble thinking of a time when I felt something akin to what you
> describe with zombie constraints

Think of deprecated methods in a class, unneeded methods in an interface that
are stubbed etc.

> I also write plenty of tests with plenty of mocking

This is good. But what happens to mock objects when the underlying class
changes its implementation - It needs a large number of changes in tests.

If you are writing micro-services, the guarantees that typed system gives you
are more trouble than they are worth. If your average microservice is less
than 10k lines of code, it probably reduces to 1000 lines of code in Clojure,
and for the codebase of that size, typed systems provide little value for the
cost(atleast for me).

------
polysaturate
I…don’t understand the point of the article? Ok Ruby is duck typed and has a
dynamic runtime. It has for…all of the time since it was created. Rails has
magic… since…all of the time since it was created.

I’m not even defending Ruby or Rails here. Use at your own benefit/risk…as
with every other programming language and framework.

~~~
crdoconnor
The emphasis on magic was a particularly bad decision. It looked wonderful in
the original screencasts that let you build a webapp in 5 minutes. It causes
terrible pain when you're trying to do something complicated.

This was one of the mistakes Django made and - to their credit - got over
relatively quickly. It began as a kind of imitation of Rails but they stripped
out the magic pretty quickly and made it a lot more explicit.

------
hgh
From Stroustrup of C++ fame: There are only two kinds of languages
[frameworks]: the ones people complain about and the ones nobody uses.

~~~
uptownJimmy
I think Rails might be a framework that nobody complains about, in the mid-
term future. It is showing signs of age. And, though I say this with strong
respect in my heart, the Rails governance is as opinionated and inflexible as
the framework itself.

------
omarforgotpwd
1\. The first software wave was system level software. Developers wanted
something but made their lives easier, but also wanted control and speed. C
and then Java were the stars

2\. In the second wave, we got languages like Ruby and Python which are
flexible and easy for developers to work with. Sometimes it's more important
to be able to iterate quickly than execute quickly. Server software, app
backends, etc were all implemented in whatever language was easiest using HTTP
as an interchange with other languages

3\. In the third wave, developer experience enhancements that scripting
languages pioneered trickled down to systems programming with new languages
like Swift and Go. These give you most of the benefits of the second wave
languages without their significant overhead. Since they are better suited to
building small light services, old bulky Ruby / Rails app are starting to look
antiquated pretty quickly.

I also used to go to Rails first for web projects... I use Go now because it's
more lightweight. I used to do native apps in Objective-C... I now use Swift
because it's easier to write.

------
hardwaresofton
For those that are feeling fatigued from working with and around the magic of
Rails, Sinatra is a great choice (in python land Django has an alternative
called Flask).

[http://www.sinatrarb.com/](http://www.sinatrarb.com/)

That said, you will have to re-implement machinery that rails gave you for
free. If you're building a simple API, there will be obvious simplicity
benefits. If you're trying to build a server-side rendered web application,
you may long for some things that rails provided (of course, you can use
libraries and create simpler patterns than rails provided).

Note that going the sinatra+libs (or any "micro" framework for that matter)
route places a higher burden on the development team when it comes to
documentation. If you implement a scheme for server side templating/rendering
outside of what is provided, you will be in a world of pain in a relatively
short time if you do not maintain good documentation.

~~~
bphogan
You will indeed have to re-implement stuff Rails gives you. But more
importantly, you will have to maintain it.

I maintain a large-ish Sinatra app that should've been done with Rails. Update
cycles on the gems are a nightmare. It feels cobbled together. it's a "half
baked homegrown version of Rails."

Someday I will just move the logic to a new Rails app and be done with it. It
was a terrible idea.

* your experience may vary. :)

~~~
hkarthik
Any sufficiently complicated Sinatra app contains an ad hoc, informally-
specified, bug-ridden, slow implementation of half of Rails.

------
draw_down
Everyone who uses software older than your preferred framework is an out-of-
touch fuddy duddy, and everyone who uses software newer than your preferred
framework is a clueless hipster.

------
cplanas
I agree with some of the issues that the author points in Rails; but, at the
same time, he is unable to name what is "today's software" using his words.
Until then, I will stay with Rails. Until then.

Moreover, the author seems to be imagining Rails as a huge monolithic piece of
software. That does not need to be true.

~~~
jmstickney
Doesn't the author end by saying Swift, Rust and Go are "tomorrow's
languages"?

~~~
collyw
Yet he gives absolutely no justification for why those are "tomorrows
languages". You don't use third party libraries or frameworks in any of those
languages?

Personally I design my Django code to be as simple as possible. I use third
party libraries, and don't see too many of the problems he talks about.

~~~
nicops
Probably because the author doesn't use them and thus has no idea of what
their problems are, so they seem "perfect" from a distance.

------
aaronwidd
It's not Rails. Web software development in general has simply plateaued
across the board.

We're out of new frontiers to innovate around and the work from now on is
about playing custodian to the innovations of the past.

Unless something spectacularly interesting comes along, the priorities of the
web are now all about supporting what's already been built. Either by
maintaining something hastily built and cracking at the seams with patches and
fresh coats of paint - or replacing it with something more stable for the long
haul. Rails was designed around rapid innovation, not the long haul. So it's
in maintenance mode.

~~~
smrtinsert
We finished the web guys, you heard it here first on hacker news.

------
gsmethells
Know your dependencies well. Keep them few and far between -- and well vetted.

------
lmm
I've been using Scala for 5+ years now, so for me it's definitely today's
software. Spray for REST backends, Wicket for HTML UIs. Clean syntax that can
be as expressive as Python or Ruby, but coupled to a type system more powerful
and effective than any of Swift, Rust or Go, light enough that you can lift
things that had to be "magic" (like database-session-in-view) right up there
into the type system.

------
zippergz
Honest question. What technology are people enjoying on the server-side with
sites built in React or Angular? I've seen some of these done with Rails, and
some done with Node, neither of which I personally enjoy a whole lot. (Note,
I'm not making an argument that either are BAD - just that I don't really like
working with them). I'm curious to hear what other people are having success
with in production.

~~~
spinlock
Pheonix looks promising. It's basically Erlang on Rails.

~~~
bobwaycott
Or Rails on Erlang (even though I see what you did there).

------
spriggan3
> Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern
> thinking, build a community with simple as a core design goal, and save web
> development from itself?

Go is great for plumbing, you can get network utilities up and running pretty
fast with no dependencies so it's easy to deploy, that's its niche. Now try
writing a complex eCommerce website, a news site, or any large app backed by a
complex data model in Go...

I started to use Asp.net CORE on Linux with Postgres the other day and
frankly, I don't want to hear about Go and its "simple" type system anymore
when I can just use C# and do projects in minutes without fighting the
language. Go is at at most a safe C with channels (without macros which make
it worse than C in term of features).

My point is neither Swift,Rust or Go are silver bullets which will fit every
use cases in Web Development. Neither is asp.net core,but for my use case
there is no debate as to what I should be using.

Rust,Go and Swift aren't tomorrow languages. They are languages that fit a
specific use case like every other language.

------
tangue
I was dubious when I saw the Medium.com tld and a clickbaity title but it
actually puts word on what I feel after 16 (ouch) years of web development.
The difference was that I was blaming the tools and screaming "#fail" with the
other rather than thinking like the author that we're in a conceptual dead-end
(at least with popular tools).

------
scolfax
Don't blame your tools for an over-engineered project.

------
MrBra
If Rails, as of now, would've been a very fast framework, the post author
would have never published such post, despite all the other "defects" he
underpins.

Rails could eventually get very fast, but it can be frustrating that it's not
right now!

This is the same kind of problem of Ruby not having a proper x-platform GUI
toolkit or binary packager: you have such a expressive and powerful language
and still you feel you are limited by the lack of speed and tooling.

That's why, IMO, a Ruby/Rails dev frustration can explode in such a strong way
at some point.

Sadly Ruby isn't backed by a big corporation, so you can only wait for the
language and frameworks to get more mature.

Personally I've dealt with this frustration by learning C#. It allowed me to
overcome all the current limits of Ruby, while avoiding the Java ShitFactory.
At the same it feels great to get back to Ruby when you want to explore ideas!
It's still an unbeatable tool for prototyping. Being aware that I have
knowledge of another language, makes me feel better, less frustrated, and I
browse Ruby weekly news with much less "anxiety" for a revolutionary Ruby
improvement (but still I browse it because I know it will happen sooner or
later!).

I'm quite sure that the OP after having vented with this post, and having
found what for him is a solution, then he will peacefully embrace Ruby or
Rails again under a different light (but again, I wouldn't be so surprises to
see big improvements soon, so maybe it could even be a better light!)

------
hartator
Rails seems to become bloated for sure, but I think there is not a no brainer
alternative out there.

When I first switched from PHP to Rails it was a natural choice whereas i
don't feel Rails to Node.js is in its current state.

~~~
max_
i wish someone could say the same for bootstrap

------
tomc1985
Well, the situations with coffeescript exceptions and exceptions-from-the-
depths-of-hell are avoidable (hint: don't use coffeescript)... indeed Rails
makes it easy but just because crazy amounts of gems are on offer doesn't mean
one has to use them.

Ruby/Rails certainly has its quirks, and while Rails certainly does seem to be
taking on more and more unnecessary dependencies, some are still plenty
productive in day-to-day Rails. A lot of pain avoidance in Rails is following
its opinions up-and-until it takes you further than you need to go

------
cryptos
I had similar experience with Grails. Discovering Grails and seeing how fast
the first version of the application is up and running was fascinating. But
sooner or later almost all generated code has to be replaced. It's not bad for
the first iterations, but no time save in the long run. But the Grails magic
was really awful! It cost so much time to find all the hairy bugs (in my own
code or in Grails itself). Finally I stopped using Grails.

I perfer static typed languages now (not only because of Grails and Groovy).
And I prefer to compose some specialized frameworks. For example JAX-RS
(Jersey) is a very good REST framework. There is no need to force the user to
use it with a certain ORM (if at all), a certain way to validate objects and
so on. Just take what fit's best. Java is not the most elegant or productive
language but there are other static typed JVM languages like Kotlin or Scala.

To come back to the article: I don't think that we need new languages, but
another way to use existing frameworks and maybe statically typed languages.

------
elcapitan
While I agree with many of the individual points he makes (rails dev myself),
I think there is a kind of fundamental issue there that we have seen with most
web framework/language combinations and will see with future ones, and that is
that they usually come to life when one concept or idea they embody the best
(for example mvc for crud apps with Rails, frontend/backend unification with
node, native concurrency with Erlang, puristic http for microservices with Go)
is becoming prevalent at some point, and then people put stuff on top of stuff
which they put on top of other stuff, and then they realize that the problem
they still have to solve is good architecture. And they need to balance that
with business needs and developer availability.

I don't think any of that is going to change by switching to the next
fashionable concept to base a web app on.

------
tankerdude
So my question would be, what's the difference between Rails and other
frameworks, especially since we are doing RESTful APIs from the start?

It would seem to me that Rails is just not the tool to use going forward for
writing APIs for websites at scale. There are much better tools out there.

Rails' sweet spot is server side rendered pages that are quick to bring up and
to add features. It seems great for certain types of websites so it does have
its niche.

But moving forward, Rails for API vs. other frameworks in other languages is
really a wash in terms of productivity, while other frameworks in those other
languages are much more highly performant.

------
SeanDav
So if Ruby and Python frameworks are not suitable web development platforms -
what is? The OP gives no alternatives, just a long rant about the problems of
web development with dynamic languages.

------
smrtinsert
I'm always tickled by the mythology that was sold thanks to a macbook and a
textmate theme - that creativity is inherent to it, and that it is a pioneers
tool, for craftmenship etc.

That might all matter if the first thing people did once deploying it was to
port off of it. For software that has such a rapid expiration date, none of it
selling points matter. You might as well have written it in php or perl.

Rails continues to be a favorite joke of mine.

------
heyts
While I hear the argument, I'm tempted to think that the framework is largely
irrelevant and that it actually is the ecosystem (package management and lack
of quality control) that is harming platforms at large from Rails to Django
to, obviously, node. I was very interested to hear of Elm enforcing Semver at
the package manager level and I believe that this is a step in the right
direction.

------
gjvc
Web development techniques are crying out for an "emperor's new clothes"
moment. Approaches like GWT (+ a toolkit such as GXT) seem to be a far saner
approach for many enterprise applications. On the other hand, there are large
classes of problems for which Rails / Django / et al have shown good results.
Vive la difference!

------
mnarayan01
There's certainly a lot of truth in this (I especially like the duck-typing
image), but the example feels like it throws it all away. You can, after all,
have a _super_ fast and simple asset pipeline by keeping things...simple (to
say nothing of skipping it entirely); having CoffeeScript compiling to
JavaScript is not really relevant to either Ruby or Rails.

------
bluedino
The question is where do you go from here if you're a Rails shop?

The last place I worked had 80% of their products running Rails 2 and 20% of
them running on Rails 3. No product was ever both completed AND caught
traction since.

Do you stick with Rails 5 for the next project? Do you meander over to Python
or Node?

~~~
sotojuan
Dockyard, a Rails agency, is moving to Phoenix I think.

------
pbowyer
Previously posted at
[https://news.ycombinator.com/item?id=11658356](https://news.ycombinator.com/item?id=11658356),
with great comments

------
miloshadzic
It's today's software which -- being almost a synonym for enterprise software
-- can be a problem for a culture built on it's difference from Enterprise
Java.

------
emodendroket
Yeah, yeah. Nothing is going to magically solve all your problems; I don't
necessarily think that means we need to go back to hand-rolling everything.

------
avitzurel
Today I learned that not everything you read on Medium is true and should be
considered anecdotal and smart.

------
mattmcknight
A couple of things seem off on this perspective, mostly that modern web
development has gotten weird, irrespective of Rails.

"The ambiguous, english-like syntax of ruby that makes rails so easy, is
exactly why it’s not simple."

First, I found Rails simple and easy, but it has become more complex over time
as it has grown to support a variety of uses. The simplicity is not just
because of Ruby, which is a low ceremony language, but rather because of the
simple structure of the application, with a clear separation of concerns, very
easy to find where a particular code item went.

"The meta-programming and object injection that 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. "

Dependency oriented development is a real problem, but it is insane to blame
that on Ruby. I was working with an enterprise Java team last year that had
over 1000 .jars in their build. It doesn't necessarily make it hard to debug,
but it does mean you have understand a wide variety of different libraries.
People are willing to load a library for the simplest of functions (as the
leftpad npm case showed). Again, nothing to do with Rails or Ruby in
particular.

"The magic of active record, the crazy levels of duck typing and the
expressiveness of ruby, are exactly why it runs poorly even on your
development box." This is highly dubious- it's very fast on my dev box. The
Ruby interpreter keeps getting better, even taking lessons from V8, and you
can compile to JRuby if you think that interpreted runtimes aren't ever going
to keep up.

"It’s why you have to build a caching strategy in as a requirement from first
line of code." This seems like a good strategy regardless, and caching is
nicely handled in Rails.

"Competitors to Rails seemed subject to the same problem — basing themselves
on interpreted, slow languages that favoured ‘easy to learn’ over ‘easy to
maintain’." As opposed to compiled, fast languages like C++ that are hard to
learn and hard to maintain? If anything, duck typing makes maintenance lot
easier in some cases, where you can add in new types which support existing
behavior, without making changes throughout the dependency tree. Even some 8
year old Rails apps we have are quite maintainable. JavaScript code does have
a tendency towards messiness, as there are such a variety of schemes for
organizing code, but it keeps getting better.

"I should be spending time writing code, not debugging a haystack of mutable,
dependency-wired mess." This is your choice! I think it's nice to have
toolsets that give people the ability to assemble things quickly, but no one
is forcing you to use a gem to do something.

"Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern
thinking, build a community with simple as a core design goal, and save web
development from itself?" This seems like barking up the wrong tree. The thing
making web development complex is largely the complexity of the front end. You
can turn your back-end application into a separate API and isolate this
problem. At some point, these become browser capabilities, and the polyfill
approach has promise.
([http://bitworking.org/news/2014/05/zero_framework_manifesto](http://bitworking.org/news/2014/05/zero_framework_manifesto))

In reality none of the stuff mentioned in this article is really a shortcoming
of Rails as compared to anything else. The biggest change is the move away
from the basic nature of REST-ful, URL driven applications. Single page apps
are a lot more like desktop applications. Many applications are looking for
web sockets. These changes to the basic structure of what a web application is
are much more of a challenge to Rails than the Ruby language itself.

~~~
pmontra
+1 but about REST and the websockets: I'd keep using REST to query data and
send data (and get a response). I'd use a websocket only for those cases where
I should poll the server for updates. Reimplementing most of the semantic of
HTTP into a websocket looks weird. Basically it would be tunneling HTTP into
the websocket, which is already an upgrade of a HTTP connection.

Exceptions: I won't POST to a chat, even if there is nothing so wrong with
that. Rationale: I'm already using that websocket for receiving messages, but
only the messages for that chat.

------
askyourmother
I remember early Rails, around 0.13, pre RC, the community was small the
future seemed bright. Little did we know the horrors of what it would turn
into. Most of the professional people left when they saw the security circus,
the endless holes and design flaws.

I learnt then - avoid any web framework which has pragprog pushing a book
behind it. The new one to avoid because the masses are already circling around
it is 'phoenix', and sure enough, pragprog is hawking a book on it.

~~~
chrismccord
Author here. Hawking a book? Are you kidding me? I'm also the creator of
Phoenix. I spent two years of my life outside of a FT job to get Phoenix to
1.0. We started a book because first class learning materials outside of the
basic online guides is necessary on any platform. I make $3/copy from the book
sales, so "hawking" a book does a disservice to me because if this was about
money, I wouldn't have spent 8 months of late nights and hundreds of hours
working on a book. Please reconsider your argument.

~~~
paublyrne
Ordered your book last week Chris and can't wait for it to arrive. Very
grateful for all the work you've put in.

