| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 40, deep dive hosted on December 12, 2024 with Ben Callahan and Scott Jehl. There are 97 answers. The question this week was: ----- Hello curious people! My friend Scott just released an online course on web components and I’ve been chatting with him this week about how far this technology has come in the last decade. Web components offer us “a standard component model built right into our browsers, and using its various technologies can help us cut delivery weight and reduce complexity.” (From Scott’s course!) Perhaps now, more than ever, is the time to lean on web components as a way to support many teams with your design system assets. However, most of the folks I’ve worked with have opted out of a web components approach for their systems. This week, we want to better understand if and how folks are relying on web components in their design systems. Welcome to The Question for the week of Dec 9, 2024! Have you evaluated web components as a technical solution for your design system in the last six months? Do you use web components in your design system? Why or why not? | |||||||||||||||||||||||||
2 | Question 1: Have you evaluated web components as a technical solution for your design system in the last six months? | Question 2: Do you use web components in your design system? | Question 3: Why or why not? | |||||||||||||||||||||||
3 | Yes | No | There are better app and web server-side solutions, also accessibility is tricky | |||||||||||||||||||||||
4 | No | No | N/A | |||||||||||||||||||||||
5 | Yes | Yes | They allow teams working with different frameworks e.g react vs angular to consume the same components, saving a lot of development work. | |||||||||||||||||||||||
6 | Yes | No | The technology, ecosystem, and community isn’t mature. They’ve moved and evolved very slowly, bad developer experience, devs kept running into brick walls. If web components become good or useful, react will compile to them like vue. Until then we’ll take DX, community, and ecosystem that keep up with our needs over arbitrary “standards”. | |||||||||||||||||||||||
7 | Yes | Yes | In the large organizations that we build design systems for they often use a myriad of different front end technologies. Web components enable those teams to integrate the design system regardless of the front end stack. However, they’re not without their challenges. SSR is the greatest problem to solve so far but we’ve had some success with our clients in that area. Tooling for web components is great now. Lit is a fantastic tool that I’ve found most clients have hit the ground running with. | |||||||||||||||||||||||
8 | No | No | Not quite there yet! But interested | |||||||||||||||||||||||
9 | Yes | No | To be honest, I keep asking why not use web components and never get a straight answer. I started asking over 5 years ago! And I've never dived in to answer the question for myself. | |||||||||||||||||||||||
10 | Yes | Yes | We consider components to be a building block in our DS | |||||||||||||||||||||||
11 | Yes | Yes | We have an old web component UI library and want to upgrade this one matching the latest technology, integrate tokens. | |||||||||||||||||||||||
12 | Yes | We plan to. | Other teams are currently using web-components in their systems and the initial plan of the system was to offer an agnostic solution such as this; we just have not gotten to that part of our roadmap yet. | |||||||||||||||||||||||
13 | I'm not familiar with web components, but I'd like to listen to the discussion. I'm going to invite one of our devs to participate, too. | I'm not sure. | I've heard the devs mentionning the concept, but I'm not sure if we use web components in our design system. | |||||||||||||||||||||||
14 | No | No | We haven't evaluated web components, but plan to in the next six months. | |||||||||||||||||||||||
15 | Yes | Yes | We're trying to support a multi-brand, multi-platform set of products, so someone before me chose Stencil web components with React and Vue wrappers. I'm not a fan of the shadow DOM. It makes accessibility very challenging or hacky. It also breaks the natural flow of basic components, like table. | |||||||||||||||||||||||
16 | No | Yes | Framework agnostic, evergreen technology | |||||||||||||||||||||||
17 | Yes | No | Engineering largely doesn't understand design systems, and isn't willing to collaborate to understand the value of Web Components. At 2 companies, I've pitched Web Components successfully, only to have someone on the engineering side of the house come in and throw out all the work (6+ months, in both cases). In one case, the pivot to Angular Material was met with a return to Web Components a year and a half later, so 2 years of thrown out work. Cultural issues are the main contributing factor (see above, lack of system knowledge), but also I perhaps would have done some groundwork to discover who the Web Component champions on the engineering side are in product prior to pitching them as a solution and having it viewed as "Why is UX pitching a technology decision?" | |||||||||||||||||||||||
18 | Yes | No | Currently building against react, not sure the loe for learning and training on web components will be worth the end result. | |||||||||||||||||||||||
19 | No | Legacy components are web components but the switch to React was made in 2023 because of an org wide change to recommend React. | ||||||||||||||||||||||||
20 | Yes | Yes | We chose web components due to their browser compatibility and the ability to separate their styling from traditional methods of creating components with HTML and CSS classes. | |||||||||||||||||||||||
21 | Yes | We are in the proof of concept stage with small risk integrations | We seem to be heading in this direction and are validating the effort to create and support | |||||||||||||||||||||||
22 | No | No | Sorry, I am a less technical person, can not answer these questions properly. | |||||||||||||||||||||||
23 | Yes | No | Still evaluating the pros and cons and I’d it will incur more technical debt over time than using a framework | |||||||||||||||||||||||
24 | I have in the past but not in my current role | I am actually not sure | I will find out! I have in the past and found them very useful. | |||||||||||||||||||||||
25 | No | Yes | They are needed for browser based experiences. | |||||||||||||||||||||||
26 | Yes | Yes | We have a wide range of tech stacks at the company, using different version. We had to pick an agnostic solution and Web Components made the most sense. | |||||||||||||||||||||||
27 | No | No | I’ve read a bit about web components, but haven’t used them. Our design system is built in React, and I don’t see us moving away from that any time soon. | |||||||||||||||||||||||
28 | Yes | No | Trying our best to introduce web components despite a lot of inertia. We recognize the power of web components in supporting both react and non-react platforms, but the cost of refactoring the code is too much. We'll have to see in the next major release. -Arko | |||||||||||||||||||||||
29 | Yes | Yes | it's the way the engineering wanted to go we deal with a decent amount of external stakeholders and they are good way to keep the integrity of the system | |||||||||||||||||||||||
30 | Yes | Yes | Platform agnostic and easy to roll out to many frameworks | |||||||||||||||||||||||
31 | Yes | No | Not the right time for where our systems given our capacity and other priorities. We are at but we are considering it for our next major release. | |||||||||||||||||||||||
32 | No | Yes | Work smarter, not harder. 😉 | |||||||||||||||||||||||
33 | No | No | Lack of awareness and knowledge of its benefits | |||||||||||||||||||||||
34 | Yes | No | We started exploring expanding our offerings to include a web components version of our React component library earlier this year, but the team was defunded before we got to implementation. | |||||||||||||||||||||||
35 | No | No | Around a year ago, when we were re-evaluating our design system implementation options, I suggested web components to help future proof our design system investment. Our web code bases were predominantly React. The team stuck with their status quo, React, given that all consuming teams were also using React (so there wasn’t a dependency size gain to be had). What followed was a nasty dependency alignment problem, where projects across the company had to upgrade React in lock-step to avoid multiple React packages. Web Components would have very cleanly sidestepped this, while also allowing product teams to consider UI libraries other than React, another considerable pain point. I still believe WC with thin React wrappers would have set us up for long term success. Unfortunately, these risks are difficult to quantify and prioritize during the technology evaluation phase. The internal status quo and industry wide norm of React is very challenging to dislodge. | |||||||||||||||||||||||
36 | Yes | Yes | Web components are an integral part of any design system, either consuming other components or delivering aspects of the design system as components. | |||||||||||||||||||||||
37 | Yes | Yes | we started exploring Micro-Frontends nearly 4 years ago and it's evolved into a Web Components based approach. Recently, the company has decided to create a Design System to unify the look & feel of our product offerings. While the initial implementation of that Design System was done in React, we're currently working on a Web Component implementation to allow us to be more platform agnostic... | |||||||||||||||||||||||
38 | Yes | No | I don't use them in the design system I'm currently working with... it's a legacy product... but I have used them in other projects. I've recommended their use in any future re-platforming of the UI... especially as a simple means of progressively enhancing HTML via HTML Web Components, where we start with plain HTML and wrap it in a <custom-element>. | |||||||||||||||||||||||
39 | Yes | Yes | Yes, using web components in a design system aligns perfectly with the principle of being not tied to a specific tech or framework. Web components are built on open web standards (like custom elements, shadow DOM, and HTML templates), making them scalable, flexible, and highly interoperable across different frameworks (React, Angular, Vue, etc.). Advantages: + Not tied to tech or framework: Web components work with any modern JavaScript library or framework, or even plain HTML/JavaScript, ensuring the design system is future-proof and not locked into a specific ecosystem. + Scalable and Flexible: Once created, web components can be reused across projects with minimal modification, enhancing scalability and flexibility. They are modular, encapsulated, and self-contained. Challenges: - Slower learning curve: Implementing web components requires familiarity with newer browser APIs and possibly libraries like Lit or Stencil to simplify development. - Difficult to build: Compared to pre-built frameworks like Material-UI (MUI), which come with ready-to-use, opinionated components, building web components requires more effort to set up and maintain. If the focus is on long-term scalability, flexibility, and independence from a particular tech stack, web components are an excellent choice, despite the upfront investment in development and learning. | |||||||||||||||||||||||
40 | We launched with web components. The community didn't want them, they wanted react. Lead developer didn't want to provide that from a system perspective. He just exited probably a week or two ahead of the announcement that there was react support for them. | |||||||||||||||||||||||||
41 | used to be an on/off subject a while ago. Landed nowhere, shifted focus to other needs | No | browser support issues | |||||||||||||||||||||||
42 | No | No | Early in the formation of our design system, the building blocks had been extracted from one of our products as React components. Once we identified that a significant portion of our products already used or could use React, we decided to continue to invest in the React ecosystem. (Additionally, standardizing on shared tools like react-intl for localization helps with consistency of development) | |||||||||||||||||||||||
43 | No | No | We don't have any developers assigned to the DS and our whole organization is on React. | |||||||||||||||||||||||
44 | Yes | No | Challenges with server rendering web components in PHP | |||||||||||||||||||||||
45 | No | No | Our web products are all in React, or for legacy Rails views, committed to migrating to React as they modernize. There is not a lot of Web Component expertise at the company. There is a sentiment that the React ecosystem is more mature for UI development. Anecdotally, I've heard that testing Web Components (built with Lit) is not as convenient as with React components, and this would certainly be a concern for the team. I think there's probably a lot of nuance to questions about performance, but this would certainly be a concern for our team. I anticipate that there would also be concerns about introducing more complexity into the frontend stack with Web Components (and a framework like Lit). | |||||||||||||||||||||||
46 | Already using them. | Yes | We opted for web components for all the reasons you’d think. But we also have a React library since web components faired poorly in performance tests we did with them in a Next.js app using server side rendering. Maybe things will be different with React 19 and it’s better support of custom elements? | |||||||||||||||||||||||
47 | Yes | No | Our design system is implemented independently in Preact and an in-house PHP/mustache/JS framework. We’re investigating web components as a way to consolidate to one library that works in both. Because it’s so difficult to support server-side rendering and JS-less environments with shadow DOM (to benefit from template-ing and slots), we will likely not be able to adopt web components. | |||||||||||||||||||||||
48 | Yes | Yes | My engineers have told me—and continue to tell me—that web components are the industry standard and the future of modern web development as well as enterprise design systems. | |||||||||||||||||||||||
49 | No | No | Investment into React is so deep. | |||||||||||||||||||||||
50 | Yes | Yes | We use them to provide a standard and consistent experience on web to our native apps. | |||||||||||||||||||||||
51 | Yes | No | It becomes overly complex when addressing accessibility | |||||||||||||||||||||||
52 | No | No | The devs told us that they don't cover everything we would need, and that it's not mature and expansive enough | |||||||||||||||||||||||
53 | No | Yes | We do since they’re a more flexible framework that can function with the different coding languages and legacy frameworks that our products currently use. The only issue that our consumers complain about is the shadow dom. | |||||||||||||||||||||||
54 | Yes | Yes | They give us the benefit of personalization and creating components that suit exactly our needs. | |||||||||||||||||||||||
55 | No | No | I am not sure, but would love to understand more about the benefits! | |||||||||||||||||||||||
56 | No | No | I've heard of design system teams authoring their components using Web Components and then delivering those components to product teams using different JS frameworks via some sort of wrapper architecture, but I haven't found the time to research this approach. Our entire company is currently in the process of migrating from old custom MVC architectures over to going all-in on React so we only need to worry about building React components at this time. | |||||||||||||||||||||||
57 | No | No | I need to be lead by my engineering partner's on this, and don't have the knowledge to assess it. | |||||||||||||||||||||||
58 | Yes | Yes | We use web components because it gives our consumers the best chance to be future facing for tech debt and allows us to support the most products in our company which is a mixed bag of technologies from Angular, React, to Vue and anything in between. | |||||||||||||||||||||||
59 | No | No | haven't had the time or people | |||||||||||||||||||||||
60 | Yes | Yes | We're using it because we have an agnostic DS working on Angular, React, and Vue in 55+ products and 250+ Repositories. | |||||||||||||||||||||||
61 | No | Yes | Our enterprise engineer frameworks are agnostic, which leave product team to pick and choose based on skillset. Our legacy Design System was hard-code HTML, CSS, and JS. This did not play nice with React. The new system is built on Web Components, which will be launched in Q2 2025. | |||||||||||||||||||||||
62 | No | No | I'm not yet sure where web components would be the right solution. Hoping to learn more in this talk. | |||||||||||||||||||||||
63 | Yes | Yes | Re-usability, consistency, most of traffics happened on a browser on mobile device. | |||||||||||||||||||||||
64 | Experimented with using web components in a hackathon setting, for initial evaluation. | No | We already have the system built using react, and currently don’t have engineering bandwidth to rebuild the components. | |||||||||||||||||||||||
65 | Yes | Evaluating them | Need to find the best timing to integrate into the existing product lifecycle in the least disruptive manner. | |||||||||||||||||||||||
66 | No | No | I came into a heavily React-based environment so there hasn't really been space to consider other options. | |||||||||||||||||||||||
67 | We haven’t had the capacity to truly evaluate them unless you count watching what the community is doing. We are so entrenched in React and maintaining our existing system that getting resources to justify exploring a new platform seems like science fiction. | No | I’m all for them on the basis of web standards principles! But principles only get us so far. There seem to be some real solid efforts out there like Fluent, Web Awesome and now USWDS which is admirable. I think WC have an uphill battle since they have been around for as long as they have but failed to materialize something that can compete with the speed of modern JS frameworks. It would take a significant cultural shift among our engineering team to dedicate real effort and resources to making them a part of our design system. | |||||||||||||||||||||||
68 | Yes | Yes | Versatility and standards | |||||||||||||||||||||||
69 | Yes | Yes | It retains the wider purpose of off loading some of the heavy tasks like ally , theming to web components and makes life of the applications which use these web components easier. | |||||||||||||||||||||||
70 | Yes | The company I joined had a failed web component library. Consuming teams found it difficult to integrate into their C# Blazor web apps. | I've read a lot about the front-end frameworks attempts to have a compile target of web components, and how React, Vue, SolidJS, Svelte, and Ember teams have failed to do it. Furthermore supporting web components in those frameworks is also not trivial. It feels like web components (aka custom elements), are better for mostly static sites with a sprinkle of isolated interactivity as opposed to web apps with integrated data flows | |||||||||||||||||||||||
71 | Yes | Yes | forward thinking and feature filled components | |||||||||||||||||||||||
72 | Yes | Yes | We're launching our DS around Feb 1, 2025. Components will be a big part of the offering. | |||||||||||||||||||||||
73 | Yes | Yes | Our DS team has no say in what tech stacks other teams in the org use to build applications so web components, Stencil, was the best option to have a single source of truth that can support most tech stacks. | |||||||||||||||||||||||
74 | Yes | Yes | Single implementation to support multiple frameworks (Angular, React, +more) | |||||||||||||||||||||||
75 | No | No | We are just learning how to create them and use them. | |||||||||||||||||||||||
76 | Yes | Yes | I have to make things more efficient in Figma, but also to have more consistent code in our web app. It's resourcing that's the problem. There's no one to really implement a web component library / styles properly to fully take advantage of its benefits. | |||||||||||||||||||||||
77 | No | Haven’t been in design systems work in a few years not sure what “web components means” | Im more comfortable with material Ui. | |||||||||||||||||||||||
78 | launched with web components when the community wanted react. system died, new system was spun up as a themed MUI toolkit. | |||||||||||||||||||||||||
79 | No | No | Honestly, just haven't experimented enough with them. I'm interested in learning more about what they can do and how we can leverage them in our sites. | |||||||||||||||||||||||
80 | Yes | No | Haven’t found a use (YET) | |||||||||||||||||||||||
81 | Yes | No | We are still new to them and are learning how we could use them. | |||||||||||||||||||||||
82 | Yes | Yes | I started a design system from scratch 3 years ago, and we chose Web Components (StencilJS), to allow our consumers the freedom to use any framework. | |||||||||||||||||||||||
83 | Starting to evaluate WC. We'd like to have a first use case of using them to prototype quickly with agnostic assets. We don't anticipate moving the main library off angular anytime soon. | No | Currently a lot of investment in angular assets. I'd like to see us 'baby step' into web components. | |||||||||||||||||||||||
84 | just bought the course, we saw Scott at the Smashing Conference in NYC this Oct | No | we are wanting to move that direction | |||||||||||||||||||||||
85 | No | Web Components with Stencil, outputting Angular and React libraries. | There were limitations for Angular and React teams, they couldn’t use the deep integrations that made the platform special like two way data binding and popular form dependencies. You also have to rebuild each HTML Element from scratch when trying to make custom links and buttons which felt too time consuming and too easy to make mistakes. | |||||||||||||||||||||||
86 | Yes | No | Working with component libraries | |||||||||||||||||||||||
87 | Yes | No | We want to use web components in the future but right now, as we're building a "new" design system, our internal team cannot agree on a definition of a web component. Our senior dev says custom elements is what we’re really talking about when we say web components, and I agree. But our other devs do not. So for now, we're holding on rolling out web components as a framework in our MVP design system. | |||||||||||||||||||||||
88 | Yes | No | From a purely design system perspective, web components seemed to an awesome solution to help teams have less underlying technical dependencies and modernize. However the legacy application code makes the adoption effort harder for product engineers as they have to adjust their mindset around how components works and interact which led to increased friction and lower velocity which wasn't a trade off a smaller company could take at this time. | |||||||||||||||||||||||
89 | N/A - I haven't been involved in any such discussions. There is a massive overhaul/consolidation project on the horizon, though, and I hope there will be an opportunity to discuss this option! | No | I can't speak to why or why not, since those conversations predate my tenure here and I don't work with the folks who would have made them. I *suspect* there some degree of (perceived?) technical limitations and possibly technical immaturity or ignorance, because it's just faster and easier to build what you know. | |||||||||||||||||||||||
90 | was over 6 months ago and for a contract role which i am no longer working at | currently contract so will be a question for future work in the ny | it's more to do with engineering wanting to or having the resouce and time than anything else | |||||||||||||||||||||||
91 | Yes | Yes | Web components are super flexible in terms of being framework agnostic. | |||||||||||||||||||||||
92 | Yes | Yes | We need to support multiple frameworks. We also want to leverage the platform as much as possible. | |||||||||||||||||||||||
93 | Yes | Yes | Serves as the "common" starter format and we use Lit.dev to parse those web components out into react, angular, vanilla html, etc. We chose this path for better coverage/scalability AND larger pool of supported platforms internally, rather than taking a "we do react or we can't support you" approach. | |||||||||||||||||||||||
94 | No | No | We are using React (MUI) | |||||||||||||||||||||||
95 | Yes | Yes | We have many web components in storybook and have lead the creation of out design system team. | |||||||||||||||||||||||
96 | Yes | Yes | Web components have lead the creation of our design system team | |||||||||||||||||||||||
97 | Yes | Yes | We chose this route mainly to align with industry best practices and the strategy our tech organization seems to be embracing. In building the prior version of our design system in react and angular, we found that adoption of our system was held back by not offering web components to our potential customers. The latest iteration of our system is being built entirely with web components. This move has allowed us to focus on a single implementation, rather than bespoke angular and react implementations. While there were obstacles and politics to overcome with this approach, we've solved some of the heartburn by offering angular and react wrappers for our web components, enabling a better user experience for those who aren't ready to make the move entirely to web components. | |||||||||||||||||||||||
98 | Yes | Yes | As a platform agnostic approach to supporting many teams in multiple front end frameworks | |||||||||||||||||||||||
99 | Yes | Yes | Our DS supports both native and web. Some values are share and some are separate. | |||||||||||||||||||||||
100 | ||||||||||||||||||||||||||
