
Rails, still? - vinnyglennon
https://blog.phusion.nl/2018/08/30/rails-still/
======
ethagnawl
"Sinatra is Ruby with Rails in mind. You will find yourself using more of
Rails in your Sinatra application over time and ask yourself why you're not
just using Rails."

This is an important point. If you've ever developed a non-trivial application
using Sinatra, Express or any other "micro" or "non-opinionated" framework,
you'll have hit this wall quickly.

To riff on Greenspun's Tenth Rule, "Any sufficiently complicated $MICRO-
FRAMEWORK application contains an ad hoc informally-specified bug-ridden slow
implementation of half of Ruby on Rails."

~~~
aikah
> This is an important point. If you've ever developed a non-trivial
> application using Sinatra, Express or any other "micro" or "non-opinionated"
> framework, you'll have hit this wall quickly.

Not really. You want an ORM? choose an ORM library. You want templates, choose
a templating library. You want to send mails, choose a mailing library. I
don't see how big frameworks like Rails make all these things better,
especially when they don't give you the choice as to what tool to use. If you
ever developed a non trivial application, you also know that your first
concern will be to avoid unnecessary bloat and complexity and only bring in
libraries that are strictly required. And as we are moving from traditional
html rendered server apps, big frameworks lost even more value since there is
no need for a templating libraries, html form libraries,...

~~~
matthewmacleod
I actually consider Rails in its 3.x+ versions to be a pre-selected
combination of smaller libraries - because it really is. Don’t need mail?
Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit
is that when you _do_ need those tools, they are there, they work together,
and you don’t have to choose.

That’s not always perfect or suitable for every use case, but it’s not a bad
thing.

~~~
steveklabnik
Agreed; those days are when I worked on Rails, and that was a lot of the
things that made 3.x different from 2.x. I wrote a blog post about it that’s
one of my most popular ever: [https://words.steveklabnik.com/rails-has-two-
default-stacks](https://words.steveklabnik.com/rails-has-two-default-stacks)

This sentiment also was a major theme of my forward to The Rails Way.

I’ve been thinking about this stuff a lot in the context of Rust...

~~~
canhascodez
> I’ve been thinking about this stuff a lot in the context of Rust...

Do you mind extrapolating further, or will that be the topic of a future blog
post?

~~~
steveklabnik
For now, what I’ll say is that I’ve seen how Node never really got a rails,
and how Rust has a zillion microframeworks but no Rails either, yet. Do we
need one? What would it look like? That kind of thing.

~~~
ethagnawl
> Node never really got a rails

I'm, admittedly, out of the loop when it comes to Node, but I do remember
Sails looking promising when it was first announced. I recently suggested it
to someone (who uses Node regularly) as a possible solution for a project
we're working on and they'd never heard of it. So, between that reaction and
the fact that I haven't heard of anyone else using it (or anything similar), I
think you're right that a Railsy solution never took off.

Elixir is an interesting counterpoint, though. It seems like Phoenix was
released and saw broad adoption very early on.

I'm wondering if this dichotomy is a result of where people are coming to
these newer languages from: people writing Elixir probably aren't coming from
the FE/JS world, but there's a very good chance people writing Node are. Prior
to the somewhat recent proliferation of JS client app frameworks, using a
smattering of libraries was a very common approach to solving problems. (It
arguably still is, albeit at a different level of abstraction in
React/Babel/Webpack land.)

Anyways, I'll be looking forward to reading the post you alluded to above,
should it ever come together.

------
ksec
Copy from my previous reply

 _This is pretty amazing. Both GitHub and Shopify are huge, billion dollar
companies running on the original apps made over a decade ago. And they now
both on the latest Rails, helping to push the framework forward [1]_

 _I can 't wait for y'all to see what we upstream now that we're in a position
to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2]
at RailsConf was just a small portion of our plans for Rails. [3]_

There are also work from Discourse on Rails performance, Ruby is getting a
Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and
it is available on all ruby manager [5]. The Open Source build is now also
available on macOS as well.

There are lots more, and all of them were years in making, It took a year for
Github to get to latest Rails release. For the past few years, many have been
writing off Ruby Rails, Ruby is comparatively expensive to scale ( and it
still is ) , we expect other frameworks to catch up in terms of productivity,
and will spell doom to Ruby Rails. Not only has such framework yet to appear,
Ruby Rails continues to improve on all front.

I say the best days of Ruby Rails has yet to come.

[1]
[https://twitter.com/dhh/status/1030528476250562569](https://twitter.com/dhh/status/1030528476250562569)

[2] [https://speakerdeck.com/eileencodes/railsconf-2018-the-
futur...](https://speakerdeck.com/eileencodes/railsconf-2018-the-futur..).

[3]
[https://twitter.com/eileencodes/status/1030461847256875008](https://twitter.com/eileencodes/status/1030461847256875008)

[4]
[https://twitter.com/k0kubun/status/960112559343878144](https://twitter.com/k0kubun/status/960112559343878144)

[5]
[https://github.com/oracle/truffleruby/blob/master/doc/user/r...](https://github.com/oracle/truffleruby/blob/master/doc/user/r..).

~~~
wolco
Would you consider laravel to be that framework that allows rapid development
increased speed and provides an easier way to scale.

~~~
John78_
Based on the following benchmarks, Laravel is slower than Rails. But still,
both frameworks are much slower than .net/java/erlang based frameworks.

[https://www.techempower.com/benchmarks/#section=data-r16&hw=...](https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune)

~~~
brightball
FWIW those benchmarks are inconsistent. Usually it’s a matter of optimizing
for direct calls to C libraries.

------
hardwaresofton
Disclaimer: I've worked with but dislike ruby and rails in comparison to other
choices (whether language or ruby framework).

IMO people are still using rails because a bunch of orgs moved to it from Java
years ago, or started with it after some successful hackathon. It's in wide
demand because a large number of orgs mindlessly (or mindfully) chose it long
ago. Basically all enterprise/large company apps I've seen have been in either
Java or Rails. Some places are still using COBOL. Some places are still
maintaining/starting codebases in COBOL. I assume that people will be able to
make this same argument about NodeJS in ~2-5 years.

Also, the the point about micro-frameworks being bad being made in the
comments because you eventually re-implement rails seems to be wrong or badly
articulated -- that's exactly the point of using a smaller-yet-composable
tool, you don't use any parts until you need them. Sinatra has also leaned
into this by allowing pieces of rails to be loaded, and providing a path to
transitioning to Rails proper.

I dislike rails because there's too much magic, and too many ways to do things
-- it's precisely why I like micro frameworks. Also, the (request, response,
next) middleware/handler paradigm is the most composable way to write server
software I've ever seen.

~~~
captain_crabs
There's a little big detail w/r/t java comparison: every company I've
personally worked with who uses rails for their backend vs java moves WAY WAY
WAY faster. So in terms of the "enterprise stack" dichotomy, there is a
difference in kind between rails/java.

I get things done faster and more maintainably (for future me and other devs)
when I do it in rails. Hopping into apps that rely on (request, response,
next) always hits me with a learning curve every single time I come back to
em, which gets worse as complexity rises. It could also be that I'm very bad
at thinking in terms of pipes and need to practice that more.

I also find that in rails, there really aren't _that_ many ways to do things.
And, in general, apps that age gracefully always figure out how to phrase
their domain concepts through the smallest restful url's/resource mappings
they need. There's a lot to be learned from the approach the smaller micro
frameworks take, and you can get the best of both worlds in a lot of ways.

~~~
StreamBright
And there are some companies where you need to move fast while at the same
time need to have high performance (100.000 req/s with 30-50 ms mean latency).
In that case Java is the only option between Rails amd Java.

~~~
jashmatthews
The gap between Scala + Play and Ruby + Sinatra (or cut down Rails) is not
like it was in 2008. Ruby 2.5 is ~13x faster than Ruby 1.8. Now you're lucky
to squeeze 3x the web throughput out of a Java/Scala service as opposed to
CRuby and JRuby closes that gap further.

~~~
StreamBright
Can you point to me any performance site where Ruby 2.5 + Rails that backs
your point? If you use JRuby than you are on the JVM already. In that case why
Rails at all?

~~~
jashmatthews
In terms of pure Ruby performance, there's a semi-official non-trivial
benchmark called optcarrot. Ruby 2.4 is 14.3x faster than Ruby 1.8.7 here:
[https://github.com/mame/optcarrot/blob/master/doc/benchmark....](https://github.com/mame/optcarrot/blob/master/doc/benchmark.md)

Rails performance relative to JVM+Scala+Play is tricky to measure but the
closest thing to a decent benchmark I know of is this:
[https://www.techempower.com/benchmarks/#section=data-r16&hw=...](https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune&l=hr9r0f&f=zg21hb-
zik0zj-zik0zj-zik0zj-zik0zj-zijunz-zik0zj-4zsov)

My own experience at ChartMogul with building production services in Ruby, Go
and Rust is that the overall throughput of REST API type services increases a
disappointing amount.

With JRuby you get to retain all the benefits of the Rails ecosystem. Most of
the Go and Scala community is driven by much larger companies who do open
source libraries but they don't really build frameworks to help developers
build software quickly.

------
spacesword
“And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve
is steep, you will need to learn OTP. Which is probably why adoption lags."

The author has no idea what they are talking when it comes to the
alternatives.

I was making simple CRUD apps in Phoenix (the types of apps I would normally
use rails for) for a year before I even looked at OTP. You can become
productive in elixir and Phoenix very quickly especially if you come from a
ruby/rails background.

I recall a blog post by dockyard where they said they had new hires making
commits within the first week.

~~~
bhahn
The author isn't wrong. You need to learn OTP to know that you don't need it
(at least in the very beginning).

When I was learning Phoenix, I spent a substantial amount of time learning
Elixir as well and OTP is one of the first few things they put in front of
you. Don't get me wrong, I loved learning about it personally, but I am not
surprised that a lot of people would consider it too much effort.

------
hota_mazi
> In summary, we 'still' use Rails as it works just fine.

PHP works fine. COBOL works fine.

Nobody ever said Rails doesn't work. Or doesn't work fine. That's a straw man.

It's just that Rails, and Ruby in general, is in clear decline. Not just
because some new flavor of the month frameworks are coming out, but because a
lot of the concepts Rails supports are antiquated, and Rails hasn't shown to
be that adaptable to more modern front end trends after years of efforts from
DHH.

Hell, I'm sure that even DHH himself would be very upset if people settled for
something that "works just fine". He's just not happy that this time around,
that characterization is being used to describe his creation.

~~~
nocman
1) "a lot of the concepts Rails supports are antiquated" ...

2) "Rails hasn't shown to be that adaptable to more modern front end trends"

Would you mind elaborating? What Rails concepts are "antiquated", and what
"modern front end trends" does Rails not adapt to?

I've never done any Rails development, but understand the general idea of how
it works, so I don't have any skin in the game. I'm just honestly curious
about what you were referring to.

~~~
stephenhuey
I imagine SPA trends with frameworks such as Angular are leading to the
parent’s conclusion. However, you can still use SPA frameworks and just use
Rails as an API, or you can take a step back and realize a large percentage of
web apps still don’t need a complex SPA framework and might get enough front-
end functionality out of something like Vue. In other words, many developers
fall into the trap of choosing tools they prefer even when they may take more
time to use and not provide enough business value. Plenty of web apps would
ship faster if built with Rails and be just fine.

------
erokar
I'm waiting for a framework that covers the whole stack and also makes it easy
to make SPAs, if you wish. When that arrives I think it'll really take off.

For a while Meteor seemed to be that framework, but for a number of reasons —
performance issues, lack of support for SSR - it hasn't taken off. While it's
often good practice to separate the API and the frontend, for solo developers
or small startups that's often overkill and adds complexity.

~~~
andybak
Or - get 90% of the benefit of SPAs but leave your business logic where it
belongs (on the server). PJAX/Turbolinks/Intercooler or something similarly
lightweight is probably all most people need when they reach for full-fat
front-end framework.

~~~
erokar
Yes, for personal projects I've moved away from SPAs to backend frameworks and
as little JS as I can get away with. I admit I don't know how easy Turbolinks
or PJAX are. A while back when i played around with Intercooler in Django it
wasn't seamless.

~~~
andrewmcwatters
Turbolinks and PJAX are really what a lot of folks wanted before the web
development community at large was introduced to client-side routing through
SPAs post-Knockout.js days.

------
cageface
We still use Rails and it's a good fit for getting projects off the ground
quickly and validating ideas. It's a niche but it's an important niche.

Once Rails projects get beyond a certain size though they start getting
exponentially more difficult to maintain. My sense is that Node is going to
surpass Rails by sheer brute force eventually. When I work in JS now I'm just
amazed at how much better the tooling and performance is than Ruby and ES6/7
is overall a pretty nice language to work with. And having something like
Typescript is essential once a codebase gets big enough.

~~~
cutler
JS tooling better than Ruby's? Care to elaborate? Which Node.js framework
comes anywhere near the productivity of Rails?

~~~
cageface
By tooling I mean things like code editing, linting, type checking, debuggers
and runtime quality and performance. As far as I can tell Rails is still a lot
more polished than any JS web frameworks.

------
fareesh
The flowchart usually goes like this:

\- Oh wow this framework looks great I wish rails had that. I am gonna try and
use this when the opportunity arises

\- Aha this is the perfect project for that framework I saw

\- hmm how do I do... Oh. Well I guess I'll just build it myself.

\- This plugin is the equivalent of paperclip, perfect! Great DSL, great
documentation. Hmm what is this error. _3 hours later_ github issue time.

\- Turns out this wasn't the right project for me to try out this framework,
maybe the next one.

\- Oh rails n+1 is out can't wait to try it

------
enraged_camel
>>And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve
is steep, you will need to learn OTP. Which is probably why adoption lags.

You don't need to learn OTP to become productive in Elixir/Phoenix. It's
abstracted away from you, but also gives you the ability to dive in if you
want/need.

~~~
brightball
Agree. You don’t need to learn OTP to use Phoenix anymore than you need to
learn the entire Java ecosystem to use Kotlin.

Erlang has been around for 30+ years...there’s a lot. Doesn’t mean you need to
use it all.

~~~
bitwalker
I think it's disingenuous to say you don't need to learn OTP. You need to
learn the basics of it, or you will struggle, because you will be trying to
solve problems in a way that doesn't fit with the underlying language and
runtime. That said, learning the basics of OTP is super easy, and can be done
in an afternoon (spawning processes, sending messages, supervision,
understanding what applications are in Erlang/Elixir parlance).

It's like saying you can build a Rails app without understanding
classes/objects - sure maybe you could throw something together because the
tools are so friendly, but you would get lost pretty quick when trying to do
something on your own. Learn those basics up front, and you can get a long way
without having to delve into more advanced topics.

~~~
brightball
Basics, sure. I think you learn the basics just to learn Phoenix though.

------
tekkie00
One of the biggest and often overlooked features of Rails is rspec and
db:migrate. For whatever reason, I have yet to find alternatives in other
frameworks that have matched the elegance of these 2 indispensable tools.

Similarly, while I'm not a huge fan of ORMs im general, ActiveRecord is pretty
hard to beat pound for pound.

------
brightball
People take for granted that Rails provides the closest thing to Aspect
Oriented Programming that exists today (that I know of).

I don’t use rails regularly anymore, but I used it long enough to appreciate
what it gives you. As long as developer efficiency and time to market is more
important than than micro performance optimizations, Rails and other options
that emphasize developer efficiency will continue to succeed.

Unless you’re in an established enterprise environment, that is generally
going to be the story.

------
sergiotapia
>And then there's the Phoenix framework. Chris McCord wanted this MVC
framework for Erlang, where Elixir is based on Erlang, used mostly for large
scale backend systems. And Phoenix would be the Rails to Erlang's Ruby
(Elixir). The learning curve is steep, you will need to learn OTP. Which is
probably why adoption lags."

This is false, you do not need to know OTP to be productive.

These days if I'm forced to work with Rails, I almost always write
functionaly-kinda-ish Ruby code. Elixir sold me heavily on the idea of one
input in, one input out and all the other good that comes from functional
programming.

I probably no longer write idiomatic Rails code (40 methods in a ruby model).

~~~
bitwalker
I commented elsewhere already, but you do need to know _some_ OTP to be
productive. But those basics (processes, messaging, supervision) can be
learned easily in an afternoon.

In my opinion, OTP is not the reason why the learning curve is steep. If
anything, the learning curve is steep for those trying to switch from
something like Ruby to a functional programming language for the first time. A
language with immutability as the default, no concept of classes or objects
(though viewed through the Alan Kay lens, processes could be seen as "true"
objects). If it is your first FP language, most of one's object-oriented
experience is not going to help, so there is a lot to absorb before you even
get to Phoenix or OTP.

~~~
sergiotapia
You don't need to know _any_ of these to build a fast, working, business-
helping CRUD app.

processes, messaging, supervision

------
krallja
In 2007, Rails was the hot new fad like Node.js became a decade later. Now
it’s the boring legacy app, like Java was in 2007 and Node.js will be around
2020. Looking back, all this effort now seems like mostly-pointless
reinvention.

~~~
joshmn
You have to remember how people were writing web apps in 2007 in order for
this to be contextually correct.

~~~
krallja
Yeah, I guess I should have written about Perl or PHP rather than Java.

Spaghetti code is no fun, but you can still write that same style today in
.erb files.

------
stevebmark
No one avoids Ruby/Rails because it's old, we avoid it because it locks you in
to conventions that most other modern languages / frameworks considered bad
practice, like magic, metaprogramming, one process per request, locked in to
OO, the concept of "controllers," separating templates from view logic, and
doing everything at runtime.

~~~
jimmy1
That, and generally ORMs are out of practice as well. Using rails without
ActiveRecord is almost pointless to me.

Even when I was programming primarily in rails in it's hay-day (2010 - 2013),
I was always swapping out my inefficient AR queries with just custom SQL. I am
generally a "performance doesn't matter that much" kind of guy, especially
when people try to micro-optimize, but one place it matters a lot is with your
data. These days I just go straight for SQL and save myself a lot of trouble.
There will always be impedance mismatch between your data store and models,
and ORMs in their ambitious attempt to serve every use case, at times,
generate some _really_ inefficient queries. ORMs really like to stay within
relational SQL databases as well, with half-baked support for a couple NoSQL
stores like Mongo, but then get into Cassandra or Dynamo territory and they
are useless.

------
honkycat
The usual amount of snarkiness I've come to expect from the Ruby community.
What a smarmy tweet: "Lol 20 something developers using new tools when they
could just use this ancient slow dynamically typed OO language I allied myself
with doing the exact same thing 10 years ago"

Ok I'll bite:

\- Because it had it's milkshake drunk by nodejs which has better support for
modern front end workflows and great languages like typescript built in top of
it. And is faster and better supported.

\- because it's slow and difficult to scale

\- because it has years and years of baggage

\- because I prefer elixir it golang or rust or Scala

\- because it's not a perfect fit for every project

\- because I do not like stateful object oriented languages with magic so I
can trust my intern and Jr devs to write something decently maintainable

~~~
stevebmark

        extend ActiveSupport::Concern
    
        attr_accessor :foo
    
        class << self
            included do
                def method_missing(name) do
                    define_method(:after_save) do |bar|
                        ...
                    end
                end
            end
        end
    

What do you mean? This stateful, first class mixin OO metaprogrammed magic,
implicitly globally mixed in to your application, makes it super easy to
understand the flow of your application and the capabilities of your system.
It's also super easy to see where things are defined, and the structure of
methods/classes/object doesn't depend on luck / the order your program
_executes_ in! Fat models are the way to go, there's obviously no problem with
stateful mixins to "separate" model logic and make sure your model can do
absolutely everything, because what is data, really?

Perfect for junior and senior devs alike.

edit: I forgot to include `method_missing`, which definitely isn't a design
flaw, and there's absolutely no fundamental community problem that Ruby
developers don't see any problem with using it.

~~~
eximius
This is sarcastic right? I really can't tell. And you either deserve and
upvote or a downvote and I can't tell which because of it.

------
vemv
Essentially, this article gets written every year.

~~~
jspash
That should tell you something, no?

~~~
freehunter
It tells me that some people _want_ Rails to die way more than it actually
_is_ dying.

------
cutler
Since discovering Clojure in 2013 my biggest regret is that the Clojure
community is not interested in building a Rails equivalent. I don't mean an
MVC clone but a full-featured web framework supported by the wider community
rather than someone's personal curated list of libraries like Luminus. I think
Rails set the bar for whether a new language can transition to mainstream
adoption.

------
chestervonwinch
I only did a short stint in web dev between undergrad and grad school for
about a year. We used Rails. This was about 7 years ago. Are the reasons Rails
has fallen out of favor technical or faddish? Or a little of both? I'm not
intending to start a flame war of any sort. I'm just curious, having been out
of the field for a while.

~~~
tim333
I'm not sure it has fallen out of favour but there is more competition now
especially from javascript stuff.

------
pgcosta
The annual "is rails still relevant" post :D

------
dnprock
I have a few Rails apps. Team now wants to move to nodejs. I made a few apps
in nodejs. It's such a mess, yarn vs. npm, webpack setup. I guess nodejs
community is still searching for their holy grail (Rails.)

~~~
te_chris
The node community is that xkcd comic about standards in human form. Nothing
is ever settled, always a new way to do something.

------
mystikal83
I want to build an ecommerce website, are there alternative JavaScript that
can replace RoR and the Gems ecosystem?

------
tobyhinloopen
Wait, when did Rails become old or uncool?

~~~
tmh88j
>Wait, when did Rails become old

It was released in 2004. Youtube and twitter didn't even exist then. The
iPhone and Android were still 3+ years away, which means mobile internet as we
know it today wasn't around then either. ROR has been around the block.

------
borgatronics
seems like very strong confirmation bias

------
conqrr
After all this time?.... Always

------
draw_down
Sinatra is frustratingly limited in some ways. I would describe it as easy,
but not simple. It’s easy to use it to bang out any use case the authors
foresaw. But now I’m going back and reading the code all the time to figure
out how to accomplish certain things. And that reading is difficult, because
like some other Ruby things it’s more focused on providing a pretty DSL for
the user. How-to docs for basic things are easy to find, but reference docs
aren’t, and often just list methods without any description of what they do.

------
thrownaway954
If Rails is in decline it's because almost all languages now have some sort of
MVC framework on par with Rails now. Since C# is used in the enterprise it's
just natural to go with ASP.NET MVC Core instead of trying to get Rails to run
on Windows. In my opinion, I feel one of the big mistakes that Rails made was
not focusing on getting it to work officially on Windows.

~~~
RomanPushkin
Why rails should bother? There are plenty of other ruby gems and their
developers who don't care about Windows. Even if Rails works, you can't
convince community to make every single gem compatible with Windows. So it
makes no sense.

------
pankajdoharey
As we transition to a more multicore, multi threaded environment Ruby cannot
perform well. And thus by induction Rails. An interesting way forward is
functional programming, because of its composable nature can perform really
well in such environments. I dont see where Rails ideal niche exists going
forward, is it in Large Apps that need really scalable apps that exist on
multicore environments? Does it lie in small SPA like apps for which it has
virtually no support? or Does it lie in the middle where you just throw more
hardware at the problem before rewriting the whole app? In the last one yr i
have seen more enterprise apps being activated in Nodejs than in Rails. Why
does the enterprise Like Nodejs while Rails is on its downward spiral? i
suspect it has to do with Nodejs being Beginner friendly. I left the Rails
ecosystem 3 yrs back never looked back, and i dont see why i would ever go
back.

~~~
bodas
I'm not sure I agree with this, you can always achieve parallelism with
multiple processes and IPC, and can do so fairly efficiently if communication
is light.

Rails' biggest problem is that it isn't JavaScript, and thus code is not
portable between client and server.

~~~
strken
Out of curiousity, where have you found it useful for code to be portable
between client and server?

I've been using Node.js/React together for a while, and I haven't found code
reuse across client and server to be as important as I initially thought. The
only code that I've tended to share is validation and a handful of utilities,
which are a tiny proportion of the total, and even for those the business
rules aren't always the same.

~~~
simonbw
I've made a few multiplayer games where players need to keep a game state
synchronized with the server. I used redux for state and game logic, and it's
been really nice to be able to share the reducers between server and client.
This made it so all I had to do to keep all clients in sync was share actions
across clients as they happened.

I've also found it useful to have TypeScript on client and server to be able
to share types between them.

Also, when using React, Node on your server makes server-side rendering a lot
easier.

------
pankajdoharey
Rails has a problem most are aware of, When i started rails few yrs back, they
said skinny controllers fat models, but in a few months our Models became 3000
lines, so they said external loading libraries, then came concerns, then they
took concern back because it doesnt work. Then another solution came in the
form of gems, people thought lets make more gems we have tried so many
different ways to do this. If that is not all there is a problem in rails that
exist purely because of the way the framework works. The mass assignment
problem, this problem literally doesnt exist in any other framework. What we
do with this is a patch to restrict an action, but it really exist because of
the nature of the framework. This is a code smell if your program due to its
very nature creates problems that needs patching is probably not doing
something right. In my opinion best is to go back to simpler ways of
organising code. Rails is too much an abstraction that creates its own unique
problems.

~~~
weego
Seriously though, the only problem firebase solves is the question "what
infrastructure decision can I make right now that I will regret as soon as
possible?"

I'm being facetious but then I feel like this whole thing is a joke, so it's
kind of fitting.

~~~
meesterdude
I've known a lot of people get started quickly with firebase and then proceed
to have to yank it out for the nonsense they run into. I also question the
real value/merit of firebase.

~~~
tbrock
Heroku did this properly imho. They are a perfect example of how one can
provide hosting that actually is helpful and sophisticated where it needs to
be but gets out of your way when you don’t need to care (for 99% of
applications that don’t need to scale beyond a certain point).

The people want postgres, give them Postgres.

