3 ms·

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

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.

willsmith72 3y ago
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
- ramesh31 3y ago
  >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.
  - willsmith72 3y ago
    Fair enough. Genuinely wondering, what flexibility do you get by not having an app server?
    - ramesh31 3y ago
      >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.
      - willsmith72 3y ago
        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.
the__alchemist 3y ago
JSON over HTTP.
uryga 3y ago
have you seen https://vite-plugin-ssr.com/ 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.
- redbar0n 3y ago
  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 https://dev.to/redbar0n/comment/28nbg
- ramesh31 3y ago
  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.

willsmith72 3y ago

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

ramesh31 3y ago
>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.
- willsmith72 3y ago
  Fair enough. Genuinely wondering, what flexibility do you get by not having an app server?
  - ramesh31 3y ago
    >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.
    - willsmith72 3y ago
      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.

the__alchemist 3y ago

JSON over HTTP.

uryga 3y ago

have you seen https://vite-plugin-ssr.com/ 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.

redbar0n 3y ago
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 https://dev.to/redbar0n/comment/28nbg
ramesh31 3y ago
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.