Lit developers build and maintain the Web Components library that delivers React-comparable developer experience — reactive properties, declarative templates, and scoped styles — using the browser's native Custom Elements, Shadow DOM, and HTML Templates APIs without a virtual DOM, enabling components that work identically in React, Vue, Angular, Svelte applications, or plain HTML pages without recompilation or framework adapters. At remote-first technology companies, they serve as the frontend and platform engineers who build the design system component libraries and micro-frontend elements that multiple application teams consume across different framework stacks — delivering the framework-agnostic interoperability that React component libraries cannot achieve, combined with Lit's 6KB runtime that ships far less JavaScript than React-based alternatives.
What Lit developers do
Lit developers define custom elements — extending LitElement with class MyButton extends LitElement { ... } and registering with customElements.define('my-button', MyButton) to create reusable HTML elements that work in any framework; define reactive properties — using @property() decorator for public attributes that trigger re-render on change, @state() for internal private state, and type: Boolean/Number/Object/Array for automatic attribute serialization; write templates — implementing the render() method that returns html\<button @click=${this.handleClick}>${this.label}`using Lit's tagged template literals that efficiently update only changed DOM nodes; define scoped styles — usingstatic styles = css`.button { color: blue }`inside the component class to create Shadow DOM-scoped CSS that doesn't leak out or accept incoming styles, preventing CSS class name conflicts; implement event handling — using@click=${handler}in templates for DOM event listeners,this.dispatchEvent(new CustomEvent('my-event', { detail: value, bubbles: true, composed: true }))for cross-Shadow-DOM events, andcomposed: truefor events that should cross Shadow DOM boundaries; implement lifecycle callbacks — usingconnectedCallback()for setup when the element is added to DOM,disconnectedCallback()for cleanup,firstUpdated()for post-render DOM access,updated(changedProperties)for reacting to property changes; implement slots — usingin templates for default slot content andfor named slots that consumers fill with light DOM content; implement CSS custom properties — usingvar(--my-color, blue)inside Shadow DOM styles to expose theming hooks that external CSS can customize despite Shadow DOM encapsulation; integrate with forms — implementingformAssociated: trueand theElementInternalsAPI for custom elements that participate in HTML forms with validation and submit behavior; integrate with React — using the@lit/reactpackage to create React wrapper components that adapt Lit's event-based API to React's callback props; integrate with Angular, Vue, and Svelte — using the respective framework wrappers or@lit/vueand framework-native custom element support for consuming Lit components in each ecosystem; implement SSR — using@lit-labs/ssrfor Node.js server-side rendering that hydrates on the client; and configure TypeScript — using Lit's first-class TypeScript support withtsconfig.jsontargetES2019or higher,useDefineForClassFields: false`, and the lit-plugin VS Code extension for template type checking.
Key skills for Lit developers
- LitElement: extends LitElement; customElements.define; reactive properties; render()
- Properties: @property(); @state(); type options; reflect; attribute; hasChanged
- Templates: html
; css; @event; .property; ?boolean; ${expression}; repeat() - Shadow DOM: encapsulated styles; ::slotted; :host; CSS custom properties; parts
- Events: @click; addEventListener; CustomEvent; bubbles: true; composed: true
- Lifecycle: connectedCallback; disconnectedCallback; firstUpdated; updated; performUpdate
- Slots:
; named slots; slot content; slotchange event - Framework adapters: @lit/react; React wrappers; Vue custom elements; Angular elements
- TypeScript: @property TypeScript types; template type checking; lit-analyzer; strict mode
- SSR: @lit-labs/ssr; renderToString; hydration; declarative shadow DOM
Salary expectations for remote Lit developers
Remote Lit developers earn $88,000–$152,000 total compensation. Base salaries range from $74,000–$125,000, with equity at technology companies where framework-agnostic component reusability, design system interoperability across multiple application stacks, and Shadow DOM encapsulation directly determine the maintainability and adoption of shared UI component libraries used across an engineering organization's diverse product portfolio. Lit developers with design system architecture expertise building large component libraries consumed by React, Angular, and Vue teams simultaneously, SSR implementation using @lit-labs/ssr for content-delivery-critical Web Component applications, form-associated custom element implementations for complex input components, and demonstrated cross-framework component adoption reducing per-team UI duplication command the strongest premiums. Those with Lit combined with deep browser platform knowledge — Custom Elements, Shadow DOM internals, and the CSS Custom Properties system — earn toward the top of the range.
Career progression for Lit developers
The path from Lit developer leads to senior design system engineer (broader scope across design tokens, accessibility, theming, and cross-framework component distribution), frontend platform engineer (owning the component library infrastructure, build pipeline, and documentation systems for multi-team engineering organizations), or browser platform engineer (specializing in web standards — Custom Elements, Shadow DOM, Web Components, and the emerging HTML and CSS features that enhance Web Component capabilities). Some Lit developers specialize into micro-frontend architecture, using Web Components as the framework-agnostic contract layer between independently deployed micro-frontend applications from different teams. Others transition into web standards contributions, participating in the W3C and WHATWG working groups that define the Custom Elements and Shadow DOM specifications that Lit builds on. Lit developers with strong accessibility expertise become the engineers who ensure that Shadow DOM-based components implement ARIA attributes, keyboard navigation, and focus management correctly — an area where Web Components have historically had gaps.
Remote work considerations for Lit developers
Building Lit component libraries for distributed engineering teams requires component API documentation, Shadow DOM boundary conventions, and cross-framework wrapper standards that allow distributed engineers to consume components in their application frameworks, extend components without breaking Shadow DOM encapsulation, and implement theming without fighting Shadow DOM's style isolation. Lit developers at remote companies document the Shadow DOM theming contract — defining which CSS custom properties each component exposes as theming hooks (e.g., --my-button-color, --my-button-bg), and documenting that external CSS selectors cannot reach into Shadow DOM to override internal styles — because distributed engineers from React backgrounds attempt to override component styles with application-level CSS that the Shadow DOM boundary blocks; establish the composed: true event contract — documenting that custom events must set bubbles: true, composed: true to cross Shadow DOM boundaries and be receivable by ancestor elements outside the component's shadow tree — because distributed engineers implementing component events that omit composed: true create events that work in test but not in application code where the listener is outside the shadow root; document the @lit/react wrapper pattern — providing a standard template for wrapping Lit event APIs as React props (onChange → my-change event listener) — because distributed React engineers consuming Lit components without the React wrapper encounter event handling that doesn't follow React conventions; and establish the part attribute CSS exposure pattern — documenting that ::part(button) allows external CSS to style specific element parts inside Shadow DOM without full style exposure — as the standard approach for allowing consumer style customization beyond CSS custom property tokens.
Top industries hiring remote Lit developers
- Enterprise design system organizations where Lit's framework-agnostic Web Components enable a single component library to serve React applications, Angular enterprise applications, Vue.js portals, and legacy jQuery or plain HTML pages without maintaining separate framework-specific implementations
- Micro-frontend organizations where each micro-frontend team uses a different framework but all teams consume shared Lit-based navigation, layout, and design system components through the Web Components standard interface that every framework supports natively
- Google Cloud and Chrome developer tool companies where Lit is Google's own component library solution — used in Google's own design systems (Material Web, Polymer successor) and developer tools — creating direct demand for Lit expertise in Google's ecosystem of partners and tooling companies
- Multi-tenant SaaS platform companies where customizable Lit web components with CSS custom property theming enable white-label UI customization per tenant without shipping framework-specific code to each tenant's embedding application
- Publishing and content management companies where server-side rendered Lit components via @lit-labs/ssr deliver Web Component-powered interactive elements on content pages with SEO-friendly HTML that hydrates progressively rather than requiring full client-side JavaScript for initial render
Interview preparation for Lit developer roles
Expect component definition questions: write a Lit component for a toggle button that has a checked reactive property, displays different text based on state, emits a change event with the new boolean value when clicked, and styles itself with scoped CSS — what the LitElement class, @property, render(), css``, and CustomEvent look like. Shadow DOM questions ask how you'd allow consumers to style the background color of your Lit button component from external CSS — what CSS custom properties look like inside Shadow DOM styles and how a consumer applies them. Slot questions ask how you'd implement a card component with a named header slot and a default body slot — what the template <slot name="header"> and <slot> look like and how consumers use them. Event questions ask why a custom event fired inside a Lit component isn't receivable by a React parent component outside the Shadow DOM — what composed: true does and how you'd fix it. Framework integration questions ask how you'd use a Lit component in a React application and what the @lit/react package provides — what the createComponent() wrapper looks like for mapping events to React props. SSR questions ask how @lit-labs/ssr renders Lit components on the server and how the client hydrates them — what declarative shadow DOM looks like in the server-rendered HTML. Be ready to compare Lit with React for component library development — when the framework-agnostic portability of Lit justifies the smaller ecosystem versus React's larger tooling and component universe.
Tools and technologies for Lit developers
Core: Lit 3.x; lit npm package; LitElement; html template literal; css template literal. Properties: @property() decorator; @state() decorator; type (String/Number/Boolean/Object/Array); reflect; attribute; noAccessor. Directives: repeat(); map(); when(); choose(); until(); live(); ref(); ifDefined(); classMap(); styleMap(); unsafeHTML(). Shadow DOM: mode 'open'/'closed'; attachShadow; ::slotted; :host; :host(); ::part(); CSS custom properties; adoptedStyleSheets. Events: @click shorthand; .addEventListener; CustomEvent; bubbles; composed; detail payload. Lifecycle: reactive update cycle; updateComplete Promise; performUpdate; scheduleUpdate; hasChanged. Context: @lit/context; createContext; consume decorator; provide decorator. Reactive controllers: ReactiveController; hostConnected; hostDisconnected; requestUpdate. Framework integration: @lit/react createComponent(); @lit/vue; Angular custom elements; Svelte native support. SSR: @lit-labs/ssr renderToString; LitElementRenderer; @lit-labs/ssr-client hydration. Testing: @web/test-runner; @open-wc/testing; chai + sinon; browser-based testing. TypeScript: experimentalDecorators; useDefineForClassFields; lit-analyzer (VS Code); typed properties. DevTools: Lit DevTools Chrome extension; Custom Elements viewer. Build: TypeScript + tsc; Rollup + lit; esbuild; Vite + lit-plugin. Alternatives: FAST (Microsoft, enterprise); Stencil (design systems, framework output); Hybrids (functional); Vue (similar reactivity, framework lock-in); React (ecosystem, framework lock-in).
Global remote opportunities for Lit developers
Lit developer expertise is in strong and growing demand globally, with Lit's position as the leading Web Components library — backed by Google, used in Google's own design systems including Material Web Components 3, and adopted by companies including Adobe (Spectrum Web Components), Salesforce (Lightning Web Components is Lit-based), and Red Hat (PatternFly Web Components) — creating consistent demand for engineers who understand both Lit's reactive component model and the browser platform APIs that Web Components build on. US-based Lit developers are in demand at enterprise design system organizations, micro-frontend platform teams, and Google ecosystem partners where Lit is the natural component library choice. EMEA-based Lit developers are well-positioned given the European enterprise software industry's frequent multi-framework environments — large European financial services, insurance, and government digital transformation programs often have diverse technology stacks where Web Components' framework neutrality is a genuine architectural requirement rather than a theoretical benefit. Lit's continued development — Lit 3.0's improved TypeScript support, @lit-labs/ssr's stable SSR path, and the growing Web Components ecosystem including form-associated elements and scoped custom element registries — ensures sustained engineering demand as Web Components adoption in enterprise design systems accelerates.
Frequently asked questions
How does Lit's Shadow DOM encapsulation work and what are the mechanisms for theming and style customization? Shadow DOM creates a separate DOM subtree for a custom element where internal nodes are hidden from the main document's CSS selectors — document.querySelector cannot find elements inside Shadow DOM, and CSS rules from the main page cannot directly style Shadow DOM internals. This encapsulation prevents style conflicts (your button's .blue class can't be accidentally overridden by the application's .blue class) but also prevents intentional external styling without explicit hooks. CSS custom properties: custom properties (CSS variables) cross Shadow DOM boundaries — var(--my-button-bg, white) inside Shadow DOM reads the value of --my-button-bg from any CSS context, including the main document: .theme-dark { --my-button-bg: #333 }. This is the primary theming mechanism. CSS ::part() selector: the part="inner" attribute on a Shadow DOM element allows external CSS to style it: my-button::part(inner) { border-radius: 8px } — this targets only the explicitly exported part, not arbitrary internal nodes. :host selector: styles the custom element's host element from within the Shadow DOM: :host { display: block; } or :host([disabled]) { opacity: 0.5 }. ::slotted() selector: styles light DOM content that is slotted into the Shadow DOM: ::slotted(p) { margin: 0 } — styles slotted children but not their descendants. Design token approach: Lit design systems typically expose a comprehensive set of CSS custom property tokens for colors, typography, spacing, and border-radius, documented as the component's theming API.
How does Lit's reactive property system work and what is the difference between @property and @state? Lit's reactive properties drive the update cycle — when a reactive property changes, Lit schedules an asynchronous microtask update that calls render() and efficiently patches only changed DOM nodes using its template system. @property decorator: marks a class field as a reactive property that is observed as an HTML attribute on the custom element — @property({ type: Number }) count = 0 means <my-counter count="5"> sets count to the number 5 (via type conversion), and changing count triggers a re-render. Attribute reflection: @property({ reflect: true }) causes the property value to be written back to the HTML attribute when changed programmatically — useful for CSS :attr selectors and debugging. @state decorator: marks a field as reactive private state that triggers re-renders but is NOT reflected as an HTML attribute and is not part of the element's public API — equivalent to React's useState for internal component state. hasChanged: both decorators use a hasChanged comparison (default: strict equality) to decide whether to schedule an update — for object properties, @property({ type: Object, hasChanged: (newVal, oldVal) => !deepEqual(newVal, oldVal) }) enables deep equality checking. TypeScript typing: @property() label: string = 'default' provides TypeScript type for the property; Lit infers the attribute type from the JavaScript type. Batching: multiple synchronous property changes batch into a single render() call — changing this.count = 5; this.label = 'new' triggers one update, not two.
How does Lit integrate with React and how do engineers bridge the event-based Web Component API with React's callback prop model? React's event system doesn't natively listen to custom DOM events fired by Web Components — onMyChange in JSX doesn't attach a listener for the my-change DOM event because React only supports synthetic events and its own event delegation. The compatibility problem: Lit components fire new CustomEvent('my-change', { detail: value }) but React JSX <my-input onMyChange={handler}> doesn't wire this up. Solution 1 — @lit/react: the official React wrapper package's createComponent() maps DOM events to React props: const MyInput = createComponent({ tagName: 'my-input', elementClass: MyInputElement, react: React, events: { onChange: 'my-change' } }) — now <MyInput onChange={handler}> works as a React prop. Solution 2 — manual ref + addEventListener: const ref = useRef(); useEffect(() => { ref.current.addEventListener('my-change', handler); return () => ref.current.removeEventListener('my-change', handler) }, [handler]); return <my-input ref={ref}>. React 19 improvement: React 19 improved custom element support, allowing property binding and event handling for many basic Web Component patterns without wrappers; for complex event mapping and TypeScript types, @lit/react remains the recommended approach. Two-way data flow: Lit components are controlled through properties (set programmatically) and communicate back through events — this matches React's unidirectional data flow pattern when implemented with @lit/react wrappers that translate events to onChange callbacks.