Hacker News Reader

Comment by ramesh31 | Hacker News Reader

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.

View on HN

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.

see also RakkasJS which is also Vite based but slightly more opinionated.

vite-plugin-ssr (soon called Vike) and RakkasJS comparison: https://dev.to/redbar0n/comment/28nbg

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.

Remix doesn't feel bloated to me. More like express combined with react in 1, in a way that lets you write nicer Codd and more performant apps

>Remix doesn't feel bloated to me.

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.

Fair enough. Genuinely wondering, what flexibility do you get by not having an app server?

>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.

JSON over HTTP.

Reply on news.ycombinator.com