So we’re back to the old pre SPA web and even have a term for it: MPA
If I build an MPA, why should I choose Astro if I can choose Rails? That’s a serious question to the HN community, not a rhetorical one - would very much love to learn if there’s something new here.
They would not, they're not even trying to be the same thing.
I get that you don't like RSCs, that's fine you're allowed to have that opinion, but you can't justify it by saying it's a CRUD framework. Apples and oranges.
Can you expand? I'm able to do non-CRUD things in Django just fine too. What's unique about RSC? People have been building production grade, multi page apps with it for almost two decades.
Yes, you can build static pages very easily in any of those frameworks, they're great for that.
The problem is that as soon as your frontend needs to be dynamic, these frameworks do nothing for you. You can do it on your own by using a library like React and making API calls, but that comes with its own set of issues.
RSCs are a way of addressing these issues by making UI and data streaming a core feature of the framework.
With Django you create an API endpoint that queries the database (this already gets complicated if you want types), then on the frontend fetch that endpoint (using some kind of library to manage the request complexity for you), then render that data.
With RSCs you write a server component that grabs data from the database directly and render it.
GraphQL addresses some of the same problems, but has its own set of issues. It's all about tradeoffs.
There's some term confusion. "Static pages" is a different concept -- when there's no code executed on the server, server can only serve static content (no DB naturally), usually from a CDN that can cache responses. We're talking here about dynamic pages.
> a server component that grabs data from the database directly and render it.
Render where?
1. If it renders it to the html content for the browser, it's called "templating", and all the frameworks have been doing it for 20+ years (e.g. ASP, JSP, Jinja).
2. Render to the browser -- it still need to pass that data from server to browser, there's no way around it. And the idea of abstracting that, so the user would not know or care where the code is executed is not new at all. There were multiple attempts, for example see JSF, released on 2001. It burned in flames because you really want and need to know where the code is run.
And there never-ending attempts to at least write in the same language on server and browser, without abstracting the XMLHttpRequest (aka AJAX aka Fetch) layer. For example Node.js -- to use JS on server. Or GWT -- to use Java in browser (died, because you still absolutely want to know how it will be compiled to JS). Now Kotlin compiles to JS. Those are successful to a point. And the ultimate answer to bring all the languages to browser -- WebAssembly.
My point is -- all the attempts aiming to abstract away client-server boundary has been an utterly obvious failure. But if RSC does not aim to abstract it, then it's not different than technologies from 1999, but in Javascript.
After watching all this for a while, in order to get MVPs up and running while holding the IP and other things under control I’ve worked through RoR docs and did some projects in Django and I’d like to know more too. I’d bet on a re-emergence of traditional monoliths quite soon. That is if pocketbases and supabases aren’t going to be the new default which I’m not sure about right now. Recently built a site in NextJS and Nuxt though and I got to say it wasn’t that bad at all. But there’s something people are not considering enough and that is bringing value fast. That’s why I’m going deeper into Django (stability, reliability, value).
The other thing that keeps me in the Django ecosystem is frankly Django Admin. If any of the JS backend frameworks would provide these out of the box things that basically everyone needs, I would be much more open to using them.
For example, an admin panel for changing your models (like Django Admin), performance monitoring like Phoenix's LiveDashboard.
Rails is faster for building an MVP. But it's significantly worse than a project built with a typed language when it comes to extending and maintaining.
I thought I had misconfigured Sentry (for error logging) because the type of errors that plague Rails, or any language that is not typed, just don't happen with a typed language (unknown method called on NilClass).
We can decide to make a column in the DB to no longer allow NULL values, and we are immediately notified by the TypeScript compiler about every line that needs to be updated.
Exactly. more than 5 years ago or so I used a lot of Rails (and have worked with Java/C++ before), but after switching to a typed language like Go on large projects I completely removed Rails from my future projects.
The Ruby/Rails magic feels like its not worth it for long-term or even short-term maintenance.
I love type languages to the point Typscript is unacceptable. But Elixir/Phoenix has so many nice things to to point that an unsound static type is far inferior.
> Rails is faster for building an MVP. But it's significantly worse than a project built with a typed language when it comes to extending and maintaining.
I'm not sure that the academic work on software engineering really bares this out. Th Static vs. Dynamic debate is far from settled and increasingly looks to me like a matter of preference.
This isn't really why most developers are choosing to use what they're choosing to use today, but in the long term the most granular serverless compute available is going to be running on V8 isolates, not containers. With JS (& WASM) you're going to be able to deploy globally w/o a build step in less than 10 seconds and pay a fraction of the cost for compute. That's why I'm focused on the JS ecosystem personally, I think the advantages are just going to keep compounding and the % of web applications being built with it is probably just going to keep going up.
Because Rails isn't good at building modern frontend experiences. It's built around static pages.
RSCs (and Next) are (going to be) built for dynamic pages. Loading new data from the backend is as simple as editing an ERB template, and you get updates on top of that. Suddenly you don't need to think about APIs nearly as much, you don't need to worry about making fetch requests, you don't need separate codebases.
If Rails decides to make data and UI streaming a primary building block then that would be awesome. Until then, that's why you would use RSCs.
We’re using typescript to create static html like it’s 1996 again! Complete with inline styles and everything.
In the web browsers eyes, a Next.js app is just a plain old html page load when you navigate within the app. I believe the days of SPA’s and mounting on the bang# sign are dead. Some smart folks realized that it was more computational efficient to output plain old html like back in the days.
The most I've seen it used is for backporting fixes from future Rails versions or other gems that are hard to update - and again it's easy to do this in an organized and clean way
Just because ruby gives you the tools to do stupid things (and every language lets you do stupid things) doesn't mean that you should do them in a real business app
And you can use something like htmx to do everything on the server and use jquery to do fancy things. It’s a thing, especially for small one-off projects.
If I build an MPA, why should I choose Astro if I can choose Rails? That’s a serious question to the HN community, not a rhetorical one - would very much love to learn if there’s something new here.