Vite

Vite does two jobs that used to be one. In development it serves your source over native browser modules, so starting up is close to instant and a saved file updates the page without rebuilding the bundle. For production it hands the same code to Rollup and produces conventional split bundles. It is the least ceremonial way to build a browser application, and it has become the default for anything that does not need a framework's server half.

How we use it

It is what we use whenever a single page application is the honest answer. The Objectify dashboard is Vite plus React and a client router, which suits it: the product lives entirely behind an API key, there is nothing for a crawler to index, and route-level code splitting keeps the SQL editor out of the bundle for people who never open it. ClassProfile is the same shape, a client-rendered app whose root path redirects to a feed and then to a login screen, with no marketing surface at all.

360nutri is a mobile-first app where the interesting work is camera capture and an upload, both browser APIs, so there was no server rendering to gain. Consonas builds its Vue front end with it. Taxcare Accountancy is the interesting one, because it is a public marketing site built as a Vite single page app with code-split route chunks, roughly 85 articles and a Making Tax Digital calculator, and it replaced a Drupal site whose URLs had to survive, which we covered in keep the URLs when you rebuild.

What it costs you

Development and production do not run the same pipeline. Dev uses native modules with on-the-fly transforms, production uses Rollup, and the differences show up as bugs that only exist in one of them: a dependency that ships broken ESM, a circular import that dev tolerates, an environment variable that was inlined at build time when you assumed it was read at runtime. Not often, but always at the wrong moment.

It builds an application, not a website. There is no server rendering, no static HTML per route, and nothing in the box for meta tags, so a Vite SPA arrives at the browser as an empty div. For Objectify's dashboard that is irrelevant. For a marketing site it is a real cost that has to be bought back with prerendering, injected metadata and JSON-LD, and it stays a thing you maintain rather than a thing the framework does.

The plugin surface is Rollup's, which is broad but not universal: an occasional tool assumes webpack and needs replacing rather than configuring. Chunking is also yours to get right. The default splitting is reasonable, but on a large app it produces either one enormous bundle or a waterfall of small ones, and tuning that means reading the bundle output rather than guessing.

When we would choose something else

If pages need to be indexed, shared with a preview card, or shown quickly on a slow connection, we would use a framework that renders HTML on the server or at build time instead, which is the argument on Next.js. Taxcare works as an SPA because its content is served from a database and its prerendering was done deliberately, not because SPAs are good at SEO.

Where the front end is a handful of interactive pieces on server-rendered pages, we skip the SPA entirely and let the server render, as Laravel and PHP does. And for a static brochure site, a build that emits HTML files and almost no JavaScript is the correct answer, with delivery handled as described on hosting and delivery.