No joke, I started my career in Step 1 with Ruby on Rails. I lived and breathed Step 2 and Step 3 with the ever-changing industry standards: jQuery, backbone, angular (avoided), react, and (currently wrangling at work) the complex beast that is graphql & apollo, all over the span of 10 years. Coming back to Rails for a side project has helped me realize:

- Server-side rendering is actually fantastic. It's fast for users and there's no sluggish build step holding you back.

- Turbolinks covers 70% of the interactivity you need.

- Alpine.js covers another 20%.

- With Rails having webpack built in, there's no friction to writing/importing your super-fancy JS interaction for that last 10% when you need to.

Rails gets it right. It truly makes your dev life better, in ways that actually matter. Back then I was convinced Rails led to spaghetti code, but in hindsight I just needed to improve as a software developer.

10 years later, there still isn't a better tool than Rails for tech founders. There are some promising ones, but none that get you launched nearly as quickly. It's kind of annoying, to be honest. Is this that hard of a problem?

Totally agree. I use https://unpoly.com/ instead of Turbolinks, anyone interested in this more sane approach should give it a try.

This feels slightly misleading.

Step 3 is where projects end up when they grow sufficiently in complexity and/or features (React specifically is not a necessity but a good solution).

The problems that are being looked at by many of these frameworks, are pushed by the need of being able to use the same rendering and logic, tooling, language and so on for different stages of complexity/requirements.

These are real issues that people worry about and try to find solutions for. On the grand scheme of things these developments are about reducing pain and cost, while keeping up with or driving advancements in user (read: client) expectations.

> You can see that nothing really changed

Nah, you've started with a good framework focused on querying data and rendering them, and finished with one focused on async network IO and live-updating an interface.

Cheap comment ..

I see them as options, not steps, options within the same ecosystem

A lot changed, but the limitation is still the same - the delivery platform - browser (dom + js)

> also less complex.

And less interactive.

I always wondered what is not interactive in pressing a form submit button, being brought to another page with results.

What is the definition of interactive?

Oh easy. Just try the HTML only version of GMail, I believe you will quickly notice the lack of client side interactivity.

Maybe just a bit of Babylonian language confusion. Static, to dynamic, to server-side-dynamic-vs-client-side-dynamic...

I don't think any of these changes have made the pages less interactive. What the move back to server has generally done is remove all the unnecessarily deferred layout. The worst performance offenders remain advertising and tracking.

The scaling characteristics of a client side and server side rendered app is different. Client side apps have up front costs which are amortized as the view can be incrementally updated. Whether this is more performant depends on the metric and the problem domain.

Particularly static pages with minimal interactivity can be prerendered and cached at the CDN, but that’s not necessarily the same as an on demand server side rendered page, either.