Settle frontend architecture

[marein]

The frontend has been an after thought. Let's change that.

Although the current implementation, meaning "traditional" server-side rendering with some custom elements, is only cobbled together to provide "some" user interface, it has proven its worth as no maintenance was required thanks to backward-compatible browsers and the stability of web standards. The main goal is to apply progressive enhancement and hypermedia controls with the least amount of dependencies and asset size wherever possible.

However, there is some room for improvement here, which should be considered:

• Assets (js, css, images) should be versioned so that they can be cached for a long period of time. Latest browser features like script[type="importmap"] could be of good use.
  Version assets #191
• Since js files aren't (and won't be) bundled, custom elements could only be imported when they are needed, loading only necessary bytes for a specific view. Not bundling assets certainly comes with disadvantages, such as file compression being less efficient or having to be careful not to create waterfalls. The advantage is development speed (opinionated), fewer tools, fewer things to run in development, and the possibility of granular lazy loading.
  Load custom elements lazily #193
• To enable faster page transitions and have the ability to keep some elements on the page, links and forms should be intercepted and manually navigated/submitted, replacing only the DOM needed on the page. Possible sticky elements could be chat widgets and simultaneous games, for example.
  Add dynamic page loads #195
• The names of custom elements should follow the same naming convention, e.g. they should be prefixed with their domain name.
  Unify prefix for custom elements #196
• Custom elements currently use the DOM api directly for changes. While this is more efficient since event listeners know what they need to update, it has an affect on readability and development speed. Changing the structure, e.g. for the game board, is cumbersome due to the imperative nature of the api. Templating libraries based on template literals could smoothen the process, e.g. lit-html or uhtml. However, maybe the first shot can just be rendered server-side, mitigating the issue from a different angle, solving the same problem.
  Use a design system #232 (ships uhtml)
• Decide on a design system or rewrite the current css.
  Use a design system #232
• Use early hints for faster page loads. Not yet.
• Assets could be minified by using an AssetMapper compiler Not yet.
• Drop service-js-polyfill as all modern browsers should be able to support the shipped polyfills by now (except script[type="importmap"]).
  Version assets #191
• Maybe, just maybe, keep service-js-polyfill in order to host 3rd party modules (as an internal CDN) without the need to install npm on the main application image. But public CDNs can be considered for this playground project too.
  Going with public CDNs for simplicity and Symfony's AssetMapper can now download dependencies.