-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
Also have a look at https://vite-plugin-ssr.com/ (author here).
VPS is slightly lower level which gives you a lot more control: integrate with your existing Node.js backend (use any backend framework you want), deploy anywhere, use any React alternative (Solid, Preact, ...) and any data fetching tool (e.g. Relay can't really be used with Next.js).
The flip side is that you've to write a little bit more glue code. Although this will be alleviated by a lot with projects such as Bati[0], Stem[1], and vike-react (see Vike Rebranding[2]).
VPS also cares a ton about details, such as hooks for full control over i18n (use any i18n strategy you want), better Base URL support (VPS supports setting a different base for your server and your CDN), automatic deploy synchronisation, domain-driven file structure, polished and helpful error messages (especially the next upcoming release), ...
Detailed comparison with Next.js: [3].
If you run into any blocker then it's quickly fixed (or at least a workaround is proposed).
It supports not only SSR and pre-rendering, but also SPA in case you don't need SSR. It's going to support RSC but doesn't yet (RSC isn't ready for production).
Because it's lower level and because it's decoupled from React everything is designed in an agnostic way and with meticulous care. In other words: vite-plugin-ssr is becoming a robust foundation. There are breaking changes coming for the v1 release but beyond that chances are that there won't be any breaking change for years in a row.
In a nutshell: vite-plugin-ssr takes care of the frontend and only the frontend. You keep control over your architecture. (Whereas frameworks tend to put themselves right in the middle of your architecture restricting you in fundemetanl ways.)
Last but not least: it's powered by Vite which means blazing fast HMR.
[0] https://batijs.github.io
[1] https://stemjs.com/
[2] https://github.com/brillout/vite-plugin-ssr/issues/736
[3] https://vite-plugin-ssr.com/nextjs-comparison
Hey Lee! Thanks so much for responding.
What's not clear to me is where do the providers go (ReduxProvider, ReactQueryProvider etc)?
Can they be instantiated up tree in a server component somewhere? And if that's the case, what data do they hold when on the server and what happens a client component tries to interact with the provider?
Or should I render as much as possible via RSC and put the providers in the first client component in the tree?
I've been trying to keep tabs on the GitHub issues and Discord that discuss this, but I have to admit, it's a bit over my head. The best resource I've found so far to understand how libraries are adapting is from Apollo's RFC here: https://github.com/apollographql/apollo-client-nextjs/blob/p...
Have you considered Deno? First class TypeScript support, secure sandboxing, and JIT rendering for React/Preact style projects with Fresh (https://fresh.deno.dev).
Also, they recently introduced a Node compatibility feature that supports _most_ modules. You can import directly from NPM using the npm: specifier, or import (almost) all of the builtin Node APIs using the standard node: specifier. Since recent versions (1.30+) of Deno are bundled with whats essentially a Node clone, and since its all packaged as a ~32MB executable... I've found myself just using Deno for everything lately. So far its been able to handle all of the projects I used to run with Node.
Check out their docs: https://deno.land/manual