I wish there were more diversity in the world of React frameworks. I get that people enjoy using Next et. al., but I see those things as bloated beasts. There's really nothing I've found that bridges "vanilla react/redux" and full stack framework. It'd be nice to see more stuff like this inbetween, preferably with swappable data stores.
have you seen https://vite-plugin-ssr.com/ ? i've only browsed their docs, but AFAICT the pitch is that it's a more DIY approach to a framework, where you keep a lot of control over how things are wired together.
Love this. I've always thought we needed "metaframeworks" for JS. The ground shifts too quickly on things like state management, routing, styling, etc. to be locked into a single library.
This still fits into the "kitchen sink" type frameworks I try to avoid. SSR has its place, but a huge portion of SPAs are better served by the flexibility of not requiring an app server. And tightly coupling those two just seems like a bad idea for a UI framework to me.
>Genuinely wondering, what flexibility do you get by not having an app server?
Keeping the frontend and backend decoupled. Being able to host the UI anywhere that can serve HTML/JS and not have to worry about maintaining/monitoring another server. Deployments are just a CDN cache invalidation, not cycling a container somewhere. SSR is great if you're worried about SEO, but it's generally total overkill for most apps.
I don't think it's overkill for most apps anymore. The performance gains are non-trivial and actually more of a reason these days for me to use SSR than SEO.
I guess keeping frontend and backend decoupled is a matter of preference. I don't mind coupling my backend and frontend, and think it's a huge developer productivity gain to colocate components with data fetching.
If you already need a server to serve data, I actually think it just makes sense to use that server also to serve html.
