{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidgv7xhawlhyjpih6rmlkixghpso7yvl7j3zpbos4aodr477pkl2q",
    "uri": "at://did:plc:vrrdgcidwpvn4omvn7uuufoo/app.bsky.feed.post/3kk4ttx2il62b"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidwyjrvd5so4mbbwcq5est2lrqyn67csblqkps6tnpmyozi7gwnu4"
    },
    "mimeType": "image/png",
    "size": 40399
  },
  "description": "Web components won't take web development by storm, or show us the One True Way to build websites. What they will do is let us collectively build a rich ecosystem of dynamic components that work with any web stack.",
  "path": "/words/the-web-component-success-story/",
  "publishedAt": "2024-01-29T00:00:00Z",
  "site": "at://did:plc:vrrdgcidwpvn4omvn7uuufoo/site.standard.publication/3mmyfl3pxzi2a",
  "tags": [
    "javascript",
    "webcomponents"
  ],
  "textContent": "Tom MacWright wrote a short post wondering why we don't see prominent applications using web components.\n\nThat's a fair question!\nIt's easy to see the success of frameworks like React and Rails: just look at the thousands of websites built with them.\nWhat does the web component success story look like?\n\nContrary to some people, I don't see web components on their own as a huge productivity boon for individual websites.\nOnce you've bought into a particular set of technologies, it makes sense to use it for as much as you can.\nIf you have a React app, you'd be justifiably skeptical of introducing a second way to build components!\n\nRather, the biggest benefits I see are collective, cutting across the industry as a whole.\nI think web components can make the entire web more accessible.\nThey have the potential to unify currently fragmented communities, including various JavaScript frameworks and those who avoid them.\n\nI know that's an audacious pitch, but bear with me.\n\nJavaScript Framework Interop\n\nWhenever I write about web components, I see pushback from people in the JavaScript community who seem to think that I want replace to JavaScript frameworks.\n\nIf you're in that camp, let me assuage those fears: the web component success story emphatically does not involve rewriting every React app using web components.\nAs I'll continue to say, web components and JavaScript frameworks are complementary (as opposed to competing) technologies.\nIn fact, I think JavaScript framework apps will be one of the most common places in which web components are used!\n\nDoes that mean we'll all start writing web components in addition to React components?\nNot at all.\nWhen I say that web components will be used in JavaScript framework apps, I'm talking about third-party libraries.\n\nJavaScript frameworks are tools, all tools have tradeoffs, yada yada, let's skip the preamble.\nI want to talk about one specific weakness of JavaScript frameworks: interoperability, or the lack thereof.\nAlmost without exception, each framework can only render components written for that framework specifically.\n\nAs a result, the JavaScript community tends to fragment itself along framework lines.\nSwitching frameworks has a high cost, especially when moving to a less popular one; it means leaving most of the third-party ecosystem behind.\n\nThat switching cost stunts framework innovation by heavily favoring incumbents with large ecosystems.\nIt's hard to create new frameworks, because each one has to start its own ecosystem from scratch.\nWe keep rebuilding the same set of primitives over and over and over again.\n\nThere's a famous Joel Spolsky blog post about why capitalistic tech companies contribute to open source.\nBriefly: every product has substitutes (products that can replace it) and complements (products that can be used alongside it).\nThe big takeaway is that \"smart companies try to commoditize their products' complements\".\nIn other words, they try to make it so that their own product has a proprietary advantage, while the products used alongside it are all cheap and interchangeable.\n\nBack to JavaScript frameworks.\nReact and Svelte are substitutes, while React and Radix are complements.\nAs a library author, the way to commoditize your complement is to make it work with as many frameworks as possible.\nAnd unlike in Native Land — where people have collectively spent billions of dollars over decades developing write-once run-anywhere environments — the web has one built in.\n\nMaybe you've heard of it?\nIt's called HTML, and it works with every JavaScript framework.\nFor all their warts, the fact that web components get this interoperability for free is a ridiculously powerful advantage, and libraries that don't exploit it are leaving a lot of potential users on the table.\n\nHere's a concrete example.\nxyflow is an excellent library for making flow charts.\nIt was originally called React Flow, but the maintainers renamed it when they added Svelte support.\nThey had to put in a ton of work just to support that one extra framework!\nAnd if you use Vue, Angular, Solid, Qwik or Ember, you’re still out of luck.\n\nReact has enjoyed continued success because it has a moat of fantastic third-party libraries: Radix, React Aria, React Three Fiber, Framer Motion and xyflow, among many others.\nWeb components have the potential to give us that same ecosystem — but for every framework.\n\nIslands of Interactivity\n\nOf course, plenty of websites don’t use JavaScript frameworks.\nHypermedia-centric approaches (read: how websites were built before circa 2010) are making a resurgence, led by libraries such as htmx.\n\nMany websites like this still incorporate highly dynamic elements.\nOften, these take the form of rich widgets that are missing from HTML, like menus and combo boxes.\nSometimes they're even more complicated, like interactive diagrams in articles.\nThe modern term for these dynamic regions within an otherwise static page is \"islands of interactivity\", but the pattern has existed for a long time.\n\nEmbedding these islands within the larger page has always been kinda awkward.\nThe process remains mostly unchanged from the days of jQuery plugins, relying on a complex choreography of HTML classes, CSS selectors and JavaScript function calls.\nThe bulk of the setup happens in a separate JavaScript file, far away from the HTML where the component will live on the page.\n\nWeb components invert that process.\nThey allow islands to be instantiated in the same way as any other element: by writing a tag name in the page's markup.\nAs I wrote in The Website vs. Web App Dichotomy Doesn't Exist, web components allow developers to declaratively add dynamic behavior to HTML itself.\n\nWhat makes web components particularly good companions for hypermedia-oriented libraries is the way they interact with other parts of the page.\nWhile JavaScript framework components tend to do so by invoking callback functions, web components instead embrace one of the web's core idioms: events. \nIndeed, Carson Gross's essay Hypermedia-Friendly Scripting neatly outlines this use case:\n\nA JavaScript-based component that triggers events allows for hypermedia-oriented JavaScript libraries, such as htmx, to listen for those events and trigger hypermedia exchanges. This, in turn, makes any JavaScript library a potential hypermedia control, able to drive the Hypermedia-Driven Application via user-selected actions.\n\nAs an example, here's a TIL I wrote on using htmx and the Shoelace web component library to load the content of a dialog when it opens.\nNotice how the whole process — from instantiating the dialog component, to requesting the content when the modal opens, to inserting it into the appropriate place in the DOM — is controlled declaratively via markup.\n\nThere are also HTML web components, which work by progressively enhancing existing markup rather than by rendering new DOM elements.\nColocating logic in this way, sometimes called locality of behavior, is a different lens on a concept with which JavaScript developers should already be familiar.\n\nNo More Silos\n\nThese sound like separate problems, but they're actually two sides of the same coin.\nWith web components, the library that works in every JavaScript framework also works as an island of interactivity on a static webpage.\nEven HTML web components fit into both niches.\n\nBrad Frost has called for a global design system: \"a common library containing common UI components currently found in most design systems\".\nThe proposal is to create a cohesive, unstyled, accessible and internationalizable set of components — like Radix, but for the entire web rather than for a single JavaScript framework.\nIt's an ambitious goal, and from where I stand web components are by far the best way to achieve it.\n\nWeb components won't take web development by storm, or show us the One True Way to build websites.\nThey don't need to dethrone JavaScript frameworks.\nWe probably won't even all learn how to write them!\n\nWhat web components will do — at least, I hope — is let us collectively build a rich ecosystem of dynamic components that work with any web stack.\nNo more silos.\nThat's the web component success story.",
  "title": "The Web Component Success Story"
}