https://www.mediawiki.org/wiki/Design_Systems_Team/Server_rendering_background_info identifies several possible methods for rendering reusable UI components on the server:
- **Client-side only**: don't render anything on the server. This is the simplest to implement, but makes the UI unusable for users of older browsers or users without JavaScript.
- **Server-side only**: don't use any JS-based interactivity at all. This requires HTML+CSS-only implementations of (some) UI components, and limits how interactive the UI can be, but it'll work for everyone.
- **Progressive enhancement**: render the UI on the server, as above, but add minor interactivity in JavaScript. Works best for simpler UIs with small amounts of interactivity.
- **Separate server and client implementations**: render one UI on the server, then another more feature-rich one on the client. Requires a lot of duplicate work.
- **Vue server-side rendering (SSR)**: implement the UI once in Vue.js, use Vue's SSR feature in Node.js to render a static version of it on the server, and then run the same code on the client for the interactive version.
(For more information about each of these approaches, see https://www.mediawiki.org/wiki/Design_Systems_Team/Server_rendering_background_info )
These aren't meant to be mutually exclusive options. The idea is not to choose one option and reject the others. Instead, I'd like to try to identify which approach should be used in which situation (and maybe some of these approaches should be avoided / discouraged / not be used).
Please give your input on these questions:
- Are these the right approaches to look at? **Are there other approaches that we should consider?**
- Is more information needed about any of these approaches? **Do you have pros/cons/considerations to add?**
- In your view, **when should which approach be used?** Are there any approaches that you think **should not be used?**
- Is anything unclear to you? **Do you need more information? Do you have any questions?**
I hope that this will spark a discussion which will lead to a (rough) policy for when it's appropriate to use which rendering method. Once we have that, we can then delve into the architecture and implementation details of each approach where needed.