We're building an internal dashboard for a dozen staff members. Mostly tables, filters and a few editable forms; no fancy animations. The backend already returns HTML for the rest of the application. A small SPA sounds attractive for instant filtering, but I don't want to add a build pipeline and client-side routing for three screens. At what point would you stop using server-rendered pages with a little JavaScript and reach for a full client-side app?
Choosing between server-rendered pages and a small SPA for an internal dashboard
- webdev
- choosing
- between
- server
40
3 replies
For three screens, I'd stay server-rendered and add small bits of JS. Instant filtering is easy to do with a fetch call or even just swappin...
For three screens, I'd stay server-rendered and add small bits of JS. Instant filtering is easy to do with a fetch call or even just swapping the table fragment without turning the whole thing into a separate app.
Yeah, this. The moment I start needing shared client state across multiple views is when I get suspicious that I'm building a SPA by accident.
I usually only reach for a client app when the page is basically living in the browser all day. If the backend already does HTML, I'd keep forms and routing there unless the filters are so chatty that the page is constantly reloading.
I'd add one more cutoff: if the team has to support the thing for years, simplicity wins. A little JS is easier to hand over than a build ch...