4 ms·

Did you see the performance issues also on web components that didn’t use shadow dom? I noticed this performance wall as well, but I always put it down to shado

by Joeri 3y ago

Did you see the performance issues also on web components that didn’t use shadow dom? I noticed this performance wall as well, but I always put it down to shadow dom being heavy. Now I’m wondering if it is the instantiation itself that’s heavy. For state mgmt I have noticed the same problem and was thinking about trying to take a page out of desktop development’s playbook by having a window-level message bus that all components subscribe to and filter data from, and every state change being published on that message bus.

mdhb 3y ago
ShadowDOM is actually a big part of the reason where the perf comes from because the universe of what actually needs to be considered in order to get to the eventual answer of what style properties should any given element actually have is tiny due to the fact that it is encapsulated. That and the the other big win comes from using native compiled C++ browser code to implement large chunks of what libraries typically provide in userland JS. React is probably the worst offender here as it for all intents and purposes brings its own implementation of both DOM and events. It’s just an outdated architecture choice that made a huge amount of sense at the time but nobody would do that today if they were building a front end library from scratch. Finally regarding your point about the message bus idea you might want to take a look at the BroadcastChannel API if you aren’t already familiar with it. Sounds like it might be what you’re looking for.
- wg0 3y ago
  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 anything about routing in context of web components? Deep linking? Any pointers? Noob backend guy here.
  - 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)); }

by Joeri 3y ago

mdhb 3y ago

ShadowDOM is actually a big part of the reason where the perf comes from because the universe of what actually needs to be considered in order to get to the eventual answer of what style properties should any given element actually have is tiny due to the fact that it is encapsulated. That and the the other big win comes from using native compiled C++ browser code to implement large chunks of what libraries typically provide in userland JS. React is probably the worst offender here as it for all intents and purposes brings its own implementation of both DOM and events. It’s just an outdated architecture choice that made a huge amount of sense at the time but nobody would do that today if they were building a front end library from scratch. Finally regarding your point about the message bus idea you might want to take a look at the BroadcastChannel API if you aren’t already familiar with it. Sounds like it might be what you’re looking for.

wg0 3y ago
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 anything about routing in context of web components? Deep linking? Any pointers? Noob backend guy here.
- 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)); }