I agree with the idea of supporting local non-huge businesses that still (need to) for their customers. But I think the coop concept works for more spread-out organizations as well, especially when it comes to digital services. As you mentioned, some big organizations like banks and grocery stores (that operate country-wide or even internationally) exist in Europe. There are also remote-first design/tech cooperatives around.
You might be interested in Subvert, a group of people (formerly?) from Bandcamp that are now founding a worker-/artist-owned version of Bandcamp and launching the platform soon. They basically want to avoid running into the same issues that came with Bandcamp’s recent ownership changes and the instability and worker-facing hostilities around it.
They also published a magazine explaining their thinking behind the setup, etc. – you can find out more on their website: https://subvert.fm/
Could be interesting to check out, even if just for inspiration or fun.
I would argue that Next.js pre app router was a solid and helpful framework for rendering React components on the server side (as long as your setup wasn’t too complex or you were using their own hosting service anyway). But in the recent years they really seem to have screwed up the ease of use and reliability. Nowadays, I wouldn’t recommend Next.js to anyone anymore.
What would you recommend? I’m building a fairly complex app with lots of state management. Next seems to be a good way to go, but I’d be interested if there are any better alternatives.
Just use react.... That's what I do - it is so much easier than trying to fight with Next.js.
I have a large application and I use next.js for the landing pages (landing, tos, privacy, blog, login, etc..) - but for the core application after login, I just use vanilla react with react router. For me I keep these as separate applications as I don't want to load the entire app just for the landing page or login box.
Every time I need to work in the nextjs part of the app I always run into problems and have to read the docs and troubleshoot, sift through which part of the docs apply to my setup versus the app router.
If your entire application needs to be indexed as a static site (e.g. content based versus a web application), then vanilla react isn't a good fit - so it depends on your needs.
Unrelated - but shout out to https://nx.dev. I always prefer using this for all of my projects - made it super easy to have my node backend, react frontend, nextjs landing page, chrome extension, cron jobs, etc.. all in the same codebase where I can share code between all of them via non-publishable libraries.
This approach doesn't work if you need to SSR any of the content of those components.
This is also a terrible solution UX wise. Your users will see some content and after some time (more or less noticeable, depending on resources, network conditions, etc) the rest of the components start to pop up, cause layout shifts and overal jankiness.
You either use and embrace one of these frontend frameworks or you don't and do progressive enhancement using HotWire, Alpine, Unpoly, Livewire or whatever.
The sprinkling of components is the worst of both worlds.
We may be talking about different things. I don't mean that you literally serve it as a static site, I'm illustrating React is just a view library.
The comment you responded to was about not needing NextJS and you said it's impossible to just use React if you need multiple pages or need SSR.
How so? You can have an MPA with React. If you have a server (Even if it's not NextJS) then you can do SSR. Then you can hydrate with React and manipulate as needed. This is what NextJS does.
I didn't interpret the OP to be saying "You don't need a server."
Absolutely plus one on this. LanguageTool is great and I’m also very happy on the free tier. With the app installed on macOS it also checks mails in the Apple Mail app, for example.
I basically followed that approach with my web (browser) extension: Started with the absolute basics (HTML, CSS, vanilla JS) and slowly ran into situations where I needed more modern features – notably file splitting/imports and types to manage the growing and repetitive JS code.
The approach worked for me and I learned some neat things about vanilla CSS and JS features, but I would also rather start new projects with a boilerplate or framework, because even small projects easily grow in scope and it’s nice to be prepared for the eventuality.
