Framework-agnostic components across React, Vue, Angular
cross-framework component strategy and its trade-offs.
web components for one core, framework wrappers for ergonomics, codegen as an alternative, with their costs.
What's really being asked
This probes architectural judgment for serving many frameworks without rewriting components three times.
The full answer
Lay out the three strategies with trade-offs. Web components offer a single, standards-based implementation that runs anywhere, but they have friction: passing complex props and handling events across framework boundaries is awkward, typing and form integration need extra work, and server-side rendering with the shadow DOM is harder. Framework-specific wrappers, hand-written per framework over a shared core, give the best ergonomics and types but multiply maintenance across React, Vue, and Angular. Code generation produces idiomatic native components per framework from one source of truth, balancing reuse and ergonomics, but adds significant build and tooling complexity and can leak abstractions. A pragmatic answer is often a hybrid: implement core logic and styling once, perhaps as web components or a headless core, then ship thin generated or hand-written wrappers per framework for ergonomics and types. Whatever you choose, share tokens and styling across all outputs and version them together.
The mistakes people make
Declaring one approach universally best. Ignoring SSR, typing, and event-handling pain with web components. Underestimating the maintenance of per-framework wrappers. Treating codegen as free.
What usually comes next
How do web components handle SSR and forms? How do you keep wrappers in sync with the core? Where do tokens live in a multi-output build?
A concrete example
You build the core as web components for shared behavior and styling, then generate thin React, Vue, and Angular wrappers that map native props and events to the custom element and add proper types. All three consume the same token build, so a brand color change ships once and reaches every framework.
Interview question
What is a real trade-off of using web components as the single implementation for a multi-framework design system?
- a.Props, events, typing, and SSR integration are more awkward across frameworksCorrect
- b.They require rewriting the component once per framework
- c.They are incompatible with every modern browser
- d.They cannot be styled with design tokens
Why? this is the answer
Web components give one implementation but introduce friction with complex props, events, typing, and server-side rendering across frameworks. They can use tokens, run in modern browsers, and specifically avoid per-framework rewrites, which is their main appeal.
Just read this? Test yourself on what you have been reading.
Read the original → thenewstack.io
- #web-components
- #cross-framework
- #distribution
- #architecture
- #tradeoffs
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles