What are the sensible front-end options for a server-rendered app in the current landscape?

The middle ground is now well populated and it is where most applications in your position land.

The options, in increasing order of commitment:

1. Sprinkles of JavaScript. A small library for attaching behaviour to markup, or plain modern JavaScript. Fine for a dropdown or a toggle, and it stops scaling once state is shared between parts of a page.

2. HTML over the wire. The server keeps rendering HTML, and a small library swaps fragments in response to interactions. Your templates stay authoritative, there is no duplicated model on the client, and you keep the framework's forms and validation. For live filtering and inline editing this is usually the right answer and it is a remarkably small change.

3. Islands. Server-rendered pages with a few components mounted into them by a real framework. Right when you have a genuinely complex widget — a scheduler, a canvas, a rich editor — inside otherwise ordinary pages.

4. A full single-page application with an API. Right when the whole product is an application rather than a set of pages, or when you need offline, or when a separate mobile client wants the same API anyway.

One thing worth weighing that rarely appears in these comparisons: who maintains it in two years.

A server-rendered application with a small amount of progressive enhancement can be maintained by anybody who knows the backend framework. A single-page front end is a second application with its own build tooling, dependency treadmill and idioms, and it needs somebody who knows that too.

For a small team that is a real constraint, and it is why plenty of teams that could have gone either way are happier having not split the stack.

The counter-argument is hiring: it is easier to find people for the mainstream client-side ecosystem than for a specific backend's templating. Both are legitimate and it depends on your team rather than on the technology.

Practical suggestion: do one screen with option two before deciding anything.

Pick the live filtering one, implement it with fragment swapping, and see how it feels to build and to maintain. It is a day, it is reversible, and it will tell you more than any comparison article.

If it is comfortable, do the other two and the question is closed. If it fights you, you have learned something specific about your application that argues for a heavier approach, and you can make that case with evidence.

The question that decides it, and it is not about the three screens: do you need an API for something else?

If a mobile app, a partner integration or a second client is coming, you will build the API regardless, and at that point a single-page front end is much less additional work than it looks — you are choosing where to render, not whether to build two systems.

If nothing else needs the API, then building one purely to feed your own front end means maintaining serialisation, a second validation layer, a client-side model and its synchronisation, for screens that were working. That is the cost people underestimate, and it is ongoing rather than one-off.

So: three dynamic screens and no other consumer is close to a textbook case for option two. Rewriting is the answer to a question you have not been asked.