Server rendering is usually enough
For forms, tables, reports and workflows — which is most business software — server-rendered pages are fast, simple, accessible by default and considerably cheaper to build and maintain.
A full JavaScript application for a system that is mostly forms and tables is a large amount of additional complexity for very little user benefit.
Three levels
| Approach | Suits | Cost |
|---|---|---|
| Server-rendered pages | Forms, tables, workflows | Lowest |
| Server-rendered plus targeted interactivity | Most business applications | Moderate |
| Full JavaScript application | Genuinely interactive interfaces | Highest |
The middle option covers the large majority of business software well and is where we start unless there is a reason not to.
When a JavaScript application is justified
- Genuinely interactive interfaces — drag-and-drop planning, live editing
- Real-time collaboration between users
- Offline capability
- A mobile application sharing the same API
- Complex client-side state that would be painful server-side
What the heavier option costs
- Two codebases to maintain instead of one
- An API layer that must be built and versioned
- Accessibility that must be built deliberately rather than inherited
- A build pipeline and its dependencies
- A broader skill requirement in whoever maintains it
Accessibility is easier server-side
Server-rendered HTML is accessible by default and breaks only when you break it. A JavaScript application is inaccessible by default and works only when accessibility is built deliberately.
For internal business systems used all day by a whole team, that difference matters more than the interface polish.