
I Miss Rails - chanind
https://chanind.github.io/rails/2019/03/28/why-i-miss-rails.html
======
BillFranklin
> if the modern equivalent of Rails already exists, please let me know!

You're in luck. Rails 5.2.3 was released 20 hours ago.

More seriously, I feel rails is still excellent and I'm happy to work with it
every day. I'd be interested to hear more about what makes rails not modern? I
find it a very productive framework.

EDIT: If you're talking about missing a JS equivalent of rails, do you know
about Loopback? [https://loopback.io/](https://loopback.io/)

~~~
0xADEADBEE
I know this is the opposite of what you asked but I find Rails to be keeping
pace with modernity much better than its conemporaries! Django seem to have
given up on integrating websockets (ActionCable has been in Rails for
literally years now), nor is there trivial integration for JS assets/asset
pipeline functionality. I don't write much of either anymore, but I'd still
reach for Rails the instant I need to get something done quickly.

~~~
dbrgn
Django has multiple good asset handling libraries. I like [https://django-
pipeline.readthedocs.io/](https://django-pipeline.readthedocs.io/).

And with django-channels
([https://channels.readthedocs.io/](https://channels.readthedocs.io/)) Django
goes way beyond just WebSockets. You can now do fully asynchronous data
processing pipelines.

I'm still happy working with Django (which is not something I can say about
the JS ecosystem). Especially when doing APIs with Django REST Framework.

~~~
0xADEADBEE
Fully agree with you - been in the JS world a lot lately and it's not as
polished as the more 'traditional' web frameworks.

Channels was supposed to make core but never did - what happened there? That's
what I was driving at really - if I were stewarding a modern web framework, I
would be integrating websocket support. It never sat right with me that
something as common as APIs is farmed out to a library in Django (this comes
out of the box in Rails with no configuration) either.

I don't dislike Django, but I certainly find that there's a lot more messing
around to get done things that I would consider pretty standard. I used the
new Rails beta last week and I noticed that Webpack integration is now there -
how long until we see something like that with Django?

~~~
Spiritus
>Channels was supposed to make core but never did - what happened there?

[https://www.djangoproject.com/weblog/2016/sep/09/channels-
ad...](https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-
official-django-project/)

~~~
nnain
Andrew Godwin (creator of django-channels) has recently handed over the repo
to other maintainers and moved on to some role on adding `async` support to
Django Core. (Channels was officially adopted by the Django project, but isn't
part of the Django-core — you still have to add the package separately.)

This async support is hopefully coming within 2019. I'm super-excited about
using it in future django projects.

------
davidbanham
I actually have gone back to writing server-rendered apps like it's 2012 and
it's been wonderful.

Server-rendered used to mean slow and clunky but I've found that using Go my
page loads are super fast. The inter-page transitions can sting a little on
really really slow connections, it's true. But users are much more willing to
deal with them if they haven't first been subjected to a minutes-long spinner
while the SPA loads up all its libraries and state.

A little game I sometimes play is asking fellow developers to try and guess
the frontend framework used on one of my apps. They click around for a little
while wondering "Angular or React" before I tell them it's actually just some
Go templates rendered on the server. It often opens their eyes that the loads
were so fast they couldn't actually tell they were happening.

SPAs have their place and I've written a lot of them. It's amazing how far you
can take server rendering in 2019, though.

~~~
GuiA
How many "quality of life" features does your website have that require some
JavaScript that you end up writing as one off functions/endpoints/etc?
(various kinds of autocompletion, live search, notifications, messaging, etc.)

I'm all for server side rendering - I maintained several vanilla PHP/HTML/CSS
websites in the 2000s, and only used jQuery sparingly when things grew in
complexity. I later used Django for many years similarly, and when
react/ember/angular/etc. started blowing up is when I started feeling like
performance was something we had to worry more about.

That being said, server side rendering shows its limits when you build an
application with lots of actions your users can perform on the data shown in
their window, and reloading the page every time would significantly slow them
down. That's when you're tempted to start going the SPA route, but those
frameworks tend to be pretty opinionated about how you should structure your
code and data, a slippery slope that leads to the stereotypical bloated,
unresponsive JavaScript mess some websites have become famous for.

There is certainly a balance to be found, but it's a tricky one.

~~~
rakoo
I haven't developed any website but my server-side preference would definitely
lead me to something that is always server-side-rendered. It's no surprise we
all like HN, the experience definitely feels more than good enough.

There was a standard
([https://tools.ietf.org/html/rfc3229](https://tools.ietf.org/html/rfc3229))
to diff pages so that only the delta would be sent to the browser. After that
the only missing piece would have been that the browser doesn't refresh the
whole page but intelligently re-renders the difference in the DOM, and that
would have been the perfect world.

~~~
jdmichal
I'm really only familiar with ASP.NET, but do other frameworks not include
support for partial page rendering? The ASP.NET `UpdatePanel` is simple and
even has gracious degradation. (If client doesn't support for whatever reason,
it will just revert back to doing full page POST and refresh.)

Of course, this is just wholesale replacing a DOM subtree with another. But
there's also probably some point where just parsing the new subtree is faster
than attempting to create and apply a diff.

------
ericb
Why miss it, come on back, the water's still warm and the dev is still as fast
as ever in Rails. Honestly, the JS stacks all seem vastly more annoying on so
many levels.

It seems like the JS ecosystem changes so fast because it _knows_ better is
possible, so it just tries to reinvent itself over and over.

The JavaScript world starts with this weird prototype based language with a
syntax that looks like it might be something more class based. From there it
goes to dependency bundling hell, callback hell and Christmas tree code
indenting, no standard implementation, and a library required for everything
under the sun (Left-pad!) And somehow this is what the cool kids are into? I
never liked Rails because it was "cool" I liked it because I love getting
stuff done, fast.

~~~
chanind
Oddly I never considered starting a new project with it, but now I'm
questioning why that is. I guess I just don't see many new projects started in
Rails, and nowhere I've worked the past few years uses it. I stopped using it
after Rails 3, but I'll give it a try again in the next side-project I work on
and see how it goes.

~~~
jacobsenscott
Server side rendered is still fantastic for the vast bulk of web apps.
Turbolinks and a bit of care around performance and all you users know is you
have a fast site. Not many apps really need the super rich SPA type
experience.

~~~
brightball
And you can take this approach to the next level with Phoenix LiveView that’s
in its testing phase right now. Server rendering is so fast in Phoenix that it
had a lot of people clamoring for a turbolinks-like solution to the problem.

It’s not perfect yet, but as a first version is remarkably capable already.

~~~
jacobsenscott
I heard someone on the ruby rouges podcast say they got turbolinks to work on
Phoenix pretty easily.

------
digb
I’ll say this: I came to Rails _from_ Node (and before that .NET but with a
way smaller scope of responsibility), and I am thoroughly convinced the author
is correct. I couldn’t estimate for shit in my first few months at this job
(once I had ramped) because Rails makes things that would’ve taken at least
twice as long easy to do, even without gems. Plus, I have seen not even a
third of the compatibility issues between our version of the framework (bit
old) and up-to-date games as I saw when I was writing Node full time. Rails is
the first non-“enterprise” framework I’ve felt let’s me focus on the correct
level of concern for my current needs.

~~~
jonahx
Here are two of the most popular books on Rails on Amazon, along with their
page counts:

"The Rails 5 Way" (1088 pages)

"Ruby on Rails Tutorial: Learn Web Development with Rail" (816 pages)

Rails _is_ enterprise.

~~~
ericb
What does this _enterprise_ slur even _mean_? Is it like saying a band sold
out when they had a hit record?

Do we only use undiscovered indie frameworks now?

~~~
jonahx
It means it's everything but the kitchen sink: heavyweight, difficult to learn
and use, and full of features you don't need.

It has nothing to do with popularity being bad. In general that's good a
thing, because support is better (and rails does have terrific support), but
it does exert a feature-accretion force.

~~~
digb
I didn’t mean it as a slur! When I wrote .NET, the applications I was working
in were massively large and complex, and so mostly what I was working on was
optimizing small bits and pieces, and they allowed me to focus ON optimizing
those small bits and pieces, because they were what mattered in that context.
Rails let’s me focus on the big picture, because that’s what matters in my
current context. Express had me working on stuff that I didn’t REALLY care
about/want to know about in the context I was in.

------
lettergram
I still write Rails applications regularly, some applications I've maintained
since 3.0 to 5.x.

What's amazing, is I booted up a 4 year old project in minutes the other day
at work. A co-worker was interested in using the project, it took 15 minutes
to setup clean.

Overall, I find Rails is easily more maintainable and definitely enjoy it more
than the Django and Flask apps I write regularly. Javascript (Node +
React/Angular) breaks all the time when upgrading, so maintaining it is not
super fun either...

Here's a project I wrote in Rails and deployed late last year:

[https://hnprofile.com/](https://hnprofile.com/)

Works like a charm!

I even recommend Rails to new people starting out because I think it sets best
practices.

~~~
styfle
That’s a fascinating tool! Now I realize I need to use more enjoyable words
when discussing TypeScript :)

------
tombert
I'll take a mildly unpopular opinion and say that I really despise code-gen-
style web frameworks, like Rails or ASP.NET MVC or Django, and would rather
reinvent the wheel than use them.

I definitely see the appeal of these frameworks, but I feel that a side effect
of having them is that there's a metric ton of code generated and you really
have no idea how it works. I remember spending almost 30 minutes digging
through the C# object being used to parse JSON, generated by ASP.NET, to see
why a field mapping was being done incorrectly, simply because I had traverse
through four different files to see the logic.

Granted, part of the problem there is intrinsic to how C#/Java are structured,
and the massive number of files needed by them, but I still feel that the code
generation made it worse.

Even if the code weren't generated, the amount of ceremony to add an endpoint,
add a new type to be parsed, and perform updates just does my head in. That
aforementioned C# app was about ~1000 LOC, across a few dozen files. I rewrote
the system, from scratch, using Clojure and http-kit in around 100 LOC,
without losing any features.

I'm probably just old now, but I suppose I really dislike magic in my
codebase, which is why I tend to prefer the lower-level things.

(Also, just a note, I'm a total hypocrite, since I actually wrote an MVC-ish
framework in Node.js 5 years ago, then ported it over to Erlang).

~~~
zrail
Rails auto generates very little these days unless you ask for it.

~~~
ndnxhs
I very much appreciate the code generation. I hate having to make repetitive
changes in 4 places to add a new file because nothing is wired up
automatically.

~~~
tombert
But why should there be 4 places to change things to begin with? Why not use
libraries to minimize the amount of surface-area entirely?

------
blacksoil
I still develop using server-rendered like it's 2012. Since I'm pretty much an
indie dev, I just don't think it's worth my time to initally start a project
off REST API (i.e. using react) because it's literally 1 more layer to take
care off. I.e. if a REST end-point name changes, then I'd have to modify both
frontend and backend code. In addition to that, initially, getting a software
specs is a much harder problem than to implement. Having to create REST
endpoints for every single data that needs to be passed around is not nice
when the structure and specs are still very likely to change.

Moreover, finding developer experienced in react is much harder and more
expensive than those who do traditional HTML-CSS combo. Finding a freelancer
to slice out PSD design into HTML-CSS is also much harder to go wrong. I
wouldn't be comfortable outsourcing a react project to freelancer I barely
know, but I'd do it for HTML-CSS.

I'm not against react or other SPA frameworks by any means. I think they're
great technology that makes certain use cases convenient and can make a good
user experience. That being said, there are also costs for those, and I just
feel like there are so many websites out there that don't actually need to be
implemented using SPA. Traditional server-side rendering would have saved them
so much time, resources, and headache.

I personally would only rewrite a particular project into an SPA when there's
a real need for it. For example, when the user base is large enough that a
nice-to-have user experience becomes a big enough deal, if there are real
needs for "reactiveness", or if mobile apps counterparts that would also
require REST API is needed.

~~~
RyanShook
As a beginner, Rails seems much easier to get from zero to something. So much
of the tutorials I’ve seen on react are about dependencies and environment
setup. I know React has some big advantages but on smaller teams/projects it’s
hard to see the benefit.

------
jph
Elixir and Phoenix are excellent, and you'll recognize many of the same
concepts in these. The communities are excellent as well, and welcoming to
newcomers.

~~~
0xADEADBEE
They're fantastic and I hope the future is bright for them but I've had to
pick Rails for a few projects over the last few months because the library
support is so much more established. The more I get to use Phoenix, the more I
am convinced it is the most well designed web framework there is, so I hope to
use it a lot going forward.

~~~
chessturk
Elixir/Erlang's emphasis on uptime/fault-tolerance/scalability/concurrency
(admittedly at the cost of performance and the abstraction of a VM) is
perfectly suited to web/mobile use-cases.

On paper, Pheonix should be the default choice for large and small web/mobile
MVC applications. I think the question of if that becomes the case is directly
tied to adoption of Elixir.

~~~
Jedi72
The performance comparison matters if you start comparing nginx, and maybe
even the Go/Rust frameworks, but it absolutely blows Rails out of the water
for performance without sacrificing any of the high-level abstraction goodness
that makes Rails appealing. No reason not to move to Elixir unless you cant
hack functional programming IMO

------
viksit
"Move fast and break things" very accurately reflects the state of Javascript
development in 2019. Libraries and frameworks, and node/npm themselves move so
quickly that APIs, versions, ways of doing things -- all break so quickly as
to be ludicrous.

This post rings true.

I gave nextjs a try recently to build a simple dashboard that could connect to
our oauth provider. Forget external libraries, even simple ways to do state
management, user login, screens, HOCs to guard routes - all of this is poorly
documented, managed, and there are 100s of github gists that aren't versioned,
demonstrate old APIs that have been deprecated and aren't really usable unless
someone who knows that they're doing goes in, and cobbles together an example.

~~~
pault
I'll bite. One, I'm not sure next.js is the right tool for a simple dashboard.
Seems a bit overkill. I think some simple MVC pages with vue dropped in where
necessary would be a better fit. Also, your last sentence sounds like you're
saying that it's not usable unless you know how to use it.

~~~
viksit
For completeness - the goal was to create a dashboard that could actually
utilize SSR as we scale it up to larger amounts of traffic.

The last sentence was written to mean that unless you go in and spend a LOT of
time reverse engineering code from a myriad examples, it's almost impossible
to get a working implementation.

------
davidscolgan
I've been using Django since I started 10 years ago. I argue that it was a
great choice back then and it's _still_ the right choice even with the advent
of the modern everything. If you are writing a website for a business, I see
nearly no actual business case for using Node+SPA for nearly any kind of
website you'd want to build. Especially in a business context, unless you are
building a super ultra real time thing (and then use Elixir not Node), Django
will do just fine and be several times faster to develop and easier to pull
off. And you can get pretty far into the dynamicness camp before it becomes
untenable. s/Django/Rails.

~~~
joelbluminator
Rails developer here. I did Django for 6 months and nothing bad happened, it's
a sane, mature, solid framework. Ruby/Rails feels nicer to me but Django is
super solid. Also, a senior Rails developer can become very productive in
Django in a matter of months (and probably vice versa) so it's not as if it's
two worlds apart.

------
lxcid
I personally don't missed Rails mostly because boilerplate doesn't really
bother me. I'm more afraid of using the wrong abstraction.

Rails (v4 was my last experience) was hard for me and I think my reasoning is
as follow:

\- I like to dig deep into the framework I work with but Rails have so much
meta programming (a.k.a magic) that I struggle real hard figuring out stuff.
You often have to go into runtime, hit method and see where it lead you to and
after a while, I realise that I'm not going to see the bottom.

\- If you are someone who like to dig deep, the documentation wasn't helpful
for me at all.

\- ActiveRecord for a while discourage using foreign key. When I move away
from Rails, I tried SQLAlchemy and love that its unopinionated. Then I move to
node and agree its ORM are less powerful but I learnt to love SQL.
ActiveRecord for me shouldn't be any more than just convenience ORM and
shouldn't replace SQL, that goes against Rails' ActiveRecord philosophy which
claim these constraints should be at the model side rather than DB side.
[https://guides.rubyonrails.org/active_record_migrations.html...](https://guides.rubyonrails.org/active_record_migrations.html#active-
record-and-referential-integrity)

\- Lastly, I firmly believe MVC is a leaky abstraction. Any variations of MVC
is just shifting the complexity around, not reducing it. I worked on Rails,
worked on iOS (which uses M-V-VC). The pattern I see is that almost every
year, someone will get bitten by vanilla MVC, tried some variants
unsuccessfully and conjure a new variant; the cycle goes on. MVC is a 20 year
old pattern, it have amazing insight into how we should build application, but
its implementation always fall short after so many years.

Ultimately, I don't think Rails was optimised for someone like me. I think
there's just fundamental differences in philosophy between me and Rails.

~~~
kbp
> MVC is a 20 year old pattern

More like 40; it's from late 70s Smalltalk.

~~~
gilbetron
Can confirm, I worked at a Smalltalk firm in 1995 and was taught MVC then, and
was explained to how it was an old pattern.

------
reilly3000
I really have no horse in this race, but I would like to know what the
argument FOR React+Redux+GraphQL is for developing apps in 2019.

Is it that we need to offer offline clients to meet user expectations?

Better raw performance on the front end?

Cheaper server costs or easier to deploy serverlessly?

For the progressive enhancement of your resume?

~~~
wefarrell
Agnostic of stack, SPAs provide a clear separation of concerns. The api layer
is responsible for transforming data between the client and controlling
access. The client is responsible for presenting the data structures provided
by the api to the user, and turning user inputs into data structures that the
api can consume.

~~~
Boxxed
I feel like this line of thinking is very analogous to the whole microservice
craze -- you shouldn't need to introduce a network boundary to write well
architected software. There's no reason you can't have a clear separation of
concerns in a server side rendered application.

~~~
hombre_fatal
What does that actually mean, though?

And "there's no reason you can't, if you wanted" is a far cry from "sure, the
work is already done."

For example, something as simple as having a server-side rendered forum built
with your favorite back-end language and now you want to build a client for it
(web, iOS, Android).

That basically means massive duplication as you create a json interface
boundary.

Yeah, you were already passing a { user, topic, posts } object to the
template, so you can just serialize it your json api, right? But you can't
because when you wrote that code, you knew the data never left the process.
You didn't need to scrub the user.password_digest. Adding an api on top of an
existing system is a lot of work no matter how much you hand wave about "well
architected software."

But forget over the air network boundary. How about just wanting to implement
the view layer of your Rails app with Go one day? How exactly would a "well
architected" Rails app help you out?

The truth is that one reason that SSRs are simpler is because they are
monoliths which spares you from certain classes of concerns. That's the trade-
off you have to pay for if you want to cleave the monolith one day.

~~~
Boxxed
It sounds like you're assuming the SSR is _not_ well architected and then
using that assumption to prove your point. It's pretty easy to have an API
layer interal to your application -- have your view templates consume that
API. No reason you have to have your view templates across the network,
written in another language.

~~~
hombre_fatal
No, what I would say instead is that 90%+ of SSR apps aren't architected like
that, so I would accuse you of the same thing: that you're using "well
architected" to describe what's actually an exotic configuration that nobody
refers to when they talk about SSR, basically creating microservices on
localhost that hit your own network stack which is a premature abstraction for
most cases that I thought you just got done lambasting in your OP.

~~~
Boxxed
Who said anything about microservices on the local network stack? You don't
need to do that to separate the layers; just have them be separate logical
layers in your application. This is common enough that I almost think we're
talking about different things: people have written APIs and SSR apps for
much, much longer than SPAs have been around.

------
inapis
What’s the harm in using rails purely as an API? You’ll still get a lot of
functionality out of the box and maybe have to write just a little bit more
glue code for the JS-backed front end than what rails provides out of the box.

~~~
splap
That's what we do. Rails mostly just a json api, with a React front end.
Devise handles auth. Useful gems in models and services, sidekiq doing its
thing... Happy with the setup.

~~~
rashkov
As far as I know, there's no official way of using Devise over a REST API. It
is designed with a server-side Rails app in mind. There's devise_token_auth
and related client libraries, but I wish there was an official way for
handling authentication for single-page apps. Every time I look into this
issue, it seems like there isn't much going on in this space. Then again,
maybe the entire authentication protocols space is like that, and it's
actually Devise which is in the unusual position of being a de-facto
standardized way to do auth in the Rails world.

~~~
rohan404
It's true that there isn't an official way to use Devise over REST, but then
again Devise isn't even the official way to manage auth in Rails apps - it
just happens to be the de facto one due to community support. That being said,
by using something like devise_token_auth/simple_token_authentication and
devise-two-factor you can have a token based auth system with MFA ready in a
matter of minutes. Personally, I don't think there are really any back-end
frameworks that have an official way to handle auth as it's always based more
on community consensus.

~~~
james_s_tayler
ASPNET Identity and Spring Security to name a few.

~~~
chasd00
I'd just like to say Spring Security has come a LONG way. It use to be a maze
of madness and frustration but now is fairly straightforward.

Also, Spring Boot saved that whole organization from irrelevance. It took a
huge amount of effort to just get hello world on the screen prior to Spring
Boot.

------
laurentdc
> I’m not suggesting that we give up React and es7 and go back to writing
> server-templated web-apps like it’s 2012 again.

My team is still building server-templated web apps with Django, RoR, Laravel.
It's just that most software we make is some sort of CRUD application and
React/Redux feels like overengineering, and still a mess when it comes to SEO.
Clients are happy and ultimately don't care. Should I be worried?

~~~
epse
No. Your solution works and makes people happy. That's fine

------
ajsharp
Yep, 100%. In the process of converting a node/typescript API to rails. I'll
never make this mistake again.

~~~
koolba
You’re going _from_ TypeScript to Ruby?

Having tasted the joys of static type checks combined with a unified
front/back data model, IMHO, that’s unthinkable.

~~~
mostlysimilar
> joys of static type checks combined with a unified front/back data model

Would you mind elaborating on the specific benefits?

~~~
koolba
With TypeScript you can define a single set of interfaces shared by both your
client side and server code. If you change an interface to return a different
value or rename a member, you immediately know where it’s used and can update
it in tandem. Static type checking let’s you know everywhere that something is
used without a battery of tests running through your app.

This takes 99% of the fear out of refactoring and expanding APIs which leads
to incredible agility in adding features to an existing code base.

~~~
xkcd-sucks
You get all of that for free with Java, plus you don't have to use javascript

~~~
simplify
You also get nullable types with Java, which severely cripples the confidence
static typing is supposed to give you.

------
sergiotapia
Ember was rails on the frontend. Still chugging along I guess, but honest to
god I haven't seen a soul use it in the past three years. Anywhere I worked,
anywhere I asked.

I'm using Phoenix and Elixir these days instead of Rails. But I've also been
circling back to C# after 9 years of not using it for anything. C# has become
to so incredibly open that you can write C# code and build static binaries for
Linux, Mac and Windows, with single commands. Definitely check it out if you
want something like that under your toolbelt.

The fact is, the javascript ecosystem is a house of cards. Most definitely the
worst ecosystem I've ever used to write software. I sometimes wish a
competitor to NPM launched with better organization and rules. NPM is insane,
in all the worst ways. Google the left-pad incident. We need JS so we're stuck
with NPM I guess.

Maybe with Phoenix LiveView we can get away with _less_ JS - maybe...

~~~
chusk3
Promise liveview is such a cool concept. I'm keeping an eye on the repo to try
to translate the concepts to my languages Pheonix-clone, Saturn.

------
_hardwaregeek
Seriously, do people _like_ writing boilerplate or something? Whenever I write
a non Rails backend, I keep on thinking about how easy, how fast this would be
done in Rails. Like I'm writing a backend right now in Rust, and while Rust is
an excellent language with lots of ergonomic features, it's not a tenth as
fast or fun as Rails. It's quite depressing to be writing a bunch of Rust code
only to remember that this would be done in a few minutes with Rails (albeit
with half the safety).

For instance, let's take writing a simple RESTful API. With Rust and Rocket, I
need to build up the file structure, start writing controllers to fetch the
different resources using diesel, figure out connection pools and how they
link with Rocket fairings, then find I need rocket_contrib in order to
automatically serialize to Json, then write out all the same routes (/
GET/POST, /:id GET/DELETE/UPDATE, etc.). Meanwhile in Rails I type `rails
generate scaffold article title:string content:string`. Boom. Done.

Several times I've found myself thinking about ways of making my development
experience better in Rust. Maybe I could write some macros that fix my
problems. But then I'd just be reinventing Rails' metaprogramming. Ah well. I
guess sometimes we need to reinvent the wheel.

------
namelosw
I've known rails for years but haven't yet used it seriously. I felt it's good
because setting up is easy and the velocity is high.

Until now I use it every day and I found it's really great and better than my
previous impression:

1\. Compared to JS there's always a specific way of doing things - how to
validate, how to dispatch async Job, how to send emails and real-time
notification etc.

2\. Compared to Spring there's only a recommended default way you can easily
start with. You don't struggle with SpringWeb vs WebFlux, different JMS
implementations, Hibernate or query builders, etc.

~~~
baroffoos
>1\. Compared to JS there's always a specific way of doing things - how to
validate, how to dispatch async Job, how to send emails and real-time
notification etc.

This is so important. When doing something on rails you always get
instructions on the exact things you have to do where as JS always seems to
either give you 500 different versions of the instructions or just expects you
to work out how to set it up based on everything else in your project.

~~~
mikewhy
I mean, we're comparing languages to frameworks here. Of course there's going
to be multiple different solutions for a language while a framework will have
fewer.

------
sixothree
> Do you need user accounts with signup / login / forgot password emails /
> email confirmation? Install devise and you’re done.

I don't understand why these types of features are so sorely lacking on other
frameworks. I was looking for a simple user management dashboard for MVC and
maybe my google fu was lacking but I just could not find anything easier to
implement than spending a day writing my own stupid dashboard...

------
jaequery
I actually dislike RoR but I'm at the same conclusion as OP. There is just
something about Ruby that makes me want to keep going back to it. It is
difficult choice when given the fact that JS is (and probably always will be)
the de-facto language for the web so it's really hard to dismiss Node. But if
that wasn't the case, I'd stick with Ruby all day.

~~~
burlesona
If you really like Ruby but don’t love the “magic” side of Rails, you should
try Roda and Sequel. The whole ecosystem built by Jeremy Evans is a joy to
work with.

~~~
jaequery
I actually like working with plain Sinatra and Sequel. I've created something
similar to RoR using it (github.com/jaequery/jasis).

As for Roda, idk why but it just doesn't click with me.

------
KaoruAoiShiho
Rails is just very high level. The comment on meteor makes it clear why a
Rails didn't exist in JS-land. Because the fundamentals are so dynamic and so
in flux it becomes hard for a high level framework to gain traction when it
can become outdated so quickly (though meteor was a particularly incompetent
try at it and that's not the only reason for its failure). Once the community
grows a stable low level stack then a Rails-like will inexorably emerge imo,
but I have a feeling that React is not at that stage yet.

~~~
tim333
It's kind of interesting looking back on "Why Meteor will kill Ruby on
Rails"(2013)
[https://news.ycombinator.com/item?id=6642893](https://news.ycombinator.com/item?id=6642893)
article cache:
[https://webcache.googleusercontent.com/search?q=cache:DnlIzC...](https://webcache.googleusercontent.com/search?q=cache:DnlIzCttYw0J:https://differential.com/insights/meteor-
killin-rails/+&cd=1&hl=en&ct=clnk&gl=uk)

------
olavgg
I love Rails vision about how to do full stack web development. It is a really
good abstraction, that hides unnecessary technical complexity and lets you
focus on solving business problems.

A lot of people here complains about Rails performance, and that is one of the
reasons why I use the Grails - Java framework. It is not as polished as Rails,
and has a few sharp edges, and it has a much smaller community which is still
super-friendly and awesome. Grails however can still take the advantage of the
enormous Java ecosystem. You have a library for about _everything_. And many
of them is of really high quality too.

I have for the last five years built three successful startups with Grails,
where the last one now employs 100 people. Grails has been really helpful
here, as it has made it possible to move fast and add,fix,improve,break
changes quickly. For my last startup Rails would most likely have struggled
with the amount of data we are dealing with, while Java is hardly sweating. It
is not something Grails specific, but still a part of the Grails application,
that is why I mentioned Java.

My last startup, which now employs over 100 people didn't use React nor
Angular either in the beginning, just vanilla Javascript. More speed, less
complexity, less errors and so on. We use React today, but that is because new
employees really really wants to work with. And developer happiness is really
important.

~~~
lame88
You may gave gotten into Grails at a better time. I more recently attempted a
project in Grails and it was a disaster. In fact it was my worst framework
experience ever. Mainly because completely inadequate sources of information.
Grails 3 had been released but the documentation was terribly incomplete so we
had to spend a lot of time searching and about every bit of info we tried to
look up returned results strictly for version 2. So some really basic things
we just never figured out how to do. I’ll never touch it again.

~~~
olavgg
I have used Grails since version 0.42 and I am a bit surprised to hear that
the documentation has been incomplete. I have always found it very detailed,
though sometimes lacking clarity as any framework documentation would have.
Since the early days, the way you build Grails application has been almost
identical to how you write and structure your code with the upcoming 4.0
release. Of course if you have used some plugins that has been unmaintained,
that could have caused issues with upgrading. But otherwise I have had a great
experience through Grails lifetime.

And if you really needed to get "out of Grails", there has never been an issue
using the Spring MVC api or Spring Boot with Grails 3+

~~~
lame88
It is still now distant enough that I can't recall specific examples, but what
I had found is that the solutions in blog posts etc. on Grails 2 (large
majority of search results) did not apply to or did not work with Grails 3
when we tried them, unsurprising given a major version change, but frustrating
nonetheless. I suspect that since you were following Grails's progression from
such an early stage, any incompleteness or lack of clarity in the
documentation may have not been so obvious to you because you would have been
able to implicitly fill in the gaps, but we as newcomers found it totally
inadequate. It was often reduced to black-box trial and error.

------
throw2016
Having just deployed Discourse and Diaspora its obvious Ruby and Rails was not
designed for end user use. There is complete and total dependency hell and a
hard requirement for a build environment for basic app deployment.

This kind of engineering directly leads to endless wasted hours
troubleshooting errors, routine build fails and apps that think nothing of
pulling in hundreds of dependencies that in turn have their own dependencies
that can fail at any time.

This is plainly wasting millions of man hours of end users time if its not a
SAAS app. Compared to that Go is an ode to simplicity, PHP just works, Python
is relatively painless and even Java causes little stress. Its node and ruby
that seem to be designed by people who revel in complexity and have zero
concern for deployment and end users.

------
rebhdm
I don't use rails, but I agree with sentiment in general. I first learnt
front-end stuff with desktop UI libraries and I hated it. Creating UIs with
programming languages sucks. The first time I used the web environment, I
really enjoyed it and it was the reason I decided to focus on programming for
the web. I was using PHP and server-side rendering, with some javascript to do
some interactive things. I liked that the design aspect (html and css) was
completely separate from the programming, and that there were no compile
steps.

Then eventually the requirement for more application-like experiences led me
to adopting client-side frameworks because server-side just wasn't able to do
those things very well. I like the idea of a json-based api talking to a
client application, but the client-side libraries have bought back all the
things I hated about desktop UI programming.

I think html is great and should be left on its own, not combined with the
programming language. That is the reason I don't like React. I can't read all
of that jsx/pseudo-javascript together. It looks like a mess. Vue is better,
but it is just a big hack of stuffing things into html attributes. Both of
them also require a compile step if you want to use them to their full
potential. So now all the things I hate are back, and I don't like web
programming anymore.

------
ravenstine
People always forget Ember.js, like it's some relic of the past, despite it
having very active development and a toolchain for a consistent Rails-like
experience on the frontend. There's no reason why you can't use React or Vue
components inside an Ember.js application if that's what you prefer.

As much as I've grown to despise the Ruby community for relying too heavily on
metaprogramming and inheritance, leading to abstraction hell, I think Rails is
still a great framework for serving web pages. Just because it's not the shiny
new thing doesn't mean it can't do most of the things we want from it(not
every company is FAANG scale), and there is still an abundance of Rails jobs
in 2019.

------
ernsheong
First of all, you should use the right tool for the job. Having said that,
Rails kept giving me the icky feeling. What you gain in speed of development,
you lose in performance and server costs and all sorts of crazy gem meta-
magic.

My current middle-ground stack is Golang API (I use go-chi) + (LitElement
front-end (web components) + Redux). I'm kinda happy, though my gripe is with
Go sometimes, not the stack.

To the far right where people are complaining on: React + GraphQL, etc. Well,
I think you went into the deep end, so rightfully you think about veering back
left again. But hey, there's a middle ground that is more "standard's based".

~~~
hombre_fatal
I tend to describe my issues with Rails in a nutshell: it felt like everything
was optimized for day 0 instead of day 30 or 300.

Devise was the ultimate example of this. `rails generate devise:install`.
Instant authentication system with almost zero changes to your code base.

Yet now something as central and important as authentication is implemented
outside of your application in some highly abstracted software. To do
something as simple as figure out the name of the cookie it sets, you have to
either dive into its internals or look at the actual cookie it sets instead of
just reading code that should've existed in your code base.

Rails was the first "language" I learned so I was its best case subject. It
was able to indoctrinate me in the beauty of metaprogramming and things like
that. Yet that still wasn't enough to keep the light from shining through the
veneer when working on a real world projects where you just want to know how
something works by reading application or glue code, not daisy chaining
through a bunch of library code or hoping you cache-hit the library's FAQ so
you don't have to deep dive.

There seems to be a lot of "why is there no Rails in {JS,Go,Rust,Clojure,...}"
lately and it's no surprise to me why there isn't. The same reason Ember and
Meteor never took off to the degree that React did.

There was some sort of "glue code just isn't that bad" renaissance.

~~~
JohnBooty

       > Rails was the first "language" I learned so I was its best case subject. It was able to indoctrinate me in the beauty of metaprogramming and things like that. Yet that still wasn't enough to keep the light from shining through the veneer when working on a real world projects where you just want to know how something works by reading application or glue code
    

I think the hidden magic is the worst part, but after a while I got pretty
good at simply diving into various gems to see where the magic's happening (or
failing to happen) and I don't mind that aspect now.

pry is an awesome tool. Put a `binding.pry` breakpoint in your code, do a
`show-source Foo.borked_method` and explore from there.

Also, popular Rails-related gems tend to have good tests. I learned that those
tests often demonstrate things that the docs don't.

------
rubyfan
The current javascript landscape reminds me of PHP circa 2003 + isomorphic
single page madness + functional philosophical purism + dreams of type safety
+ <new fad here every six month>

Yuck.

~~~
chessturk
The similarity of Hack and TypeScript support your argument.

------
rajangdavis
Is there a modern Railscasts?

I feel like the Rails community owes a lot to Ryan Bates for pushing out high
quality content and keeping up to date with Rails for as long as he did.

~~~
digitaltrees
gorails.com and driftingruby.com

~~~
excid3
Thanks for the recommendation of GoRails! I started screencasting a few years
back because I missed Railscasts and learned just about everything from Ryan
Bates. Wish he was still around in the community.

If anyone ever has suggestions on Ruby / Rails topics to cover, let me know!

------
rco8786
Rails is still very much alive and popular, this is kind of a weird take.
Server rendering is also very much still a thing.

 _But_ I do agree that it seems the JS ecosystem is missing a real Rails
equivalent. Specifically an ORM that is as robust as ActiveRecord. I've often
thought about building this myself, and then I remember I have a family and
full time job.

------
andrewstuart
>> I’m not suggesting that we give up React and es7 and go back to writing
server-templated web-apps like it’s 2012 again

Actually I have gone back to server-template development using Django for
selected projects, after many years working with React, which I still love.

Server side templated development with Django can be extremely fast in terms
of development time, very direct and effective.

There no need to use React for all the things.

Sometimes React is the right tool, sometimes server side templated is the
right tool.

------
brentm
Rails with Webpacker is the best of both worlds IMO. Ruby is a pleasure to
write and Rails saves a ton of time. There are just so many things that Rails
does that you forget about until you start putting together a Node app.

------
dpods
Every single example the OP laid out is solved by an official laravel package.
People love to hate on PHP but I can spin up a laravel app with all of those
features in a matter of hours.

I can build a traditional server side rendered app or I can use the front end
scaffolding to build an API driven SPA based on vue or react.

~~~
aosaigh
I think you're missing the point. Rails == Lavarel == Django in the context of
the discussion.

------
sjellis
I think that Buffalo is actually the most credible replacement for Rails that
I've seen:

[https://gobuffalo.io/](https://gobuffalo.io/)

The lead developer is a ex-Rails developer with a very keen sense of what made
Rails successful. One of the reasons that it's still pre-1.0 is that it won't
ship until the plugin architecture is good, which speaks to the point of the
article.

You don't need advanced syntax in the server code to write Rails
_applications_ , so Go may be a good fit for a Rails replacement.

------
jasonhansel
We need a framework that makes it easier to build server-rendered, multi-page
web apps with Node. Preferably something "batteries included," with support
for recent innovations in web tech.

~~~
AgentME
Next.js is pretty good, but could still be better.

~~~
jasonhansel
I'd like something focused on _pure_ server-side rendering, so that users can
have at least some interactivity (via <form> elements) without JS.

~~~
AgentME
Next.js pages do work for people without javascript too, and it's often paired
with something like Express that can handle form post submissions. The
Next.js+Express integration could be made smoother though.

------
thrownaway954
I keep looking at C# and Blazor myself

If you want an SPA type Rails way of doing things, you can use Turbolinks.
This talk at RailsConf 2016 is really an eye opener.

[https://www.youtube.com/watch?v=SWEts0rlezA](https://www.youtube.com/watch?v=SWEts0rlezA)

------
endlessvoid94
Every time I dip my toe into the node.js waters I recoil in horror at the
complexity of the defaults.

~~~
wzy
I can fondly remember me trying out a Node-based framework back in the day and
deciding it wasn't for me because I couldn't decipher an error that was
halting the application.

Then, I decided to delete the folder.

I remember watching Windows building the list of about 1GB+ of files to
delete. Only to have it try but couldn't complete the deletion process because
some file names were too long because of the recursive nature of folders and
dependencies in `node_module`.

Good times!

------
reustle
I recently started working with Django after not using it for almost 10 years.
It's really wonderful how nice it is to get projects up and running so fast,
and the Python community is stronger than ever. There are many integrations
with modern tools like Cognito and Stripe, and it automatically turns my model
definitions into an admin interface and REST API (with django-rest-framework).
I think I'll be sticking with it for a while.

------
president
There is a universe where there exists only 1 programming language and only a
single web framework. That would be cool to experience.

~~~
tormeh
There are many languages that work on both client and server. Most obviously
JavaScript/Typescript, but also Scala and Clojure. If webassembly really takes
off you can add Rust to this list.

I'm not sure how a combined framework for server and client side would work.

~~~
scns
Ocaml with Ocsigen or Bucklescript/ReasonML

------
neovive
Whether you use Rails today or moved on, many of the concepts introduced
and/or popularized by Rails can be seen in the current generation of popular
server-side frameworks across many platforms.

------
mvanduyn
I take modern to mean: Using latest state of the art techniques to increase
programmer productivity and happiness.

Rails is still the number 1 backend framework, and the RoR ecosystem is so
powerful that the [https://hyperstack.org](https://hyperstack.org) gem lets
you code in Ruby on the client, and fully access your AR models directly in
your client code (again all written in Ruby.)

You get all the maturity of rails, including be able to use Rspec to test your
server and client code in an integrated fashion.

Here is a blog post that shows how simply adding a 2 line AR model declaration
adds data persistence, and push synchronization to a "client-only" app:
[https://medium.com/@mitch_23203/the-exact-same-app-in-
hypers...](https://medium.com/@mitch_23203/the-exact-same-app-in-hyperstack-
part-ii-5b062074ec20)

If that is not "modern" I don't know what is.

Meanwhile the rest of the world is writing tons of boiler plate, creating
reducers, transformers, co-axial independent state repeaters, I don't know
what all, but the bottom line is you have to write a ton of code to get
anything done.

------
mnm1
The arrogance and ignorance of this post is massive. There is nothing wrong
with rails or django or symfony or any other server side rendered web
framework, whether it's 2012 or 2019. The author seems to think that somehow
react SPAs are the only modern apps. The case against SPAs is still huge and
for most use cases, they are the wrong tool for the job. This type of cargo
cult, fashionable trend thinking undermines his entire argument and questions
his qualifications as an engineer. There's no logical explanation for not
using rails or something like it. He's complaining about a problem with
literally dozens of proven solutions, including rails, that he's even aware
of, and yet refuses. What ever happened to use the best tool for the job
rather than what's fashionable and popular in 2019? I would not want such an
engineer anywhere near my company, that's for sure. I can't think of a worse
trait than knowing the right solution to a problem and deciding to use
something else just because "everyone else is doing it." Absolutely bonkers.

------
almostarockstar
If I understand the situation correctly:

Rails applications benefit from batteries included boilerplate because Rails
"owns" the whole stack.

"Modern" (contemporary?) JS applications benefit from separation of concerns,
and flexibility because each layer is interchangeable.

So how do we make this better? We can't reasonably split Rails up to match the
benefits of JS. The obvious (naive?) solution is to provide a protocol that JS
layers can follow. Specific packages/layers can decide to provide the protocol
which makes them interoperable. The developer may then pick and choose,
knowing that if they choose packages that comply with the protocol, they can
use the "batteries included" features.

It would be fairly trivial to identify the major features that most apps
reimplement. Getting it all to play well together would not be as easy.

As the OP described, I think Meteor was a great platform, but had some fatal
flaws. If "Meteor-the-company" was "Meteor-the-protocol" I think we would have
been in a much better position.

~~~
mvanduyn
I'm sorry but I am saying this all over the place on this thread.
[https://hyperstack.org](https://hyperstack.org) is a logical successor to
meteor but it uses Ruby (instead of JS) and Rails on the backend. However its
a complete integrated isomorphic stack.

~~~
grzm
> _" I'm sorry but I am saying this all over the place on this thread."_

Please stop. At this point you're spamming. It's great to be excited about a
project, but you're gone beyond that now.

~~~
mvanduyn
I'm trying to delete these but I don't see how. Sorry

------
ckluis
Elixir/Phoenix is the spiritual successor and includes a potential means of
minimizing the need for client-side JS with Live Views.

Check out:
[https://twitter.com/joerichsen/status/1109122286139965441?s=...](https://twitter.com/joerichsen/status/1109122286139965441?s=21)

------
aosaigh
No one here is talking about clients. One of the great benefits of using
Rails, Django etc. is that they are stable, very well documented, well
supported frameworks with a large ecosystem of libraries and developers. If
you are making an app for a client these will generally be much easier to
maintain than a bespoke Javascript stack.

------
xutopia
I think Rails is amazing. My only gripes with it are that tests run slow and
you need plenty of tooling to make things work (redis, sidekiq, anycable).

I have been particularly interested with Phoenix as of late as it fixes all
the gripes I have with Rails and Liveview is an amazing pattern that I think
would simplify a lot of things.

------
meow_mix
The ecosystem around rails was incredible. Really wish we could get something
equivalent with a static language

~~~
SkyPuncher
Static is my hope too.

We started with a Rails project two years ago. It's a bit slow, but dear god
we get so much done with it. That being said, having Typescript on the
frontend makes it so utterly clear how much better Rails would be with static
typing.

------
jaequery
Anyone know of a BetterErrors equivalent in Node.js with an actual REPL (live
shell) like in
[https://github.com/BetterErrors/better_errors](https://github.com/BetterErrors/better_errors)?

Or even a pry-remote equivalent?

------
k__
AWS Amplify is becoming the "Rails" of serverless.

It already has impressive code generators for GraphQL.

~~~
garren
I was just playing with Amplify the other day. I was super impressed with the
graphql codegen. I think the Rails comparison makes sense with the exception
of the vendor lock-in. I haven’t looked at the Serverless framework very
closely, but I know it’s not tied to AWS. I wonder if that’s a better
comparison to Rails?

~~~
mooreds
Serverless is more aimed at abstracting infrastructure, with small services
written in lambda/cloud functions/etc. So not really a rails replacement.

------
verdverm
Check out [https://apollokit.org/](https://apollokit.org/) for something
similar using full-stack JS

Sysgears has some other projects that is moving towards the ability to import
functional modules from npm

~~~
jamestimmins
This is pretty interesting, (not to mention it's a very aesthetically pleasing
page). It seems like we're possibly seeing the rise "meta-frameworks", which
simply provide a higher level of abstraction by combining multiple disparate
tools.

I work primarily on the backend, so this could be incorrect. But I'm curious
if anyone else has been aware of this trend, or if I'm identifying something
that isn't really there.

------
Aks21
I read your blog and I think that's why we still need Rails to keep other
frameworks on their toe.

Feature/Improvements introduced in Rails are constantly being picked up by
other frameworks but for some reason, people are ignorant about the progress
made by Rails in the last couple of years.

I use Rails every day at work and trust me when I say this, It is so easy to
get back to the code written last week or even last month(Of course Ruby plays
a big role in that). It is a big advantage when you do not have to break your
head every time you wanna review your code which is written some time back.

------
digitaltrees
What would be cool is a full stack framework that was built around GraphQL and
a SPA but that had essential packages for a broad array of features. Sort of
like when rails added REST but within and around the framework. The problem
with configuration would be solved if vue or ember or angular had an
opinionated server/api stack that was maintained and integrated more tightly.
Some people like configuration, that’s fine, lots of options out there. Others
like conventions and a unified end to end platform, lots of options for MVC,
literally none for SPA/API.

------
codyeatworld
It took me a long time to learn rails, it's very magical and makes many
decisions for you. If you constantly find yourself disagreeing or fighting
these decisions, rails will never be fun. Maybe this is why so many people are
against it, but I loved having a framework teach me about why it made these
decisions. To me, nothing comes close to vanilla rails app, after you learn
where and when to apply certain patterns it's extremely productive and fun to
use. You can get so much farther than you probably think if you haven't used
it in a while.

~~~
herbst
When I first looked into Rails I ended up learning Ruby because it was so fun
but Rails was overwhelming. After I got Ruby I found sinatra and my
fascination to use Ruby for the Web was finally born. After that I discovered
Padrino. Essentially sinatra packed with a ORM and backend.

When I then looked into Rails again (years later) everything felt so natural
and right suddenly. However beginner documentation also got a lot better so
this was surely part of it.

------
haney
I’ve been really happy splitting the difference between rails style server
side rendering and full client side JS apps using Django. I can easily build
REST or GraphQL endpoints for client side web apps to consume, but I have the
ability to easily render out server side templates for more lightweight pages.
Add to that that the python ecosystem is great for data science / data
engineering tasks so it’s easy for developers with different backgrounds to
cross over / reuse data model code between projects/tasks.

------
westoque
I believe we are at a turning point for the future of web apps and servers.
After using Firebase and serverless (I hate this term) technologies in the
last few, I didn't miss doing all what's said in the blog at all.

Need authentication? Just turn the feature on in Firebase and use it. Need
storage? Need analytics? Just do the same. The future is bright and we are
heading in the right direction. With this, we can get started on our apps with
zero configuration and just focus on features.

~~~
burlesona
This is also very expensive very quickly compared to the mileage you can get
running an application on AWS.

And if you pick a neat tech provider and it goes belly up (like Parse!) you’re
in some real pain.

------
vincentmarle
I could never get into Rails because of all the magic. “It just works” doesn’t
cut it for me, if I as an engineer, can’t understand exactly what’s going on
under the hood.

~~~
JohnBooty
After Rails' memory usage, I would say that the "magic" is the _worst_ part of
Rails. Wish I could have Rails, except a bit more explicit.

That said, with pry, it's pretty easy to dig down into the "magic" and see
wtf's going wrong when something is borked.

Despite that minor grumbling, I'd say that Rails is still darn good! It's very
mature framework (or perhaps more accurately, collection of frameworks) at
this point. You can get stuff done quickly.

Most things really don't need to be SPA, and many (most?) don't need to serve
up more than a few hundred or a few thousand responses per core per second.

------
revskill
Here's how i replace Rails with the "modern stack":

\- Compile Graphql schema into Typescript typings + Fragments for "Active
Record"

\- React Hooks as controllers action.

\- React Suspense for HTML rendering.

\- Apollo for graphql caching

\- ExpressJS for middlewares.

\- @reach/router for routing.

\- @loadable/component for code splitting.

\- Serverless for API.

I missed Rails, too. But i found that the "modern stack" is not bad at all. It
just needs more time to investigate to find out the best way to reuse
features.

~~~
rsanheim
Your post is a perfect example of why the "modern stack" is a horrible
developer experience (and lets be honest, probably crummy user experience)
compared to Rails.

~~~
revskill
You're absolutely correct at current moment.

I hope the DX will get better soon. But this stack beats rails on scalability,
universality, user experience, and many more. It's a trade-off that i found
worth the effort.

------
hezag
> There’s no longer a standardized way to get user accounts with a
> login/signup, [...] so instead we need to spend days rewriting this
> functionality anew on each project

I don't think that ever existed "THE standard way" to build web applications.
At the same time Rails was trend, for a lot of people the "standard way" to
build web systems was write it from scratch in PHP.

------
piyushpr134
I think one big mistake rails did was to tightly couple view side with server
side. This made sure tight coupling. If rails had a layer in between
controller and html (with a dumber html templating), with this middle layer
either spitting html or json apis, we would not need to get rid of rails

I too find react etc too complicated for a simple crud kind of app. Rails was
much faster to achieve the same.

------
perfunctory
> The world of tech moves fast, and there’s always new frameworks and
> paradigms popping up that make developers’ lives easier and allow us to
> build more and more powerful applications.

I wish people didn't start their posts with such proclamations. Why can't one
just go ahead and criticize something without first giving it a compulsory
doze of praise.

------
yakshaving_jgt
> I’m not suggesting that we give up React and es7 and go back to writing
> server-templated web-apps like it’s 2012 again

Why? What is wrong with that exactly?

Has the Internet fundamentally changed over the past seven years? I’d argue it
hasn’t fundamentally changed in the past _20_ years.

A single-page app isn’t a panacea, and in most cases is a bad choice for a
business.

------
0_gravitas
I haven't used rails myself, but I often hear that Phoenix is effectively
Elixir's version of Rails.

------
agar
I look forward to a comment section filled with passionate developers
rejecting the author's premise, and pitching their favorite framework(s) as
proof...

Thereby validating the author's premise that "the majority of the problem is
just a result of fragmentation in the modern ecosystem."

------
ai_ia
I have been dabbling with Elixir + Elm. This can be the next big thing, once
live view gets wider adoption.

------
jbverschoor
I don't miss rails. It's there and it's awesome. Can't wait till crystal is
far enough so there's better type checking, or for ruby to implement that.

And I can't wait for activerecord to be replaced by something like
objectmapper.. It makes a lot more sense.

------
ashelmire
>nodejs / typescript graphql backend and React / Apollo on the frontend.

So uh... I run a Rails / graphql backend and React / Apollo frontend. It's not
perfect, but I still think it's easier than running a complex node backend by
an order of magnitude.

------
m23khan
sure, you will miss rails if you are still working on monolith development
model (which is still valid in many cases) or if you want to have your Ruby
developers who can also do frontend work.

These days, frontend has advanced so much that either you are a minority who
is truly full stack and can do both backend and frontend work in good
competence otherwise, frontend has become a separate profession altogether and
for good reason -- it not only requires artistic capabilities, but it requires
good amount of coding now with plethora of frameworks/modules.

Rails is a great framework no doubt but advent of React/Angular along with
rise of microservice-oriented architecture has limited the footprint of rails
in job market.

------
novon
Rails is awesome! We’re hiring Rails devs in 2019 for our startup in Seattle.
We found a good balance of React and Rails.
[https://www.sharegrid.com/careers](https://www.sharegrid.com/careers)

------
rglover
[https://phoenixframework.org/](https://phoenixframework.org/) \+
[https://elixir-lang.org/](https://elixir-lang.org/)

------
rohan404
Ruby on Rails out of the box gets a lot of bad rep for being slow and non-
performant. Has anyone replaced MRI with JRuby or TruffleRuby to mitigate
that? Were there any significant "gotchas" with integrating it?

~~~
favorited
I did a POC getting a monorail running on JRuby (probably 6?) years ago. It
wasn't for performance reasons (though we _did_ have some GC issues, which
JRuby might have helped). It was because we had to integrate with some
services which only vended APIs via JARs.

The biggest dealbreaker was that (like most Rails apps) we had a ton of gems,
some of which had native extensions. JRuby doesn't support C native
extensions.

In the end, it was way easier (and a much less risky change) to spin up our
own Java REST APIs in front of those JARs, and let our MRI Rails app integrate
with them by talking to those REST endpoints.

Just for fun, I also tried using dRuby so an MRI Rails app and a small JRuby
(non-Rails) process could communicate idiomatically. It was cool, but I'm
pretty sure dRuby was eventually deprecated.

------
kissgyorgy
Not sure why everybody nowadays rule out Rails (or Django) like frameworks.
Not every web app need to be an SPA only! There are multiple kind of web apps
which I would still start with Django today!

------
maxehmookau
8 years in to my programming career, I still LOVE Rails. No other framework
I've come across lets me do as much quality work in a short space of time as
Rails does.

------
fouc
So what is the modern front-end equivalent to Rails or Laravel?

With clear outstanding options for authentication, image processing, and all
the other bits that are commonly needed?

------
readittwice
Ember? It's supposed to be a Rails-like JS framework.

------
cordite
For those in the JVM world, is grails good to look into?

~~~
debug-desperado
Groovy and Grails are still around but probably not as big a push anymore.

I would highly recommend JHipster to bootstrap a new Spring Boot app. It does
monoliths or microservices and gives you a great scaffold to build on top of.

~~~
jacques_chester
Spring Boot + Kotlin is a pretty sweet experience.

~~~
debug-desperado
I bet. After doing the Kotlin Koans I'm itching to get away from Java.

There is a JHipster Kotlin blueprint that generates the backend code with
Kotlin instead of Java. Can't wait to use it.

------
vasilakisfil
EmberJS with its addons is very similar to Rails productivity. React has some
pretty good drop-in components as well, but mostly are related to UI.

------
sneak
from TFA:

> _" Now, I know Rails isn’t universally beloved by developers, and I’m not
> suggesting that we give up React and es7 and go back to writing server-
> templated web-apps like it’s 2012 again."_

Why not, exactly? It worked well then and it works well now. Not everything
needs to be some 10MiB javascript bundle delivered to a late-model version of
Chrome served from a static bucket.

------
groundCode
I think Rails is a good framework. What absolutely sells it to me is Ruby. I
was a miserable C# developer. Now I’m a happy Ruby developer.

------
vmware513
Actually, Ember.js gives you the same experience for frontend development than
Rails for backend. So you can stay happy and productive. ;)

------
sandGorgon
There is opportunity for a rails like framework in Typescript and React Hooks
which is server-side first. A lot of the js/react frameworks are rich, client
side ..which need a little more conceptual thinking than a server side
rendered framework like rails (because you get into unnecessary complexities
of API,graphql,her,etc).

The other thing that's missing is db migrations - typeorm has decent
migrations, so that can be leveraged.

------
asattarmd
I believe Firebase + React is actually that. Yes, it's buying into a
proprietary system, but it is so productive working in that. Database is taken
care of, file uploads, authentication etc. are all taken care of.

It's not comparable to Rails in that we can't have plugins to install new
things that work with the entire stack, but whatever we have initially is
really good and I feel makes me very productive

------
joduplessis
There are tons of JS stacks that exist right now - Sails, Adonis, etc. - but I
feel they all miss having a hugely profitable business using them in
production. Rails had 37signals use it for all their products - along with
having DHH too.

Right now you have FRAMEWORKS being used in production at big companies, so if
you use React, Angular, etc. you know that you're in good company. I think it
would be super interesting having a large company roll out a full stack JS
framework that they themselves use.

~~~
yakshaving_jgt
This is an example of the Appeal to Authority logical fallacy.

Just because Google wrote Angular, doesn’t mean it’s good.

~~~
joduplessis
That's not at all what I'm saying.

------
stonewhite
This reminds me of the Rich Hickey keynote talk[1] at Rails Con 2012. Which
boils down to: just out of sheer convenience you no longer own your code and,
don't make the easy choice, take your time and make the simple choice.

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

------
b212
As a front-end developer I hated Rails, every day was a struggle working with
the project, it was so slow. It was around 4 years ago and I was using top of
the line Macbook Pro.

Our project wasn't badly written, it was just that slow. Is it better today?

I somehow ended up working with PHP-based back-ends but for smaller projects
and I sometimes miss Rails, because Docker for Mac...

~~~
scruple
You'd have to start by defining some things. Are we talking about AJAX
request/response cycles being slow? Are we talking about SSR request/response
cycles being slow? What was the app doing, CRUD? Something more interesting?

For reference, the Rails app that I am working on, almost literally right now,
is responding to HTTP API requests, performing authentication and resource
authorization, creating a background job (or 2 or 3), and posting an event to
kafka, in 2-3 ms. This is on my work-issued dev laptop from 2016.

If I start hitting the SSR portions of this same app, I'm getting response
times in the 70-80ms range pretty consistently across the 6 or so pages that I
just hit to get a quick baseline. No front-end frameworks here. Just
turbolinks, ERb, HTML, CSS, and sprinkles of ES6 (served via webpack(er)).

------
jaredcwhite
Oh gawd, not another one of these articles. I appreciate what the author is
trying to say, but the premise is just all wrong.

Repeat after me: Rails Is A Modern Web Stack. Seriously. You can do everything
you might imagine needing to do for a modern web app:

Need an easy way to create server-side rendered (SSR) pages that still behave
in a performant, snappy manner like all the cool kids? ERB + Turbolinks 5 is a
powerful combo.

Need to ratchet it up a bit with dynamic interactivity? Slap some Stimulus on
that SSR puppy!

Still not "modern" enough for you? Use React! Or Vue! Keep Rails operating
just as a JSON-flavored REST API.

Need to push commands from the server to multiple clients at once? ActionCable
to the rescue.

Need to offload long-running tasks to background jobs? ActiveJob + Sidekiq is
the bee's knees.

At any rate, plenty of us are developing "modern" web apps and sites using
Rails, Webpack, and other cool frontend tools, and it's going quite well. I
don't feel in the least like I'm missing out on something amazing or obvious
by sticking with tried-and-true, stable tools that have been my bread and
butter for 11 years and counting. DHH's philosophy of web programming may not
appeal to everyone, but for many of us, he continues to a voice of reason in
an insane world.

------
randomacct3847
You can use rails just as a backend. React, GraphQL, and Rails works fine from
my experience

------
lgregg
I'm currently building an app using Webpacker and Rails 6 edge, it's been
great.

------
JakeWesorick
We use Rails with the GraphQL gem and React/Apollo on the front end. Works
great!

------
jbverschoor
I guess the number of comments show how much love rails is still getting

------
matchbok
Couldn't agree more.

------
sgdesign
It's still small but a "Rails for JavaScript" is exactly what we're trying to
build with Vulcan.js: [http://vulcanjs.org](http://vulcanjs.org)

Built with Meteor, React, and GraphQL.

------
djaouen
This: [http://paulgraham.com/avg.html](http://paulgraham.com/avg.html) seems
somehow relevant to this discussion.

------
monksy
I miss Grails.

------
pythonwutang
Try Django Rest Framework with React

------
kristianp
Looking for the Rails of the modern web stack? Try asp.net core api +
AngularJS! /sarcasm. Sigh.

~~~
james_s_tayler
Close.

[https://aspnetzero.com/](https://aspnetzero.com/)

------
bobblywobbles
I agree.

------
codesushi42
I never liked Rails even when it was hip. Way too much bloat and magic behind
the scenes, and also poor performance because of that.

I always preferred Flask, because it gave you a minimal framework, allowing
you to cherry pick modules as needed. Sinatra looks similar if your preference
is Ruby.

I cannot say that a Node stack is better though. Both Rails and Node are
fairly awful, but for entirely different reasons.

~~~
bushido
When I first started with Rails/Ruby things felt magical. There is still
definitely a little magic, but with time I've found it to be less so.

Usually all it takes is to lookup the source (which is well
commented/documented) to see where the magic is coming from, the code is
fairly easy to understand. If it works well use it, or take what you like/want
and write your own methods, classes etc.

------
black-tea
I learnt to program for the Web in the late 90s. I used perl and later php. I
stopped in the early 00s because I found supporting IE6 was soul destroying.
Much more recently I got into it again and saw things like Rails and Django
and was amazed. It was like stepping in a time machine and seeing what I
always thought web development should have been. But the whole node, react
etc. model is nothing like that. It's a regression as far as I can tell. It
just makes everything more complicated for little benefit.

