Epic: tracking the removal of react

[SgtPooki]

We want the service worker gateway to be super lightweight.. in order to do that we should remove react and make sure we have a very easy to understand and legible codebase that doesn't require transpilation or minification.

While this issue will likely be open for a long time, there are a large number of tasks that can be done to chip away at this goal:

• [ ] no config page viewing on subdomains
• [ ] 504, unknown-fetch-error, no-service-worker-error, and origin isolation warning pages should be in their own .html file in /public and not require react at all.
• [ ] remove react routing that waits for react to be fully loaded to determine which page to render
• [ ] All error pages (504, unknown error during fetch) should:
  1. unregister the service worker
  2. link to root domain config (it's on the landing page) to allow users to adjust things

I think we should still have react on the landing page because it will make development much more maintainable, but by completely separating the content retrieval and verification from the UI and react code, it will be much easier for users to verify and audit that the content they are getting is what they expect, without having to dive through a complex react ui codebase to do so.

This is mostly done with #773 and #782 (e.g. #785), but there is a lot of react that can be removed and migrated to lighter-weight javascript.

Related #773 #775 #778 #780 #782 #784 #785

cc @lidel @2color

[lidel]

Thank you for writing down this plan. LGTM.

Small update: limiting React use to main page with config sounds ok as a midway of the process, but we should define the end goal to be full removal of third party code surfaces like React.

(after switching to url-based config passing, the main page components are no longer shared with subdomains, should be a simple form read from local storage on DOM load and saved on a button press. With this new limited scope, it does not need a framework. )

[SgtPooki]

I have maintained framework-less websites (only js and css and html) that are much simpler than this one, and it's not a fun time for a developer. Is the idea that we won't have much UI or configuration at some point?

Switching to JS and not using a framework is a recipe for a painful codebase in 2-5 years, unless the config will be unnecessary or unchanged at that point.

Also, you mentioned offline that we want the codebase to be simple and not require build-time changes, so what you see is what you get.. but that currently means duplicating the headers and input element UI..

what is the concern with react? just that it's a third party library? that it's large? Are you against using any framework or solution for making the development and maintenance of the service worker gateway easier?