Inertia is "dumb" in that a component can't request data, but must rely on that the API knows which data it needs.
RSC is "smarter", but also to it's detriment in my opinion. I have yet to see a "clean" Next project using RSC. Developers end up confused about which components should be what (and that some can be both), and "use client" becomes a crutch of sorts, making the projects messy.
Ultimately I think most projects would be better off with Inertia's (BFF) model, because of its simplicity.
I'm using fedora coreos to run nextcloud on a cheap old workstation. It took some work to get the configuration right, but I'm very impressed by how little maintenance I need to do (so far none at all).
I've been looking for a better solution for local dev on services deployed via quadlet, could you elaborate on this?
I just took a look at the socket activation docs[0]. Is my understanding correct that no `compose.yaml` is required, just running `docker-compose up` with the appropriate env var pointing to the socket is enough to trigger a connection and service activation?
As far as I remember my podman installations on both fedora and ubuntu came with a podman.socket service that I could enable as easily as running:
`systemctl --user enable --now podman.socket`
It works perfectly fine if you install docker but just the CLI (e.g. on debian docker provides a package for that in their deb repository).
Then you can use docker contexts to make the default context your podman socket. Then you just use `docker compose` as you normally would. I usually use this with rootless podman installs.
No, it was absolutely about the effort needed to rewrite the project. They couldn't afford a rewrite, only a port. They're not going to keep maintaining the Typescript version once they have transitioned to the Go version.
Yes, they distinguish between a rewrite and a port (first time I heard the distinction like that, but it intuitively makes sense).
A Go port looks roughly the same as TypeScript, same “shape”, same concepts, so they don’t need to re-architect the code, they can just “translate” TypeScript to Go, then clean up where makes sense or needed. For a good while (definitely years, probably half a decade, if you ask me) while both projects are maintained, adding fixes and features will be therefore easy. The two codebases can be expected to have almost the same output and bugs, both is good for maintainability.
With Rust, the translation wouldn’t work as Rust is significantly different. This would mean rethinking everything, the architecture would diverge, resulting in two possibly very different set of bugs. With different structure, tweaking both at the same would be very difficult.
One alternative that we are using is scalingo as a replacement for heroku.
I doesn't have all of the same features as heroku, but the features that are there work really well. For instance the UI is better and more responsive than heroku's.
On top of that it isn't more expensive than heroku and does not have pricing traps the way heroku does. Their live chat is also an upgrade over support tickets.
I'd definitely give it a go if I were on the hunt for a European PAAS provider.
I'm really not a fan of the "what colour is your component" situation introduced by RSC.
RSC is a cool feature, but I'm still not convinced that the added churn of thinking about "colours" when building components and structuring the component tree is worth it for the benefits it gives.
It is a solution when all your developers are bootcamped on react for 6 months and don't know how to run a proper back-end. Managers like it because their front-end react dev can add a back-end feature NOW and in 1 hour.
It’s awful and I’m pretty sad that it seems the entire nodejs community has adopted next.js as standard. All projects I’ve been involved with use it and none of them use any SSR at all.
That's mostly because `create-react-app` was abandoned. There is no default project template for React SPA, so everyone just uses Next, even if they don't need SSR.
Add in tailwind and a router of choice (I love wouter) and you've got 90% of what you need to build most applications. Vite is so much simpler than webpack and the rest that came before, it's a tiny amount of work to do this.
A lot of things exist. But to become a go-to standard a good timing is required. Next.js was getting popular right at the time Facebook abandoned 'create-react-app' template, and many people adopted Next.js even if they didn't need SSR. Vite didn't exist back then.
It's a really strong selling point that you can use a popular FE framework for all the templates, but at the same time almost completely avoid state management.
> but at the same time almost completely avoid state management
Unless you're just building simple landing pages (I think the context is "web apps" here) or something, you might not have removed any state management, you've just moved it elsewhere.
So the question is, where did you move it instead? The backend?
That is a good point, and I can see that I probably did not communicate what I meant clearly enough.
In my experience most of the state management in FE apps is about fetching and handling data from different types of APIs. With inertia you get a very simple abstraction in that each page gets its own little API. Then inertia takes care of feeding the data from that API to the rendered page when you navigate to it.
For that reason the page can be a "dumb" component, and there really isn't much state to manage.
If the app needs modals, dropdowns, forms e.g., you will need to manage the state of those in the browser, which I think is very reasonable.
Obviously there can also be situations where you'd want to have a small part of the page to fetch some data asynchronously, and for those you'd need to use something else - inertia doesn't do everything.
I'm happy I didn't have to scroll too far to see this.
Git's CLI isn't elegant, but it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc.
I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works.
The same can be said about regexes.
Regexes and git are probably the two tools which I have benefitted the most from learning compared to how little time I've spend on learning them - and I wouldn't even consider myself an expert on either.
> it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc.
Yes, that's what people mean when they say that git is hard. Instead of presenting you with an interface expressed in terms of the domain you intend to work in, whose commands represent the tasks you intend to perform, git dumps its guts all over the place and requires each user to re-implement the interface between "what you want to do" and "how git is built" inside their own brains instead. Once you have written git's missing user interface in your brain, you are fine; but that's a lot of work which is not necessary with other version-control systems.
>I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works.
For example: you have bazilion ways to achieve the same thing, all of them having its own quirks/advantages?
It is just poorly designed, that's it, lol.
I like to joke that if somebody else invented Git, then it'd be 10% less powerful, but 10 times more user-friendly
But any software evolves over time so if it had fewer ways of doing things in the past, it would very likely eventually pick them up because people have use cases for the advanced features.
It's like complaining about languages ("English is hard to spell and doesn't have consistent pronunciation" etc.), they're constantly changing and that kind of thing is going to happen eventually...
Inertia is "dumb" in that a component can't request data, but must rely on that the API knows which data it needs.
RSC is "smarter", but also to it's detriment in my opinion. I have yet to see a "clean" Next project using RSC. Developers end up confused about which components should be what (and that some can be both), and "use client" becomes a crutch of sorts, making the projects messy.
Ultimately I think most projects would be better off with Inertia's (BFF) model, because of its simplicity.
reply