I Miss Rails

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

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

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

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

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

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

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

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

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

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

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

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

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

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