If Web Components are so great, why am I not using them?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • lit

    Lit is a simple library for building fast, lightweight web components.

  • The nice thing is that if you're using a library like Lit or Svelte, you won't have to bother with the web component API much at all. https://svelte.dev/docs/custom-elements-api https://lit.dev/

  • custom-elements

    Using custom elements (by andrewmcwatters)

  • The React API is slightly nicer to use, especially with JSX.

    [1]: https://github.com/andrewmcwatters/custom-elements

  • SurveyJS

    Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

    SurveyJS logo
  • yhtml

    Tiny html tag function for rendering Web Component templates with event binding

  • The main reason is that they're too low-level to use directly.

    They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding.

    Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) as an application developer:

    https://github.com/dchester/yhtml

    It's just ~10 SLOC, admittedly dense, but which make a world of difference in terms of usability. With that in place, now you can write markup in a style not too dissimilar from React or Vue, like...

        ${this.count}

  • stencil

    A toolchain for building scalable, enterprise-ready component systems on top of TypeScript and Web Component standards. Stencil components can be distributed natively to React, Angular, Vue, and traditional web developers from a single, framework-agnostic codebase.

  • Examples like this bug me. The React example is using a high level abstraction, the web component is directly using the API. A more accurate example would show how those React calls eventually boil down to document.createElement()

    I don’t think the Web Components API was meant to be used directly all the time. You can use a framework like StencilJS:

    https://stenciljs.com/

  • uibuilder

    Typed HTML templates using TypeScript's TSX files

  • fastdom

    Eliminates layout thrashing by batching DOM measurement and mutation tasks

  • Now, every time we read `offsetHeight`, the browser sees that it has a scheduled DOM modification to apply, so it has to apply that first, before it can return a correct value.

    This is the reason that libraries like fastdom (https://github.com/wilsonpage/fastdom) exist - they help ensure that, in a given tick, all the reads happen first, followed by all the writes.

    That said, I suspect even if you add a write followed by a read to your `while(1)` experiment, it still won't actually render anything, because painting is a separate phase of the rendering process, which always happens asynchronously. But that might not be true, and I'm on mobile and can't test it myself.

  • img-comparison-slider

    Image comparison slider. Compare images before and after. Supports React, Vue, Angular.

  • * Should not conflict with anything on the page

    [0] https://github.com/sneas/img-comparison-slider

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

    WorkOS logo
  • FunPizzaShop

  • proposal-import-attributes

    Proposal for syntax to import ES modules with assertions

  • Things like HTML (and JSON) imports in ES modules, among other things, have been waiting on some safety signalling mechanics currently named "Import Attributes". Import Attributes are currently in Stage 3 [0].

    The basic security story is that browsers never care about file extensions, they care about MIME types. A developer might add an import to a third-party HTML or JSON file somewhere and expect one "safe" behavior, but the third-party could just return a MIME type of "text/javascript" and inject an entire script and the browser is supposed to respect that MIME type.

    To keep things safe, browsers want a way to signal that an import is supposed to JSON (or HTML or CSS) rather than JS and error if it gets back something "wrong" from a server request. That's one of the proposed uses for Import Attributes to suggest expected MIME types for non-JS modules in ES module imports.

    Unfortunately, there are other proposed uses for Import Attributes (things like including hashes for integrity checks) and so there have been quite a few revisions (and multiple names) for Import Attributes trying to best support as many of the proposed uses as possible, and that has slowed progress on it a lot more than some people would wish.

    [0] https://github.com/tc39/proposal-import-attributes

  • custom-elements-everywhere

    Custom Element + Framework Interoperability Tests.

  • React supports Web Components, just some quirks to be aware of: https://custom-elements-everywhere.com/

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts