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.
Rails, Django/Flask or even Apache Struts or Java Spring would do good in this use case.
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.
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.
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.
The Ruby/Rails magic feels like its not worth it for long-term or even short-term maintenance.
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.
Can you elaborate on this? Is this using something like knex/objection or something else?
Is there something that will do this if one is using mostly raw sql with knex?
I don't have experience with Knex so I, unfortunately, don't have an answer to your question.
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.
I'm glad we have several options for building modern frontends, I'm very excited to see how things will shake up in the next few years.
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