3 ms·

Broadcast Channel API - unbelievable that it has such a wide support. Really amazing. Thank you for this. Didn't know that. OP above or anyone else can say an

• mdhb 3y ago
  One approach I don’t mind is to just make a HTML file per screen in the application and route like the rest of the web. When you bring in modern things like service workers and the prefetch API you can still very much keep the speed that is traditionally associated with SPAs. Otherwise I’ve seen good things said about both of these options: 1. https://github.com/vaadin/router https://github.com/vaadin/router 2. https://github.com/lit/lit/tree/main/packages/labs/router https://github.com/lit/lit/tree/main/packages/labs/router Both follow the mental model of mapping a URL pattern to a component fairly intuitively.
  • wg0 3y ago
    One file per screen is actually awesome. That's the "MPA" many frameworks are boasting about. The big win here would be that if you have a huge app (let's say an ERP kind of app that has too many screens and dialogs and what not) then that can be easily decomposed into separate pages that are far more manageable. You can easily wrap these pages up as Electron/Tauri app or Capacitor etc for mobile. Deep linking however would be interesting in that if someone pastes a URL, we have to load the exact screen/dialog etc.
    • mdhb 3y ago
      I like to keep a mental model that a page level component uses URL parameters the same way I would write a CLI application reads in arguments. Not at all meaningfully different from say void main(List<String> arguments) { runApp(MyApp(arguments)); }