
Why I believe Rails is still relevant in 2019 - mottiden
https://devbrett.com/2019/03/why-i-believe-rails-is-still-relevant-in-2019.html
======
mikekchar
I work on a Rails system. It's fine. Just like everything else is fine. I have
problems, but I have problems with everything else too (sometimes different
problems, but not always...).

I think my main complaint about Rails is that it's pretty heavy weight. Lately
we did a Sinatra app because we didn't really need anything that rails was
giving us. Fairly quickly I realised that I didn't need anything that Sinatra
was giving us either. Rack was fine.

I think especially after your app gets to be a certain size, you are either
writing your own framework, or fighting with the framework you chose at the
beginning. It's just the nature of the beast. From there it's more of a
training issue than anything else. You can hire "Rails developers" (or
whatever developers), but you can't hire people who are specifically trained
in a system you've built. Depending on the kinds of developers you hire, this
may or may not be a problem.

Personally, I like writing code and I like small, light systems that are easy
to move around in. Usually that means trying to avoid large frameworks.
However, not everybody I've worked with is comfortable with that experience,
so normally we pick things people have worked with before. Either way it's not
a big deal in the end.

~~~
danmaz74
Having worked with many different languages and frameworks over the years, I
have to disagree: when creating web applications, starting from scratch or
from a minimal base is massively slower, more error prone and less safe than
starting from a well developed and maintained framework, where so many of the
things you're going to need have already been solved and battle tested.

~~~
lmm
A summary of my experience would be: libraries are good, frameworks are bad.
(Indeed possibly the best "framework" I ever used was TurboGears which is very
deliberately just a collection of dedicated libraries, all of which you can
replace piecemeal as and when you need to).

Rails raised the bar for how little custom configuration should be necessary
to do a simple, straightforward thing. But it turns out being a framework is
not integral to that; modern libraries have been able to adopt the
"opinionated" (which seems to be just a fancy term for having sensible
defaults) approach of rails without having to grow into all-encompassing
frameworks.

~~~
monkeynotes
Can you give an example of a collection of libraries that you would consider
would compete with Rails?

~~~
lmm
On a broad level, Turbogears is such a thing. (On an even broader level, so is
my current preferred stack which is something like: Wicket, Akka-Http, Circe,
Hibernate, Liquibase, and Scala's native ways of doing DI). If you're asking
about Ruby specifically I'm not current enough to answer.

------
nitrogen
Popularity of a framework or paradigm seems largely driven by marketing and
memes. With "Rails doesn't scale" as the almost-rhyme that sticks in people's
minds, an entire tech cycle gets wasted on things that take significantly more
developer effort.

I've seen a Rails app handle Cyber Monday traffic for an ecommerce company
just fine, and I've seen JVM-based apps crumple under a fraction of the load.

Rails scales (see, that actually rhymes, so it _must_ be true), Ruby is a
really nice language to work in, and those things will remain true regardless
of whatever frameworks exist or whatever earworm sayings stick in the minds of
the next generation of developers.

~~~
rapsey
> Popularity of a framework or paradigm seems largely driven by marketing and
> memes.

I think a whole lot of developers choose technologies because they are popular
at the moment for two reasons: they lack the technical knowledge and
experience or maybe just confidence and/or they avoid some responsibility this
way (since everyone is doing it).

Of course this is most acute in web development because it attracts younger
developers.

Also the words performance and scalability attracts developers like moth to a
flame.

~~~
codetrotter
Not going to defend choosing what’s popular just because it’s popular but the
main argument for using something popular IMO is that most of the sorts of
things you want to do is likely to have been done by someone else already and
some of those other people will have written about their solution or made
libraries etc that you can reuse. Whereas if not many people are using
something then the amount of information you can find, even in the official
docs, is likely to be lacking. So you can save a lot of time by using
something even moderately popular compared to using something that few other
people use.

However, the caveat of course is that if you blindly choose something just
because it’s popular, or in spite of your own skepticism towards it because
you let the hype get to you, then it is very much possible that you end up
using something that is unfit for what you are trying to do and which even
though someone else has used it for the same purpose is going to lead you to
implement something that has poor performance, is too inflexible and/or has
other undesirable properties.

But really, the proper way to choose frameworks and libraries is to look at
the docs themselves and benchmarks and make your decision based on that. Not
to lazily use popularity as a proxy for estimating suitability/ease of use.

~~~
rgoulter
"popular tech is safe because someone will have done what you want to do" is
phrased negatively in this excellent opinion piece: with a new
technology/tool, you don't know what can go wrong. With boring technology,
there's enough community experience around it. [https://mcfunley.com/choose-
boring-technology](https://mcfunley.com/choose-boring-technology)

It also seems like 'boring = popular & old', 'hype = popular & new'.

------
rememberlenny
As an individual developer, I don’t know a platform and framework that lets me
do more with my time. I used rails recently for a new project to act both as
the backend for an iOS app, an auth management system, a asynchronous worker
manager, an upload manaager, and BI tool.

Combined with the mature gem ecosystem and clear mechanics for putting
everything together, I was up and running immediately, and was able to
continue adding features and refining without issues.

~~~
yedpodtrzitko
I replaced `rails` with `Django` in your statement (and maybe could do the
same with Node.js), and it reads the same. Guess it's just about being
familiar with a mature ecosystem you already know, and then you can achieve
results.

~~~
jypepin
Agreed. Although I do Rails and have no experience with Django I know Django
is the same.

To my knowledge tho, I do believe those are the only 2 framework that offer so
many plug-and-play, trustable component for everything, allowing you to be up
and running so fast.

I've built similarly large systems both with rails, flask and nodejs. Nodejs
environment was definitely the worst, on every front, and I coming back to
something like Rails always feels like I have so much more power.

~~~
ramraj07
As someone who's built a few apps in flask that have gotten quite big (but
still maintenable), I am curious to get your perspective on how big a
difference Rails gives - I have explored ASP.net and Django as options before
for projects and immediately (probably out of naivete) concluded that even for
simple apps I'll have to start modding the behavior of the components
sufficiently enough that it will give me a headache.

Hence I have generally stuck to using Flask and just quickly building a custom
version of any component that doesn't directly cause any security issues.
Thoughts? Am I wasting my time ?

~~~
pmontra
Coming from Rails, I spent some time with Django and Flask applications in the
last few years. There are noticeable differences between the two of them but
both are much lower level than Rails. The developer has more choices and can
make more mistakes. Projects can look totally different. On the other side all
Rails projects look pretty much the same and this make onboarding much
simpler.

To answer your question: you're probably wasting customer's money (unless
you're the customer) by implementing your custom components. You should use as
many existing components as you can find: they are probably better engineered
(dozens of teams at work vs one person - that included bug reports), better
documented and maintained and will live longer. Then you have to adapt much
like we adapt buying stock cloths, furniture, etc. But it's cheaper, faster to
deliver and usually good enough.

------
nathan_long
I spent a couple of years dreaming of getting paid to work in Ruby and Rails
and about 7 years doing so. There are many things I loved about Ruby, and
Rails brought a ton of good ideas to web development, as this post describes
(though I don't agree with all the highlights).

I've since moved to using Elixir and Phoenix, and then even more recently,
done some consulting on a Rails project. So the contrasts are on my mind.

My perspective now is that the advantages Ruby/Rails have over Elixir/Phoenix
(community size and number of libraries) are circumstantial, and the
advantages Elixir/Phoenix have (fault tolerance, concurrency, speed, less
requirement for external tools) are inherent in the VM.

Yes, speed of development and maintainability matter. And yes, you can write
good or bad code in any language. But if Rails taught us anything, it's that
defaults matter. And the default pattern in Rails is to use ActiveRecord and
rely heavily on model callbacks, which can get confusing quickly. ActiveRecord
also has no way to turn off lazy loading as far I know, and chasing down N+1
queries to improve performance is something I spent far too many hours doing.

My productivity also wasn't helped by the long test run times of Rails
applications, or by wasting time trying to optimize view rendering on a
heavily-used page.

All of those are either non-issues for me now or at least greatly reduced -
Phoenix view rendering is crazy fast, N+1 queries aren't possible with Ecto
and it doesn't have callbacks, Elixir test suites are highly concurrent and
generally fast (though driving a headless browser is still rather slow).

Performance and concurrency do impact productivity. And I find that "functions
in modules" is a great way to structure code and makes it easy to refactor. So
does being able to run the entire test suite faster than I can get distracted.

The best ideas of Rails, in my opinion, are present in Phoenix - things like
structural conventions, English-like naming, and database migrations. But many
of the pain points are missing.

Phoenix and Elixir aren't the One True Way™, aren't the best for every
conceivable software problem, etc. And surely they'll be superseded. But in my
opinion, Rails already has been.

~~~
emptyroads
I agree with a lot of what you've described, but 7 years of working in Rails
and you never figured out how to turn off lazy loading in ActiveRecord?

~~~
nathan_long
I know how to preload associations, but I don't know how to globally disable
lazy loading of associations. Do you know a way?

~~~
emptyroads
Hmmm, I don't want to assume too much (because of course everyone's project
needs are different), but that just sounds like a terrible idea. I guess there
are solutions like goldiloader (I've never tried it), but 99% of the time I'd
rather _not_ load associated records unless I use them. When I need to
load/use them along with many parent records, it seems pretty obvious that
I'll want to include those associations (eagerly loaded) in my AR query to
avoid N+1 queries as you mentioned. Then again, maybe I've just spent too long
taking those assumptions for granted where newer devs might not.

EDIT: After looking more into your claim that "N+1 queries aren't possible
with Ecto", I think I have a better idea for what you might mean. Perhaps you
don't want everything eager loaded, but you want an exception to be raised if
you try to access an associated record that hasn't been preloaded. I suppose
that's a fair point (probably good practice if having _any_ N+1 queries will
be a major problem in your project, or if subpar performance really is your
biggest threat), and no, I don't know of a way to do that in AR.

~~~
nathan_long
> Perhaps you don't want everything eager loaded, but you want an exception to
> be raised if you try to access an associated record that hasn't been
> preloaded.

Yes, exactly.

> When I need to load/use them along with many parent records, it seems pretty
> obvious that I'll want to include those associations (eagerly loaded) in my
> AR query to avoid N+1 queries as you mentioned. Then again, maybe I've just
> spent too long taking those assumptions for granted where newer devs might
> not.

You know that and I do too, but legacy Rails apps tend to be full of N+1
queries in my experience, and it's a major cause of slowdowns.

~~~
JangoSteve
Looks like the bullet gem does what you want.

[https://semaphoreci.com/blog/2017/08/09/faster-rails-
elimina...](https://semaphoreci.com/blog/2017/08/09/faster-rails-eliminating-
n-plus-one-queries.html)

[https://github.com/flyerhzm/bullet](https://github.com/flyerhzm/bullet)

EDIT: It looks like this was already mentioned in another thread. I guess I
don't understand the issue if that doesn't solve your problem.

~~~
nathan_long
The bullet gem has helped me solve this problem in specific applications
before, yes.

My higher-level problem is that having lazy-loading on by default allows N+1
queries to creep in to a code base and you need a third-party gem to find
them. I've had to spend significant time finding and fixing this after joining
teams with large legacy apps.

"Disable lazy loading globally" should be an ActiveRecord setting and it
should be on by default IMO; people who need lazy loading should have to turn
it on per query, something like `query.allow_lazy_loading(post: :author)`. I
suspect that a very small fraction of queries would use this, since many apps
don't do server side rendering, many who do SSR don't use Russian doll
caching, and even those who do both still execute many queries that should
prefetch all the associations they use.

------
anm89
I've never felt as dialed in and as productive in any other tool or framework
as I have in Rails. It takes all the unimportant BS, places it off to the
side, allows me to focus on what I want to build, and gives me the ability to
dig in deeper on the details when I want/need to.

The amount of projects I have seen go bad because someone did a bad job of
solving some problem that would have been a non issue in Rails is staggering.

------
bjoernw
Build your app using whatever you're most comfortable with because in the end
an existing product is better than no product. Will you enjoy spending an
extra hour per day working with this framework over another? That's an hour
more of progress.

Personally I think Spring Boot with Kotlin is a way better choice today for
monoliths that transition well to micro services. But if you're already deep
in the RoR world just go with that.

Running into stack or framework-related scaling problems is an honor and a
huge accomplishment. Those are good problems and there are many ways to solve
them, which will be extremely motivating at that point because people are
actually using your thing.

~~~
cageface
_Personally I think Spring Boot with Kotlin is a way better choice today for
monoliths that transition well to micro services._

What do you use for an ORM in this case? Is there anything comparable to
ActiveAdmin?

~~~
jillesvangurp
I recommend to not use an ORM. Really, with a modern language, an ORM is
mostly redundant. If on Spring boot, simply use JDBCTemplate and
TransactionTemplate to deal with raw SQL queries and transactionality. Get rid
of all the annotation magic around this.

Then you need a bare minimum of mapping code. Mostly this boils down to a
single line of code to call the relevant constructors while you extract
columns from your rows in a type-safe way. Kotlin makes this stupidly easy.
I'd argue this type of code is actually easier to maintain than misc
annotation cruft all over your codebase. One way or another you end up
expressing in some place that column foo is of type Int and goes into some
property of a class MyLovelyFoo with a foo field. So
MyLovelyFoo(foo=row.getInt("foo")) kind of does that in a really compact way
and there's not a lot more to it. Of course Kotlin having default arguments,
sane property handling, immutable data classes, etc. helps a lot. Mostly ORM
made sense when people were doing JavaBeans on Java.

The problem with many Java persistance frameworks is the amount of magic that
happens that leads to hard to understand bugs, sub optimal joins, and other
stuff that just isn't worth having. A side effect of using an ORM is also
overengineered table structures because people are pretending they are doing
OO and thus end up with way to many tables and columns, fragile and more
frequent migrations, and a lot of silly joins. This magnifies all of the above
problems.

If you know what you are doing, you can actually fix this of course and do it
properly even while using an ORM like hibernate. At this point you lose most
of the advantages of using an ORM because now you are knee deep into framework
complexity and trying to coerce it to do the right thing while spending
disproportionate amounts of time inspecting and guiding all the magic it does
for you. I've been parachuted in more than a few hibernate projects gone bad.
The fix is always pruning back all the copy paste annotation magic propagated
by juniors, vastly cutting down on the number of model classes, use of
inheritance and the silly hacks that come with that, fixing the
transactionality, etc.

~~~
imtringued
I have dynamically generated queries that span over 200 lines. Doing this
without a query builder is pure madness. It doesn't matter how modern your
language is, manually concatenating SQL shouldn't happen in 2019.

~~~
debug-desperado
100% this. Whenever folks recommend simpler options like JDBI, I have to shake
my head. Rolling your own query builder with string templates feels like an
SQL injection attack waiting to happen. If you know 100% going into a project
that you won't have to modify the structure of your queries based on user
input, then it's an acceptable option. But it's quite common, at the very
least, to have user input that results in variable number of terms in where
clauses.

Hibernate is quite powerful and the tooling in IntelliJ (or Eclipse) catches
many common mistakes at edit time. Where most folks get themselves into
trouble is with all the caching setup. Not surprising, but if you want to just
use Hibernate as a cache-less mapper there's always the StatelessSession
interface.

I also don't get the oft-repeated notion that ORMs result in bad table design.
You can map any tables you can dream up. And if you insist on doing
inheritance, Hibernate has 4 different strategies for mapping to classes.
Certainly one of those has the performance characteristics you're looking for.

------
shay_ker
Having worked w/ apps large & small on Django, Spring boot, and Rails, I'd say
that Rails is the easiest framework to be productive in, especially to people
new to it. This includes junior devs as well as senior devs - it's just easy
to pick up. And it gets easier to use over time to rip out all the cruft,
especially with things like Rails API.

Like any language/framework, it has its warts and its weirdness. There are
times when it can be very frustrating to deal with it all. But I've felt that
feeling working across multiple paradigms, and I'm convinced it's just a
reality of software development.

If you're deep into microservices, Rails can be a tough choice, I'll admit. It
really depends on your use case. A small-medium sized startup can get a lot
done with just a Rails app if your workload is primarily IO based.

------
geebee
This particular blog post did a fine job articulating the benefits of Rails,
and these remain good reasons to use rails in 2019. I think there's another
side of this discussion. There are reasons why _rails_ itself is worth using,
and then there are reasons why MVC frameworks + a sprinkling of javascript are
still worth using.

Personally, I feel that the latest trend toward heavy javascript front ends
that are more or less detached from the middle tier or back end has led to a
wildly overblown, over engineered state of constant technical churn. I quit
web development over this. I got involved in a project for a while, but
finally decided that if I had to write javascript in these constantly changing
frameworks, I didn't want to be a web developer anymore.

Fortunately, I have enough of a math and engineering background and work
experience that I was able to move over to writing code for answers more than
for applications, though code for answers can be used as a wing of an app. I
largely stay out of the framework now.

But I use python, not surprisingly. Ruby is a nice language, and Rails is an
excellent framework. I think that rails plus a little bit of javascript is far
more productive than the javascript churn, and for a lot of apps, you give up
next to nothing in terms of functionality.

But if I got back into web programming, I'd probably do what I described
above, but in Python. Ruby, for whatever reason, just isn't a big player in
data engineering, data science, scientific programming, machine learning, all
that. I haven't programmed in Django before, but much as I enjoyed Rails, I'd
probably stick with Python at this point.

Alternatively, if the javascript framework hamster wheel dwellers want to
handle that mess and let me write my wing of it in python and integrate it
however they please, then, uh, sure. As long as management understands that
when they quit, I won't be able to maintain it. A few people tried to get me
to use node, but I won't do it. I feel secure enough that the scientific
programming community will not be switching over to javascript so that we can
keep our programming language consistent with the shit show that is modern web
development.

~~~
andrei_says_
Just so you know, agree on all counts :)

------
mmartinson
I worked on a couple of production apps in Rails at the start of my career. It
was the first way I learned to make web applications.

Rails works as advertised and is great at what it does, but I think ultimately
the conventions-obsessed nature of the community, that is often so helpful,
has settled on some patterns that make the Rails approach more bother than
it's worth with other good options out there. Often touted for being able to
scale business logic and developer productivity at the expense of runtime
performance, I see some serious issues with the claimed strengths.

\- The powerful active record pattern and accompanying library makes it easy
to pile on coupling between business logic and database access code.

\- Ruby doesn't give you a straightforward way to protect against mutation,
which leads to some real debugging nightmares at the worst of times.

\- Rails conventions openly disregard low hanging fruit best practices of OOP
like the SRP, and make it difficult to design code that follow these practices
without straying outside the well trodden conventions (hi again Active
Record).

\- Rails provides configuration-like interfaces that don't feel like you're
calling Ruby code. They are convenient, but offload a big cognitive burden in
the name of convenience whenever you need to problem solved something that's
not a garden-variety bug.

Ultimately I made the time investment to try some other approaches and have
been finding that it's possible to get much of the productivity of Rails at
the (arguably worthwhile) cost of a bit of extra typing up front. If you know
Ruby well already and have some business goals with some urgency behind them,
certainly a great move. If you are earlier career and looking to invest in a
productive skills set, you may be better served to consider a few different
options.

------
wrestlerman
I thought same in 2018 when I didn't use Phoenix. But after trying out Elixir
and Phoenix, damn... Elixir and Phoenix give you so much, nice websockets,
concurrency, fucking easy to read code with great docs.

I was a bit sceptical about the praise Elixir was getting, but after working
with it for a while... I started noticing a lot of stuff that is lacking or
abused in Ruby and Rails.

~~~
cutler
Elixir looks great until you look at modulecounts.com where Erlang/Elixir libs
total a mere 7900. Compared with Ruby's 150900 gems that's a lot more code
you're going to have to write surely?

~~~
wrestlerman
That's a very valid concern. My personal opinion: Yes, the package system is
pretty small. That's why it depends what kind of project you are gonna write
and how much time you have. Ruby has a lot of gems, but many of them are buggy
and deprecated... Proof:
[https://github.com/rubysherpas/paranoia](https://github.com/rubysherpas/paranoia)

I think that Elixir is gonna catch up. If you write a project where you need
to use a lot of external libraries probably Ruby is better. If you don't need
to rely on the external dependencies too much and you want to/have to write
your own code(libs), imo, Elixir is a better option. It also depends on a
project, lots of external api calls, webhooks, real time chatrooms, etc. I
think Elixir is gonna be a better option.

One thing more, because Elixir's code is much easier to deal with, it's easier
to fork and fix deprecated lib than in Ruby(Rails).

It's just my opinion.

~~~
cutler
Another concern with Elixir is that, like Node, it is optimised for IO, not
computation. Take chatbots, for which Elixir is supposed to be ideal - what if
my chatbot connects to a computation-intensive AI/NLP model. I'm going to need
something else for that, surely? Elixir and Node are good for the
orchestration layer but lack the all-round capabilities of, say, the JVM
platform.

~~~
bluesnowmonkey
Elixir definitely comes up short on raw computation. However we've been very
satisfied with it for implementing a database. Use data oriented design (you
want that anyway) and move any CPU intensive part into a native function. It's
pretty straightforward to bind a C/C++/Rust library.

~~~
cutler
Considering the massive growth in AI that makes Elixir only half a solution
then unless you're good with low-level languages such as C/C++/Rust. Scala and
Clojure, on the other hand, are good for both computation and IO so I don't
really see the advantage of Elixir.

------
chvid
I think for what it is - for its paradigm if you will - ruby on rails is an
extremely well-designed platform. But I think things have moved on and what
was back then seen as the right way (or just fresh new way) is now seen
differently.

For example - is it really "better" to say 7.even? rather than isEven(7)?
(Strict OO vs multi-paradigm/functional programming).

Or is the article's example of a data model migration really better than a
series of alter table sql statements? (Putting OO on top of a relation
database using an ORM.)

And why not go for a pure SPA rather than an AJAX-sprinkled compromise between
a traditional server-side rendered html app and a SPA?

~~~
rimliu

      > For example - is it really "better" to say 7.even? rather
      > than isEven(7)?
    

Yes. And that has nothing to do with rails, it's just the Ruby way.

    
    
      > Or is the article's example of a data model migration
      > really better than a series of alter table sql statements?
    

Yes. Migrations provide much more than just altering DB schema.

    
    
      > And why not go for a pure SPA rather than an 
      > AJAX-sprinkled compromise 
    

I would love more people to ask themselves "do I really need SPA?" actually.

~~~
freehunter
>I would love more people to ask themselves "do I really need SPA?" actually.

And I'd love if people asked "is anyone actually doing SPA" beyond what
TurboLinks + a Vue frontend on a Rails backend would get you.

~~~
chvid
My point is rather if you are doing that (a hybrid app) wouldn’t doing a full
spa actually be simpler? And allow you to use a less complex framework / a
framework which doesn’t have to support that legacy.

~~~
freehunter
You're going to need to define a "full SPA". Every SPA needs a backend, and
Rails is as good as any. In fact, Rails + Vue is, by any definition, a "full
SPA" as Vue is a SPA front-end framework and SPA only refers to the front-end
design. You can launch Rails in API-only mode so there is no "legacy"
anything, just a backend framework that has all the benefits of Rails while
still giving you the SPA front-end you're looking for.

I wouldn't even call it a hybrid, nor would I say it's any more complex than
anything else. Every SPA needs a backend, and Rails is as good as any.

~~~
chvid
By full spa i meant something where all ui is rendered on the client side and
the server only serves static files and a set of web services for whatever
business logic that has to run on the server.

------
gashaw
Ruby is great, Rails is good enough.

The main issue with Rails (it's the same with other frameworks) is that it
discourages from doing proper design. The only design decision you make is
where to put a piece of code, which is ridiculous ("Fat models, skinny
controllers" is a bad design heuristic.)

Following Rails conventions works for small (simple) applications, but over
time you arrive at a point where no one understands the whole thing. At this
point someone suggests moving to microservices, and all hell breaks loose.

~~~
richjdsmith
Adding a services directory with logic moved out from my models into POROs
helped a lot for taming the mess.

~~~
yebyen
Can you share a link about what you mean by this?

I went searching but came up pretty empty ... do you literally mean adding an
"app/services" directory, is that all? Where you put classes related to
external dependencies that aren't ActiveRecord?

~~~
nitrogen
I don't agree with the pattern discussed here and actually like smart models
(I want to tell my model "do the thing", not write and babysit a bureaucratic
coordinator service. But, since you asked, it's common in other frameworks
like Spring to have a "service" layer that sits between your controller and
model layers. The service layer has the logic, and the models are just
storage.

~~~
yebyen
That's common in Rails too. Except I don't think it's necessary to make it a
go-between.

Where controllers have simple interactions with models (which represent
database structures, and may have logic in them) you let the controller have
direct access to the model.

Models can grow to be too complex, this is where having a concept of named
"Concerns" can come in handy, even if you won't use them in another model, it
can lift some complexity out of your model and put it into a logical group.

Services, in my view, are akin to models. Some of them may use models behind
the scenes. More of them actually represent an external service, which might
be an external database that lives behind a web service, an API. Or it might
be an LDAP service. (Or it might be a command pattern)

I agree with smart models, if the complexity does belong to the model, then
why not let it live there. It sounds like the service layer you're describing
is a needless ceremony for "managing complexity" – I'll bet it was a concept
that was introduced to your group by an architect.

------
forty
I have this joke that I noticed ruby/rails developers seems to use a lot of
their extra time (which they get with the high productivity you seem to get
with rail) talking about how great ruby and rails are and how efficient they
are with it ^^

~~~
ck3g
Take a look at how many non-rails developers spend their time proving that
Ruby and Rails are dead.

~~~
freehunter
But that's not wasted time, they're just waiting for their async promises to
finally return so the page actually renders.

------
Arubis
Rails is still fine and appropriately boring (in a good way). Its issues are
well known by now, and it’s pleasant to work with for backend CRUD work.

What TFA really appears to be writing about is that doing backend work in
nodejs is a subpar experience. I have little trouble believing that. A more
interesting comparison would be to Django (my gut feeling is that Rails
compares favorably here), Phoenix (a different set of choices about how
opinionated to be on the data model, different base language with some
significant and relevant advantages), and other frameworks that one would
deliberately learn to replace Rails.

------
tmm84
My personal love for Rails is recent. I had been trying in my one to two hours
of spare time on weekends (I am busy with exercise/family/gaming/etc) to build
a simple website for my wife's company (simple crud stuff mostly). I found
that several ways I had attempted to build the site were time consuming to
learn/compile/test/demo/repeat. Even though I program for a living, starting
from scratch takes time and one/two hours per weekend is almost nothing when
it comes to getting stuff done. When the PC I was using for building kicked
the bucket and I got an old Macbook air, I tried Rails and within an hour I
had got most of the base moved from Spring Boot to Rails. I can't complain
about Rails. The time investment to usable results are there. I think Rails is
going to relevant like other web frameworks for a good long time.

------
LyndsySimon
I see nothing at all wrong with Rails - I find it to be a perfectly valid
choice in 2019, if that's what you want to use.

That said, I'm not a huge fan of Ruby in general. I'm a Pythonist, and don't
see that changing in the near future. Python seems more straight-forward and
"shallower" than Ruby to me, and there's less "magic". I'll even contend that
Ruby is a more powerful language than Python - but with the caveat that this
in fact is its greatest weakness.

The example that comes to mind for me is when I needed to flash multiple
alerts to the user using Rails; I re-opened the class Rails used to implement
the behavior and modified it to keep an iterable of messages instead of only
one. It was easy, sure... but what happens when the Rails class changes in the
next version? My changes not only weren't guaranteed to be compatible, they
weren't encapsulated from the parent class, and didn't define and verify its
behavior. I can totally see a circumstance where my class would appear to work
without error, but the underlying implementation might have changed in subtle
and unknown ways.

With Python, I'd have subclassed the parent implementation and wired my
subclass up to the application. RoR doesn't make this approach easy, and even
if it did, it's not idiomatic for that language.

~~~
temuze
I agree 100%.

Ruby follows Perl's philosophy of "there is more than one way to do it."

That sounds terrible! When you scale an organization, do you really want
everyone doing everything in their own unique way?

Python has a more practical philosophy:

> There should be one-- and preferably only one --obvious way to do it.

While this sounds a little fascist, it enforces consistency. It means that a
senior Python programmer will see code from another senior Python programmer
and say to themselves "yup, I'd make it exactly this way if I wrote it
myself."

------
etaioinshrdlu
Does any free web framework have something more thorough than rails' Active
Admin?

Django admin seems pretty unfinished by comparison. Haven't seen anything
actually better.

~~~
peteforde
I've tried to work with ActiveAdmin on several consecutive projects, and I do
not understand the draw. It's a fussy DSL that requires you work with your
data in a way that feels very un-Rails. You basically have to approach
building out your UX from the perspective of what the tool is designed to do.
This seems a shame, in the context of Rails - a framework that's actually
pretty great at getting out of the way in the right places.

Of course, there are people in this thread who prefer writing Rack endpoints
over the thorny complexity of Sinatra. You really can't make everyone happy
all of the time.

~~~
jypepin
I hate ActiveAdmin because of exactly what you say, but tbh it is indeed a
very powerful tool and still allows you to very quickly spin up admin pages
(to a certain limit, but this limit is pretty high). I yet have to find
something similar.

~~~
peteforde
While it is not a 1:1 replacement for the end-goal of a drop-in admin, I've
had some success with datagrid:
[https://github.com/bogdan/datagrid](https://github.com/bogdan/datagrid)

A good way to think of it is as a drop-in for the index view of many admin
modules, which is the filtering, sorting and pagination of tabular data. This
is the specific pain I want to be abstracted away... not the entirely
conceptual UX of my admin in general.

------
pankajdoharey
Sure its relevant in 2019, which is why someone had to write "Why it is
relevant", the last time i remember i read something similar about Spring
Framework and why it is still relevant
[https://www.theserverside.com/tutorial/A-Spring-summary-
The-...](https://www.theserverside.com/tutorial/A-Spring-summary-The-Spring-
framework-is-still-relevant)

------
StevePerkins
What is the Ruby community like in 2019?

I've spent the past 20 years primarily working on JVM-based languages. Being
told for about 19 of those years that my boring verbose tech stack stack is
obsolete, and going away from the business world any day now.

Most recently, that voice comes mainly from the Node.js community. But 10
years ago, it was a mix of Ruby and Python upstarts. I kinda saw those
languages and communities as two sides of a coin:

* The Python guys were the upstarts who leaned toward stability and practicality. Wore slacks and polos, or maybe t-shirts and jeans.

* The Ruby guys were more of the "move fast and break things" school, and favored aesthetics over performance. Had numerous tattoos, and shaved with vintage German double-edged safety razors and a badger brush.

It feels like Node took all the oxygen out of the room in terms of racing to
be the Java replacement. But how have the shifts affected the identity of the
Ruby community? Did they get older, mature, and come to resemble the Python
community culturally? Or are there still a lot of young people disrupting
things rapidly, and you just don't hear about it as much anymore?

~~~
KurtMueller
These are certainly broad categories you're putting people into. I'm a ruby
developer who wears t-shirts and jeans on the regular, have no tattoos, and
shave with a Gillette Mach 3 razor (lol).

I'm definitely older and more mature now but I'd don't necessarily think that
makes it closer to the Python community culturally nor that the two dev
communities were ever that far apart to begin with.

------
gjmacd
The author took a bit of a pot shot at NodeJS (which I do understand why). But
I think it's a bit naive to think NodeJS is any more complicated of a stack or
problematic as a whole than Ruby -- it's simply not. As someone that's moved
between many different stacks, once you're in that stack and being productive,
you tend to realize "oh, this is why this is a good stack." From the outside,
if you've never used the stack professionally, you tend to get skeptical.

But for me these days, there's very little difference between stacks as to
"what's better". For me it's mainly "best tool for the job and who are are
your carpenters?"

But these days, NodeJS seems to be the right choice for many of these jobs and
it's hard to sit here and knock it. Why?

Unfortunately, Rails suffers from what a lot of other Web stacks suffer from
-- the browser requires some level of JavaScript marshalling that all the
other stacks have transform to. When you can code on the server and on the
client in terms of the same language. It just makes the process cleaner and
far more manageable. When an object on the server is the same as the one on
the client. Your life just becomes a little less stressful.

And I love other stacks. I'm a Python fan.

But It's really hard to not embrace NodeJS when you've got developers who work
on the frontend (Maybe in React, Vue, etc.) and server developers who are on
NodeJS and they can speak together, moreover, work within each others codebase
and not kill each other.

That doesn't mean Ruby is a bad stack, it just means like all the other
stacks, you have to move data between the backend and browser and it's "Oh, I
need this change on the server, I'll have to wait for..." \-- no, you can do
that, if you've got the ability to code in JS, and you're a fullstacker, you
can do both.

~~~
dehrmann
> When you can code on the server and on the client in terms of the same
> language

This was the promise of GWT.

------
gumcreme
While reading this thread, it feels like a flashback from 2009 and now, I
remember what was my biggest gripe with Rails (next to all the bad parts
mentioned here in this thread):

It is the culture.

I really find the Rails culture odd or tbh, I utterly dislike it. I mean if
met a Go guy, he tells me all good with Go, it gets the job done but it has
its warts, the same with Rust, node, React and so on. People of other stacks
like their stack but it's not about life and death. Only Rails guys have these
issues and would start a flamewar right on the street and try to evangelize,
yell at me why Rails is (always) the way to go and imply that I am not just
wrong but also an incompetent developer. There were so dogmatic and when
reading such posts in 2019, they are still this way.

 _Edit: as expected I got downvoted and this is what I mean, they take this
too serious, Rails is their religion, Rails locked them in. Downvoting doesn
't bring your Rails back._

~~~
freehunter
Maybe this is because everyone has spent the last 10 years telling them that
Rails is dead, they're stuck to a dead technology, and Go no wait Dart no wait
Rust no wait Javascript no wait Node no wait React no wait Phoenix is better.

~~~
yebyen
Yes. Literally ten minutes before Amazon announced their Lambda support for
Ruby at this year's re:Invent conference, one of our lead architects who was
watching the livestream sent out (and I quote)

> I guess if you want to know which languages will dominate the industry going
> forward, just look at what Lambda supports.

> AWS Lambda supports code written in Node.js (JavaScript), Python, Java (Java
> 8 compatible), and C# (.NET Core) and Go.

Tongue firmly inserted in cheek, aimed directly at our large cohort of Ruby
developers, as if to imply that we're mostly irrelevant to the future of the
industry, and it shows in Amazon's lack of support for our ecosystems.

Then immediately following that message, Amazon announced they have added
support for Ruby... and PHP, and Cobol. And suddenly it's "I guess AWS is out
of the choosing business." I'm still salty about this, forgive me please. But
the refrain is tiresome, and it continues even today.

------
dawhizkid
Aren't some large at-scale apps still on RoR? AFAIK Coinbase, Shopify, Twitch,
etc...

~~~
bjoernw
Having to support a legacy RoR monolith and being happy with it are 2
different things. How many of those companies are now supplementing the
monolith with microservices in other stacks and are actively chopping up the
monolith? I know at least 2 of those companies are doing just that.

~~~
fyfy18
Right, but that's just because those companies have grown to a certain point
where it's hard to remain productive with a monolith. If you are starting to
have scalability issues it makes sense to rewrite key hot code paths in a
language faster than Ruby. That doesn't mean using Rails when they started out
was the wrong choice though.

~~~
lmm
True as far as it goes, but does Rails offer a compelling advantage over
higher-performance languages these days, even when starting out? Modern
compiled languages have closed the expressiveness gap with Ruby a lot in the
last decade or two. E.g. I find I'm just as productive in Scala as in Ruby -
if anything more so - so I'd sooner work in Scala/Wicket from day 1 (for use
cases where server-side rendering makes sense at all).

(I still have the problem of services growing too large and needing splitting
up - though the better isolation of a typed language means that point comes
later than it would in Ruby - but it's still nice to be able to split out a
module and keep the existing logic implementation rather than having to
reimplement entirely)

~~~
joelbluminator
That's quite hard to measure, how do you measure expressiveness? Or easiness
to grasp and get into? Take a CS graduate and have them build an app either
with Rails or with Scala, in which stack will they be more productive? That to
me will say a lot about a stack's productivity - because quality of
documentation, community, stackoverflow questions, 3rd party libraries,
general framework architecture etc etc etc..all those things are crucial for
productivity.

~~~
lmm
> That's quite hard to measure, how do you measure expressiveness?

How much code it takes to express a given idea. I was just talking about my
subjective impressions, but I'm sure one could count lines of code.

> That to me will say a lot about a stack's productivity - because quality of
> documentation, community, stackoverflow questions, 3rd party libraries,
> general framework architecture etc etc etc..all those things are crucial for
> productivity.

Depends on what kind of organisation you're in; in the kind of environment I'm
working in, how easy it is to get up and running for a quick prototype has
surprisingly little to do with longer-term productivity. To the extent that
you're actually doing novel programming work, how familiar the syntax is and
how available libraries are is actually much less important than how clearly
you can think about the problem you're actually solving, and I'd far rather be
using a cleaner language with fewer frameworks available. Of course in other
cases you're doing things that can mostly be solved by frameworks (indeed
that's the original idea behind Rails - it started out as a tool to make
stamping out repetitive crud apps easier, and it's very good at that) and in
that case the availability of those frameworks is the higher priority.

------
mark_l_watson
Off topic, sorry, but reading this article made me realize how much I miss
using the Ruby language. Except for maintaining a legacy web app that uses
Sinatra (and takes close to zero time to maintain/devops) work and customer
preferences have driven me to other languages. Ruby really is a pleasure to
develop in.

------
fouc
All the standard web technologies are still relevant.

MySQL & PostgreSQL are still relevant.

Redis is still relevant.

Ruby on Rails is still relevant.

Javascript is still relevant.

~~~
lmm
Disagree with all of those except Javascript (and that only as an execution
layer). All of the things that those technologies promised, we now have better
ways of achieving.

~~~
robenkleene
Yet here we sit in entire thread that’s the perfect place to discuss these
“better ways” of doing things and I'm seeing zero consensus about what those
better ways might be. Are other people interpreting this thread differently?

~~~
lmm
There's no clear consensus on which way is best. That doesn't mean there
aren't better and worse ways.

------
sidcool
I think Rails is fine. It gets you up and running super fast. GitHub, Heroku,
Basecamp etc. run on Rails and they are doing great. It's popular because it's
relatively 'low-code' than other language/frameworks. Ruby is quite simple to
get started with and Rails' convention over configuration philosophy gives a
lot out of the box.

Having said this, it's not all rosy. Rails does buckle under scale, hence
LinkedIn and Twitter had to gradually migrate to Scala(I think) based
platforms. This is more a problem with Ruby than with Rails. A huge Ruby
backend application becomes quite difficult to reason without a good type
system. It's not impossible, just more difficult than say Scala or Haskell or
Rust, that have very strong static types.

I am sure I am missing a lot in this comment.

~~~
KurtMueller
> A huge Ruby backend application becomes quite difficult to reason without a
> good type system. It's not impossible, just more difficult than say Scala or
> Haskell or Rust, that have very strong static types.

It also becomes difficult to refactor if you don't have a very good test
suite. From personal experience, refactoring an Elm application is way way
easier and more error-free than refactoring a Rails app.

------
ausjke
These days for new projects you may just use flask/django depending on how
complicated your application is. Python is top 3 language and its ecosystem is
getting better daily, meanwhile it leaves many other scripting languages in
the dust including ruby. Otherwise you can use a java framework or (maybe)
node.js?

Node.js no longer has a good framework anymore, express is "out of date", it
still can't do async/await and Express 5.0 is not actively developed. The MEAN
stack is pretty much gone. I wish there is something in the
javascript/backend/nodejs field that shines like Django/Flask as a framework.

------
SnowingXIV
I also work on a Rails system. It does the job and the nice part about it is
whenever I need to make tweaks I can easily dive into the code and implement
said feature quite quickly. There are a few services I wrote that have a bit
of overhead but that's my fault - these typically go untouched as they are
part of the backbone. I run this system on two different instances and I will
say the difference between a few thousand records and a few million records is
noticeable. There isn't any memory leaks that I could detect or n + 1 queries,
so I've kind of thrown my hands up. Most importantly though, it's been super
reliable. I'll take the slight delay for robustness.

Recently I went the other way and built something with Flask because I felt I
only needed something tiny (plus python and ruby are both friendly to read)
and kept hearing the negatives about monoliths. It started out refreshing
because I only added in what I needed but eventually this started to get a bit
annoying as it grew, I felt I was rewriting the wheel often, and I missed the
organization and forced convention of Rails. Not to mention gems seemed to
have more support and often were more recently updated compared to flask
imports. I now want to convert this over to a Rails application.

I think a lot goes into picking what to use, size of team, size of users being
served, verasility, and development productivity. It's not always only
performance at massive scale (you may never need to handle the traffic Twitter
does and if you do I think you're doing pretty well and can weather that
storm).

------
l33cher
Why are people saying stupid things like this? I'm doing rails 24/7 for the
past 5 years in MANY different projects and I can say its the BEST and very
relevant in 2019. I have to deal with other platforms written in different
languages/frameworks like php/laravel and I can only pity developers that have
to do that by choice.

~~~
Kiro
I very much prefer Laravel/PHP to Rails/Ruby and I'm mostly working with Rails
nowadays.

~~~
move-on-by
PHP even has static types now. I think Ruby is missing out by not supporting
static types. Python has it as well, and there are a couple different type
systems for JavaScript- TypeScript being the most popular.

I’m not saying all languages and projects need static types- but there are
several great examples of scripting languages that have successfully added
optional support for static types. After working on several large projects
with Ruby, type-less Python, and JavaScript - I have a major appreciation for
static types. I’m also a fan of compilers. Anyways, that’s my two cents on
Ruby these days. I think it’s a cool language and has a neat ecosystem- but I
think it could get a huge boost from static types.

------
philwelch
As a former Rails developer, I figured it would be worth mentioning reasons I
disagree.

> Rails is not the fastest framework in the world… but I will argue that
> performance is the last thing you should worry about when you want to scale.

> In my experience, NodeJS or projects written in other frameworks start to
> collapse architecturally after an alarmingly small amount of complexity is
> added to them.

> More important than how many requests you can serve per second, is how your
> development team can maintain productivity over time.

This is what we call dismissing the actual concern (performance) and instead
going on an unrelated talking point (maintainability). And frankly, legacy
Rails apps are not actually that great to live in. The Rails approach, which I
can best describe a “precious”, contains a lot of abstractions that don’t
actually abstract successfully, breaking down when faced with the real world
in ways that require ugly fixes.

> Where should we put files relating to our data model? /app/model!

> Where should we put our config? /config

> Our email code? /app/mailers

> Decision made. Conversation over. Now let’s get back to our desks and write
> some code!

If your backend consists merely of “data models” (with business logic and
behavior bolted on in an inflexible Kingdom of Nouns sense), routes, mailers,
jobs, and maybe response templates, Rails is opinionated enough. At least
until your business logic is complex enough that you can’t just use active
records as your sole method of abstraction. (Also, the active records
themselves are poorly conceived, with obvious foot guns that persist to this
day, though at least they’re better documented now. But more on that later.)

I usually find that the architecture I get from Rails is neither necessary nor
sufficient. Do I really need controller classes just to route endpoints to
handler functions? No. Do I need an ORM? No. Do I need HTML templating? Also
no. But I’m going to need more sophisticated design patterns than active
records. Decoupling data access from business logic is one of the first and
most important separations of concerns that exists, and Rails actively
discourages that. Another crucial separation is between work that can be done
locally (and hence unit tested) and behavior that entails a network
dependency, which includes DB access! Rails really leads you down a bad path
if you just naively follow the defaults, especially if your app is so
monolithic that my mailers and asynchronous jobs are in the same artifact as
my response handlers. (I’m not down on monoliths; Rails just does too much for
a microservice and not enough for a monolith. Hell, Rails does too much for a
macroservice let alone a microservice.)

> Database management is hard. Managing database schemas and migrations is
> hard.

> Rails provides you with a no-nonsense way of defining your database
> structures, as well as a full suite of CLI commands for migrating,
> resetting, seeding, dropping and creating databases across all environments.

> Rails handles databases in a ubiquitous way. There are database drivers for
> almost every popular database, and schema management and Object Relational
> Mapping is handled the same way across all data stores.

These are almost all false.

* SQL isn’t hard to use for schema definitions or migrations. The Rails DSL for database schemas is marginally prettier than SQL, at the expense of adding an extra layer of indirection and making you learn yet another precious Ruby DSL when, if you’re worth your salt, you already understand SQL anyway.

* Rails has an inbuilt assumption that your app connects to a single DB instance per environment. Cool, but why on earth would I connect to different RDBMS systems across environments (except _maybe_ in-memory SQLite for “unit tests”, which is already an anti-pattern?). And given this constraint, what exactly does ActiveRecord get me? I can wake up one morning and just port my whole app to Postgres without changing a single line of code? That’s not bloody likely in the real world and we all know it.

* Rails adds even more unnecessary brittleness to common DB access scenarios, which paradoxically means that the “simple” but broken Rails solution has to be augmented or replaced by ugly workarounds. For example, ActiveRecord validations are inherently prone to race conditions that make them both unnecessary and insufficient. From the current Rails guide:

> 2.11 uniqueness

> This helper validates that the attribute's value is unique right before the
> object gets saved. It does not create a uniqueness constraint in the
> database, so it may happen that two different database connections create
> two records with the same value for a column that you intend to be unique.
> To avoid that, you must create a unique index on that column in your
> database.

OK, so the uniqueness validation doesn’t guarantee uniqueness if there are
concurrent connections to my DB. Also, every real world Rails app is deployed
so it runs as multiple processes. So it never guarantees uniqueness. Instead,
I create a unique index, and ActiveRecord...sometimes throws an exception
that’s distinct to the RDBMS but not distinct to the failure mode, so I still
have to string match against my DB’s particular phrasing of “uniqueness
constraint got violated” and handle that as an unnecessarily generic Ruby
exception. Which is exactly the same amount of work that would exist if
uniqueness validation just wasn’t a Rails feature to begin with.

A thoughtful design would realize: at least some validation _has_ to happen in
the DB and not in the application code, and it will anyway, so let’s make
patterns for living with that. Why don’t my models automatically detect my
unique indexes and throw a “not unique” Rails exception when the DB complains?
Why does it instead insist on doing a shitty job of trying to guarantee
uniqueness itself? It gets worse and worse when you run into scenarios like,
“I want to run SQL queries that don’t cleanly map onto ActiveRecord without
monkey patching every damned column of the result set onto individual
instances of a loosely related ActiveRecord class”.

> Rails (and Ruby) Have a Deep Culture of Code Quality

Hah. I think I’ve already debunked that one. Rails has a deep culture of
precious, brittle abstractions that make easy things easier and hard things
harder if not impossible.

> Asset Management

If your app is monolithic enough that you’re managing your assets in your
Rails app, it’s probably big enough that you’ve run into the problems with
Rails I’ve mentioned earlier. If it isn’t that big, odds are you’re in a
microservice environment where your assets are most likely deployed in a
highly decoupled way—perhaps from a separate repo owned by your front end
devs. Maybe the asset pipeline is a perfectly reasonable way of managing a
full-stack monorepo, and you can still deploy your Rails assets to a CDN and
make it work. But that implies that your web app is a Rails monolith, and
Rails monoliths need a lot of thoughtful design decisions above and beyond
“put models in app/models”.

> RSpec is quite simply the gold standard for behaviour driven development,
> and almost single-handedly created the BDD movement that is still raging in
> the industry today nearly a decade later.

RSpec is nothing special. I actually find Spock a lot more featureful and
self-documenting.

> A Smorgasbord of Plugins

The first plugin on the list he links to is activerecord-import, which only
exists to work around a problem Rails itself creates in the first place. The
rest are either generic things that every other language has and other
instances of workarounds for Rails limitations.

Rails (and Ruby in general) isn’t unique in terms of library support. Python
has greater breadth, JVM has greater breadth, heck I bet you can still find
stuff on CPAN that never made it into a RubyGem.

> Heroku

Works with everything; not a selling point for Rails.

> ActiveAdmin

Admittedly, something like this is one of the few redeeming qualities of an
ORM, which is why Django always had this built in. Why not Rails?

The article keeps saying that Rails is “batteries included”. “Your app behaves
in a reasonable way without ugly DB-specific exception handling code if you
run more than one parallel instance of it” didn’t count as batteries either,
though. But I guess HTML templates did. Rails’ design choices would be logical
if you treat Rails as a framework for prototyping, but isn’t that when you
need admin screens the most?

> Rails is battle-hardened and industry-proven. There is a long list of (very)
> successful businesses building their product with Rails.

Starting with Twitter, which migrated away from Rails onto a JVM backend as
soon as they grew up. If you want to go with “battle-hardened and industry-
proven”, use the Spring ecosystem. You can even deploy it on Heroku.

~~~
TheRealDunkirk
> If you want to go with “battle-hardened and industry-proven”, use the Spring
> ecosystem.

Well, uh, there it is. </Goldblum>

As a Rails fan who was forced to use Java for a web application at a previous
job, I've been all over this whole topic, and even ranted about it on this
site a couple times. This is the conclusion I came to: some people like to
have things done for them by a framework, valuing the tradeoff of time vs.
specificity, and some people like to write a lot of extra code themselves,
valuing the precision that affords, at the expense of time.

The working example I took away from the exercise was that writing a simple
edit page with a nested model. It took me 3 lines of code in Rails, with a few
dozen more from the generators. (Cocoon is freaking magical.) In
Java/Spring/Node.js, it took me 160, and I still wasn't done. I needed
repeated classes, controllers, and services in 2 languages in 2 stacks. One of
the arguments I see a lot in this field is how people are fans of strict types
in the Java world. OK, but it seems to be a requirement to keep Java and
Javascript sorted, and is a non-trivial amount of work to keep in sync.

Some people get hung up on, say, race conditions of database validations, or
mock database transparency as useless, or argue about which ecosystem has more
plugins (Node "wins!"), and some people think it's ridiculous to duplicate 90%
of the plumbing, or hate having to deal with migrations manually, or find it
inconceivable that there's not one single canonical example of a working
Spring/Node CRUD app in a current version of the stack available on the
entirety of the internet.

To the last point: THAT is how fragmented the "Spring" world is to learn and
apply. THIS is the tradeoff in NOT being opinionated. In nine months of
pulling my hair out, I never once found 2 examples that did ANYTHING the same
way, and NOTHING was current and complete, not even stuff by Matt Raible. I
even contacted him directly, and the best he could do was point me at a GitHub
project I had never been able to bubble up with Google, which was 3 versions
out of date, and would no longer work the same way with current versions of
the stack.

To each their own. Horses for courses. Your milage may vary. Terms and
conditions may apply. It's almost like a "right-left" dichotomy of politics.

Anyway, I leveled up my career, and now I get to pick what tools I use. But,
yes, I'm still bitter on this topic. ;-)

~~~
philwelch
My point wasn’t to use Spring, my point is that it’s ludicrous to refer to
Rails as “battle-tested” when most people who test it abandon their Rails
prototype eventually anyway. My actual advice is probably that every stack
sucks, but some stacks at least get out of your way.

> The working example I took away from the exercise was that writing a simple
> edit page with a nested model. It took me 3 lines of code in Rails, with a
> few dozen more from the generators....

> Some people get hung up on, say, race conditions of database validations

Because those race conditions mean that your cute three-line edit page is
eventually going to turn into a hundreds-of-lines monstrosity if you actually
try to put it into production. Rails is a great rapid prototyping framework,
granted, but once you try and run a Rails app in production, you’re still
face-first in all the complexity Rails pretends to handle for you when it’s
just localhost:3000.

~~~
TheRealDunkirk
I've made at least a dozen LOB Rails apps for internal use at companies. I
also worked at a bespoke consultancy that made Rails sites for startups, and
I've seen dozens of Rails apps "in production," out on the open internet, and
making money for their owners. I think there may be some conflation here
between "production" and "Twitter- or Facebook-scale production." And I
wouldn't trust ANY framework to applications at that scale.

~~~
philwelch
Even for internal use, you have to worry about data integrity a lot of the
time.

> I also worked at a bespoke consultancy that made Rails sites for startups

Ah, so didn't have to handle the maintenance burden afterwards. I did. Rails
is awesome if you can just dump the maintenance burden on someone else and
move on.

~~~
TheRealDunkirk
Wha...? Honestly, the presumption on this board sometimes. I was one of the 2
people who maintained the apps on AWS. There were no issues. I guess we've
just had VERY different experiences.

------
belenos46
Man. I like two things. Boring languages/frameworks, and minimalism.

Boring languages/frameworks Just Work, and are usually pretty secure.

Minimalist --which is to say, making something as simple as possible, but no
simpler-- means fewer moving parts which can break in production.

90% of what my places of employment and clients need is the same old shit, and
I like to build it so that when something breaks, I can jump in and hammer out
the broken thing and get the process moving again without needing a ton of
research.

------
devin
Big no thanks on citing the wisdom of one “uncle bob”, but otherwise, yeah,
the framework is relevant if not dominant, and that’s just fine. Live long and
prosper.

------
smartstakestime
rails did the opposite of php , and I think its harder for it to pivot in its
community.

-php started with no framework , everyone just did super minimal strait to the db and template query stuff, very unorganized but you knew the underlying apis and tech because you were right up against them

-rails started very ridged. separating programmers from the underlying apis and tech

Now php devs had to create the ecosystem of organization but the experience of
working with the the server and db was still useful particularly when doing
something unique or when one needed special performance

Ruby devs needed to learn to become leaner how to break away from the
framework when performance was needed. This was completely new and I feel the
community did not support scripting away from ruby. Mostly the community was
focused around ease

also at the same time PHP was improving the language. I dont think Ruby had
the same improvement and some of the stuff I have heard about ruby makes me
cringe.

[http://rubylearning.com/blog/2010/09/27/almost-everything-
is...](http://rubylearning.com/blog/2010/09/27/almost-everything-is-an-object-
and-everything-is-almost-an-object/)

~~~
pjmlp
Also PHP benefited from Facebook's work and the commmunity actually cared
about performance. Zend exists since the early days, now there there is the
JIT migration going on.

On the other hand JRuby doesn't seem to be having that much adoption, and the
new pseudo-JIT via C compilation doesn't seem to be the best way to improve
it.

------
danenania
These days I find myself thinking of Rails as primarily a dsl for modeling
data in SQL. I still don’t think anything beats it for this purpose.

But all things considered, I think TypeScript/react/lambda with VSCode is now
a better choice for developer and devops productivity in both the short run
_and_ the long run. It’s still a good idea to follow many of the Rails
conventions though regardless of the language you use.

------
clessg
This article reads to me as more of a "Rails vs Node.js" piece, which seems
almost too easy—I would be interested in a more thorough comparison of Rails
versus other frameworks. Here I will attempt a comparison, limited in length
as this isn't a blog. :)

My personal favorite up-and-coming framework (and admittedly, my favorite web
framework overall) is Phoenix[1], written in Elixir[2], a functional
programming language with a focus on concurrency, performance, and developer
productivity. In my opinion, Phoenix has almost all of the best parts of Rails
without nearly as many of the warts, and adds a plethora of compelling
features of its own.

Despite what the author argues, I believe that raw performance and developer
performance are equally important, and even intertwined. Why? A slow
application results in lost customers and revenue, a fact that is well-
documented. A default Rails application is going to be quite slow, requiring
intervention. Of course, most larger Rails apps are not necessarily slow in
practice—in my experience, this is largely because the code is littered with
brittle caching logic and hacks requiring many human-hours to maintain and
debug when things go wrong. Thankfully, Ruby is seeing improvement in the
performance realm.

Phoenix achieves massive scalability, raw performance, and developer
performance, without requiring significant trade-offs and caching logic
littered all over your code. It is an absolute joy to write Elixir. Phoenix is
famous for consistently achieving microsecond response times without caching,
and being capable of holding millions of websocket connections[3]. Granted,
Elixir as a language is not computationally fast, but the typical web app is
not performing expensive computations, but instead juggling IO, which Elixir
handles extremely well. CPU-intensive tasks can be written in a different
language if need be.

Importantly, Phoenix is _not_ your application—Phoenix's job is to provide a
web interface into your broader Elixir application. Thus, Phoenix is more of a
toolkit than a framework, and yet it provides everything you would expect in
any web framework, with strong conventions based on the solid foundation of
Elixir. You could migrate to a different framework with relative ease. You can
easily integrate different interfaces into your application, such as a CLI
frontend. This is in contrast to Rails, where Rails _is_ your application
unless you actively fight against the framework.

Ruby and Rails are notoriously bad at handling concurrency and real-time
features using e.g. websockets. This becomes progressively painful as using
all CPU cores becomes increasingly necessary, and as websockets continue their
ascension on the web & mobile. In contrast, concurrency and soft real-time
communication are Elixir & Phoenix's bread-and-butter.

As I mentioned, Phoenix brings compelling features of its own. The most
interesting to me is the upcoming Phoenix Live View[4], which will allow
developers to write rich, interactive, real-time applications without being
forced to wade into JavaScript hell. Read the linked article for more
information. I could be wrong, but I don't see something like Live View making
its way into Rails, especially without significant downsides.

One area where Ruby & Rails trounce Elixir & Phoenix is maturity. Although
they have gained significant traction, Elixir & Phoenix are still
comparatively immature. Thus, you'll have a harder time hiring, finding third-
party libraries, and answers to questions. That said, Elixir is based on
Erlang, which is extensively battle-tested and has a huge assortment of
libraries available. (You can very easily and naturally use Erlang code in
Elixir.)

I could go on, but I think this has gotten long enough.

[1] [https://phoenixframework.org](https://phoenixframework.org)

[2] [https://elixir-lang.org/](https://elixir-lang.org/)

[3] [https://phoenixframework.org/blog/the-road-to-2-million-
webs...](https://phoenixframework.org/blog/the-road-to-2-million-websocket-
connections)

[4] [https://dockyard.com/blog/2018/12/12/phoenix-liveview-
intera...](https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-
real-time-apps-no-need-to-write-javascript) (Repo:
[https://github.com/phoenixframework/phoenix_live_view](https://github.com/phoenixframework/phoenix_live_view))

~~~
cpursley
Elixir and Phenoix absolutely blow away Ruby and Rails in terms of performance
and capabilities, and in my opinion, is just as elegant and productive (José
was part of the Rails core team, after all). I still appreciate Rails (it
allowed me to enter the industry), but just don't see the point of starting a
new project with it these days.

------
derekdahmer
Was anyone saying Rails wasn't relevant?

~~~
freehunter
All the people trying to sell you something else. I heard someone on HN call
it "blog driven design". Tech blogs need something to write about, Udemy
teachers need something new to sell, startups need some way to differentiate
themselves from their competition, so they start talking about how awesome
[insert new tech stack here] is. The cycle continues and in 6 months, [new
tech stack] is old news and you can't build the modern web with it and it
doesn't scale, so here's [even newer tech stack].

Meanwhile Ruby, PHP, Python, and Java are still powering all the sites that
are telling you those technologies don't work anymore, and powering the site
that takes your money when you buy another Udemy class to learn [even newer
tech stack].

------
lurker213
In my opinion, Rails / Ruby is nearly unbeatable in terms of productivity when
you add trailblazer to the mix.

~~~
peteforde
I love that Rails is flexible enough for me to both agree completely AND be
thrilled to not use Trailblazer, because I prefer interactor, state_machines,
rolify, pundit and draper. Considering the talk about how heavy Rails is in
this thread, I feel like I have all of the options in terms of customization
and in a very mature ecosystem that still values developer happiness.

------
danmaz74
Meta: I read this on the tube, and wanted to write a comment when in the
office. Came here, and it's well out of the first page, even if there were
many additional upvotes. I really wonder who hates rails so much to flag an
article about it, and why.

------
_hardwaregeek
I think Rails could go far if DHH et al keep their ears to the ground about
the state of web development and adapt accordingly. It still has some killer
features that I've yet to see replicated with as high a level of ergonomics
and elegance.

For instance, GraphQL in Rails is smooth like butter. You define the types and
the fields just resolve like magic based on your models. I wrote an API a
while back and it was just stunning at how easy it was to write. Only issue? I
wasn't using Rails. I was using all of the niceties of Rails like autoloading,
ActiveSupport, ActiveRecord, associations, etc., without the actual, framework
of MVC. If Rails could really invest in the API mode and get it working with
say, GraphQL, I could see it working amazingly.

Plus, you could take the DSL idea and expand it to GraphQL. GraphQL top level
queries and mutations take similar forms (get all of resource, get one of
resource, etc). You could easily abstract that into a DSL if you'd like.

Authorization and authentication in GraphQL isn't amazing either. I'd really
like to see someone making that simple and on by default.

There's also some generic Ruby tooling things that'd be nice. Types, of
course. The standard way would be a mypy/TypeScript esque annotations with
erasure at runtime, but I actually feel like Ruby could do something really
neat and really true to the language by developing runtime dependent type
checking. Autoformatting would be nice (any thoughts on rufo[0]?)

[0] [https://github.com/ruby-formatter/rufo](https://github.com/ruby-
formatter/rufo)

------
revskill
Rails needs more opinionated decision on frontend story. Just pick ReactJS
instead ? Not a bad idea. Or VueJS ? Neither a bad choice. It's the main
reason i don't choose Rails over a universal Node.js stack for the HTML
rendering part.

~~~
jmchuster
Their opinion is coffeescript + turbolinks, which turn out to be the first two
defaults developers change.

~~~
revskill
I mean something like Typescript with an opinionated library/framework for
client-side part.

~~~
peteforde
Okay, I have lots of good news for you.

First, CoffeeScript is formally deprecated. Turbolinks sucked, but Turbolinks
5 is an entirely new beast and it rocks. You need to give it a second look. I
recommend this talk, sped up to 1.5x:

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

Finally, there absolutely is an opinionated client library that is designed to
pair beautifully with Turbolinks 5. It's called Stimulus and it rocks.

[https://stimulusjs.org/](https://stimulusjs.org/)

You can play with all of these frameworks using the --webpack parameter:

rails new future --skip-sprockets --skip-coffee --webpack=stimulus
--database=postgresql --skip-test

As a bonus for anyone starting a new Rails project today, you're going to want
to bookmark
[https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81...](https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b819517)

Let me know if you have any questions.

~~~
revskill
Thanks, it's an almost complete guide. But there's one important missing
piece: Universal routing. How about taking the routing config which can be
applied for both server and client ?

~~~
peteforde
If you're talking about React-style routing via navigation or whatever, then
yeah, you need to evaluate what's best for you.

One reason I love Stimulus + Turbolinks 5 is that you don't have to think in
terms of client-side routing.

------
crb002
Rails will have a resurgence with a Data Driven Design generator like
JHipster. So much time saved when you get front end client side validations
generated automatically; and layout is 90% automated with UI constraints.

------
dmitriid
In the past 14 years we somehow lost the ability to do “Your blog in 15
minutes” videos for any framework [1].

I wonder if that “do X in under 20 minutes” can be replicated in modern-day
Rails.

[1]
[https://mobile.twitter.com/dhh/status/492706473936314369?lan...](https://mobile.twitter.com/dhh/status/492706473936314369?lang=en)

------
hombre_fatal
I don't know how to quantify how relevant Rails is today, but I do think it's
interesting to explore why Rails isn't as popular as it once was. I remember
just eight years ago, Rails was on the HN frontpage almost daily.

Some ideas:

I think the most critical trend has been the dissemination of the Ruby
ecosystem's most popular and best ideas into every other ecosystem, which I
would summarize as a culmination/caricature of a movement that was already in
motion thanks to other ecosystems like Perl and Python. Rails was such a
massive hit because it was a stark contrast to the tropes of complexity that
came before it like endless XML configuration and IIS. I think Rails was a
symbol of this whole renaissance, not single-handedly, but because it
coincided so well with a critical-mass milestone in our industry and hit so
hard with this cult of "fun and easy". And these days were back when
[https://rack.github.io/](https://rack.github.io/) came out and Zed Shaw wrote
Mongrel which was Twitter's first web server and one of Ryan Dahl's
inspirations for Node.js.

These represented identity-level changes in tech and its crescendo into the
mainstream, not ideas that would merely spark and die in the Ruby ecosystem,
so it's no surprise that Rails cannot command the same gravity over time.

Another trend has been the popularity explosion of smaller and simpler
solutions over monolithic frameworks. For example, trending away from things
like GWT and ExtJS and Ember and Meteor. Trending towards things like React
and Express. No Rails analogue caught on in Node or Go and nobody cares.

There's also the explosion of Javascript which became such a viable
alternative to other dynamically-typed languages (particularly Ruby in this
context) that "why should I pick Ruby?" became a harder and harder question
for beginners to answer.

Finally, there's the explosion of choice. One back-end application framework
just can't dominate HN anymore like it could in 2007. I think React is the
modern repeat of Rails in the sense that it popularized a new paradigm of
building applications. And I think React will go the way of Rails in the sense
that its ideas will become so ubiquitous that React itself won't stand out
anymore, like when we see UIKit2 adopt these sorts of unidirectional data flow
and FP ideas as a core first-class abstraction. And we'll get so used to it
that we'll wonder "so what was the big deal about React again?"

Rails is certainly still amazing software and is clearly still improving. I
generated a fresh Rails project half a decade ago after a long hiatus and was
blown away when the error page in the browser had an embedded Pry REPL
initialized at the error's stack frame iirc. That's some wtf-level polish. And
I can only imagine how much better Rails has become since.

~~~
peteforde
I think that your perspective is fair and balanced. I'd just like to say that
nobody is forcing you to use method_missing or RSpec.

Anyhow, definitely peek at
[https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81...](https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b819517)
which I consider to be something of a missing manual for the bleeding edge.

I think that most folks would be completely shocked to realize that they can
run a command like: rails new future --skip-sprockets --skip-coffee
--webpack=react --database=postgresql

Although, I would argue that they should check out StimulusJS instead of
defaulting to React... it pairs up beautifully with Turbolinks 5. All
preconceived notions about earlier versions of TL need to be discarded because
it's actually pretty awesome now.

------
sklivvz1971
> I will argue that performance is the last thing you should worry about when
> you want to scale.

Oh boy, this is in one sentence almost everything that is wrong with Rails...

------
fareesh
I feel like Ruby/Rails needs to introduce some way of eliminating bloat
through some kind of optimization steps at the time of deployment.

------
JamesAdir
Some stats from Who is Hiring March 2019: Number of occurrences of the words:
Rails - 25 Elixir - 13 Python - 76 Ruby - 29 Django - 20

------
Smithalicious
Heh, from the rise of Rails as the hot new thing to blog posts trying to
justify its continued existence, it all went pretty fast.

~~~
richjdsmith
Just curious, do you think hell.js with its node_modules filled with
(sometimes) thousands of unmaintained or non-versioned dependencies will age
any slower?

------
miki123211
how relevant is Rails in the age of SPAs? How well does it work with making
JSON APIs and hosting static React apps?

~~~
manch23
Quite well. From Rails 5 there’s an API only init flag which removes the view
layer and then you can just return JSON from controllers. Chuck nginx in front
to proxy backend requests and serve your static front end bundle and you’re
golden.

------
mrtweetyhack
Too bad we can't compile a Rails app...

------
mavdi
Every time I read an article about something still being relevant, it soon
becomes irrelevant.

~~~
joelbluminator
Naah Rails is here to stay - the momentum around the project is still huge and
too many companies rely on it. Even if dhh did a Guido and left, there's a big
army of contributors that would replace him. If I need to guess though, in 10
years dhh is still involved with Rails to some degree.

~~~
pankajdoharey
Staying power has less to do with relevance and more to do with legacy apps.
There will always be some people working on any given technology. Be it
Spring, Smalltalk, Common Lisp or ...some X technology. The question is, is it
relevant? In an increasingly Multicore world where you try to extract more
performance out of your CPU's Ruby may not cut it and by induction Rails. The
future web devs would require writing better multithreaded code probably on
the JVM. Clojure, Erlang or Go are the few awesome options that come to my
mind.

------
mping
Rails is fine but didn't age well, specially the lack of strong functional
programming support. Other nag is that it's hard to not do things the rails
way - this monoculture reinforces the appearance that is fine because people
looking to do something different just don't use rails. And when you "scale"
rails is not really rails that scales as much as it is the architecture - it
could be applied to other frameworks. Still if you are familiar you can write
stuff really quickly.

~~~
mping
Feel free to downvote, but please present counterarguments so everyone can
learn.

~~~
pankajdoharey
Tons of Rails FanBoi's here! I use to be one of them.

------
jmchuster
Rails is a great monolith framework, but a monolith will eventually reach its
limits, due to size/complexity of the team or the task at hand. I think
providing a better story around how to prepare for or handle that transition
would definitely serve Rails a lot better in the long run. But, as long as the
main target audience of Rails is Basecamp (a saas tool with 12 developers), I
don't see it in the future.

~~~
dymk
The company I work at is transitioning from a rails monolith to many smaller
rails micro services - it’s the best if both worlds.

~~~
batiste
I think the best is to have nicely designed modular monolith application.
Sadly this something that Rails backwards conventions makes very hard to
achieve.

------
pankajdoharey
Mostly an opinion piece, A few points to Observe :

* According to the author NodeJS fails architecturally when small amounts of complexity is added to it.

=> Same applies to Rails aswell, anything beside a crud app and you start
wondering which code goes where.

* Rails is Opinionated...

=> Great if it were 2006, In 2019 rest apis are a norm, and more Nodejs apps
get enabled everyday have the same feature. Infact serverless apps to have the
same features. In my view firebase or similar apps is the right way to go when
you are booting your apps, and then scale or rewrite when you grow.

* Rails has a deep culture of code quality.

=> So does smalltalk, lisp and clojure. Infact ruby community has borrowed
many ideas from both Smalltalk and Java communities.

* RSpec ..

=> Rspec isnt the original invention its based on JMock.

* Heroku, ActiveAdmin, Industry Proven ...

=> Straw-man arguments.

I am as opinionated as rails and in my opinion Rails isnt relevant in 2019,
they are running out of ideas, the latest "innovation" in rails is an inbuilt
_Rich Text editor_ called Trix available as ActionText. Yes you read it
correctly a rich text editor is the latest relevant innovation in a web
framework. I think for most startups a great way would be to start with a
serverless setup like Lambda or Firebase .... and just write the relevant
front end bits in Javascript, Coffeescript, Clojurescript or Elm. When the app
outgrows such services just write the enough parts of backend service as you
need it.

~~~
Retra
Are you really choosing web frameworks based on how 'innovative' they are?

~~~
pankajdoharey
Innovation implies improvement! My primary metric is ease of use and long term
scalability, but so is constant improvement and upgradation in features. A
rich text editor isnt improvement, its bloatware.

