Web Components section #13
Conversation
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
lholmquist
force-pushed
the
update-web-components
branch
from
43738ae to
c25846a
Compare
| ### Advantages and Ideal Use Cases | ||
|
|
||
| Through the teams experience with Web Components, we've identified a few different pros and cons when using Web Components and what type of applications you might want to use them with. | ||
|
|
There was a problem hiding this comment.
do you think it makes sense to add a bullet about web components being "Framework Agnostic"?
A line about independence of web components in relation to react, vue or angular for example. Not sure if we want to show their usage alongside or independent of these frameworks as well.
| The team at Red Hat has been involved in several Web Component projects and have learned a good amount about Web Components and how to write them | ||
|
|
||
| Two Web Component "Systems" at Red Hat are | ||
|
|
There was a problem hiding this comment.
like the real world examples and use cases here 👍
| - shadow DOM can be a double edged sword. Teams which are unused to it may find it difficult to work with at first | ||
|
|
||
| - Unit Testing | ||
| - JSDOM/Jest may not work with your custom elements: teams may have to author their components with node environments / DOM shims in mind, which can increase payloads to the client in some cases. |
There was a problem hiding this comment.
should we include or recommend testing strategies for web components then? Perhaps testing libraries like @open-wc/testing
| ### General Concensus | ||
|
|
||
| Authoring web components: If you have a team with web platform experience, that always have an MDN tab open, and you’re hopeful to leverage current and future web standards like PWA, then you’re likely to succeed. If on the other hand you don’t have much senior experience or depth of knowledge on web platform features, you may run into issues. However, your teams that overcome those issues will gain platform knowledge and not just framework knowledge. | ||
|
|
There was a problem hiding this comment.
not sure if we'd like to emphasize on the performance considerations for web components.
- There have been experiences when excessive DOM manipulation has resulted in performance bottlenecks. So efficient DOM updates are crucial for rendering a smooth experience.
- Shadow DOM overhead.
- Event handling overhead.
There was a problem hiding this comment.
browser engines are able to optimize rendering based on the encapsulation guarantees, as well
There was a problem hiding this comment.
and lit's rendering performance beats react most of the time (scales with interpolations instead of nodes)
There was a problem hiding this comment.
we should link out to perf studies on lit and others, and emphasize that b/c wc relies on code already in the browser, it reduces page payloads for end users
There was a problem hiding this comment.
https://www.youtube.com/watch?v=CJYkwDTaHzY vaadin lit vs react perf comparison
There was a problem hiding this comment.
https://bennypowers.dev/decks/devconf-brno-2023/#slide-27/step-1 toy app page loading comparison (2023 devconf.cz)
react: 2.5mb
lit: 230kb
|
|
||
| The framework interoperability aspect enables upgrading complex projects on a component-by-component basis. Rather than break the entire app when bumping the underlying frontend-framework from vX to vY, replace components one by one with interoperable web components. | ||
|
|
||
| ### Common Gripes |
There was a problem hiding this comment.
we ought to flesh some of these out a bit
Co-authored-by: Benny Powers - עם ישראל חי! <[email protected]>
| - [PatternFly Elements](https://patternflyelements.org/) (aka PFE) (“upstream”) | ||
| - [Red Hat Design System](https://ux.redhat.com/) (aka RHDS) (“downstream”) | ||
|
|
||
| ### Advantages and Ideal Use Cases |
There was a problem hiding this comment.
We should add a section here on architecture:
- state management
- SPA routing
- data fetching
With an emphasis on the concept that web components are agnostic to all those things, and thus can integrate with most or all. For example, there are implementations of redux, mobx, apollo, etc etc for web components
Using the PR for web components that @bennypowers originally wrote: #9 i've added the notes that we took from one of the previous meetings.
I figured i'd close that other PR and just use this one instead. All the history should still be here