A MPA, no-bundler JavaScript meta-framework separating client- and server-code

Modern JavaScript meta-frameworks like Next.js, Nuxt, Astro, SolidStart, SvelteKit and Qwik all use a bundler/transpiler (like Vite or Webpack), and with the exception of Astro and Qwik, all of them are SPAs.

I would love to have a modern JS meta-framework that does away with these two conventions, but instead chooses to optimize for simplicity and leveraging browser-built-ins over client-side JavaScript:

Why? I think that for most use-cases (i.e. if you’re not building the next Figma or Google Docs), this will provide both superiour UX and superior developer-experience.

A bundler (and related tooling) is just such a massive addition in complexity that the developer needs to understand in order to debug certain issues. It seems to be a historical accident (because bundlers have their roots in tooling for client-side-only SPAs) that lots of functionality is implemented in bundlers instead of in plain JavaScript functions, which you would call either during static site generation or during server-side rendering: like how import.meta.env is replaced in the build step and not accessing the env variable when you run the server, or how CSS or SVG files are included into a component. This makes it unnecessarily difficult to call the vite-based code, that you wrote to render some HTML on your webiste, in a script (e.g. in a cron job to send an email). Also, the newcomers to modern JS-tooling that Astro targets routinely struggle with what exactly the behaviour of <script> and <script is:inline> is (in addition to forgetting to add client:load to hydrate islands).

Finally, with the exception of Astro, all the modern meta-frameworks ship with some kind of RPC functionality that doesn’t make the network request explicit, and without forcing the developer to handle network errors: use server in React/Next.js and SolidStart, as well as server$ in Qwik.

Leave a Comment