September 29th, 2024

Web Components Are Not the Future – They're the Present

Web Components are currently relevant, enhancing interoperability across frameworks. The article advocates for collaboration among developers to improve web standards and emphasizes the need for frameworks to adapt to these standards.

Read original articleLink Icon
Web Components Are Not the Future – They're the Present

The article discusses the current state and future of Web Components, emphasizing that they are not a distant concept but a present reality. The author critiques framework maintainers who oppose Web Components, arguing that their resistance stems from a lack of alignment between frameworks and evolving web standards. The piece highlights the importance of interoperability, suggesting that while frameworks offer unique features, they should adapt to existing standards rather than resist them. The author clarifies that Web Components are not direct replacements for framework components but rather a foundational technology that can enhance interoperability across different frameworks. The article calls for collaboration among developers to improve web standards and frameworks, advocating for a shift towards a more unified approach that prioritizes stability and user needs over proprietary interests. The author concludes that the future of web development lies in embracing Web Components and evolving frameworks to work with them, rather than against them.

- Web Components are currently relevant and not just a future concept.

- Frameworks should adapt to web standards instead of resisting them.

- Web Components provide interoperability across different frameworks.

- Collaboration among developers is essential for improving web standards.

- The future of web development relies on embracing Web Components.

Related

New Web Development: Or, why Copilots and chatbots are bad for modern web dev

New Web Development: Or, why Copilots and chatbots are bad for modern web dev

The analysis critiques Copilots, chatbots, and React for web development, citing slow sites, complex code, and high costs. It advocates for a shift to browser APIs, CSS, and HTML for better performance and lower expenses. Transition challenges include finding developers skilled in vanilla JavaScript. Organizations are urged to prioritize simplicity, efficiency, and core web technology training.

We moved away from web components – learnings from a Component-First DevTool

We moved away from web components – learnings from a Component-First DevTool

Corbado, a startup, transitioned to framework-specific components like passkeys for user authentication in 2024. The move aimed to improve developer experience and meet evolving needs efficiently. The blog post covers benefits, challenges, strategies, and recommendations for startups considering a similar shift. It explores scenarios favoring a component-first strategy and details building web components using various technologies. The discussion guides developers in navigating the JavaScript UI component-first startup landscape.

Show HN: Plain Vanilla – a tutorial website for vanilla web development

Show HN: Plain Vanilla – a tutorial website for vanilla web development

The article discusses web development using only HTML, CSS, and JavaScript, emphasizing Web Components and modern CSS. It encourages experienced developers to explore this simpler, standards-based approach for building applications.

Server-First Web Components with DSD, Htmx, and Islands

Server-First Web Components with DSD, Htmx, and Islands

Web Components gained universal browser support by 2020, with streaming Declarative Shadow DOM widely supported in February 2024, enabling server-rendering techniques applicable across various frameworks. A course is offered for further learning.

The Neverending Story

The Neverending Story

The article highlights that corporate attempts to dominate web technologies often fail, while collaboration on web standards like HTML, CSS, and JavaScript ensures accessibility and long-term success over proprietary solutions.

Link Icon 1 comments
By @veidr - 7 months
> They're not Solid components. They’re not React components. They’re not Svelte components.

I don't go on Twitter much since that oligarch bought it (causing most of the people I used to follow there to leave), but I happened across [some discussion](https://x.com/youyuxi/status/1839833110164504691) of this article there yesterday.

To me, the topic is interesting, because at work I both use and advocate for using "Web Components" instead of Angular(!), or even Svelte or Vue, or whatever awesome framework. When feasible, anyway.

It got more interesting, though, when I clicked through and saw the follow-up discussion, which I will summarize thusly:

- Vue.js creator: Web Components will not win

- Svelte creator: wasted so much time on Web Components before realizing they suck, and certain people promoting them are acting obnoxious

- React team guy: yeah we ditched them quickly, too

- Ex-Angular core guy: word

- SolidJS creator: ATTENTION! Web Components are not only trash, they are the biggest threat the web has ever seen

- Guy who wrote the above-linked blog post: NO, THEY'RE AWESOME, FUCK YUO!!!!!!

As a person who builds various apps, by myself and with teams, my perspective is pretty different from these framework (or library/compiler) guys.

I would like the code I and my team produce to have a reasonably long and simple service life, so Web Components are attractive, because they are part of the browser platform. They evolve much more slowly, and still have many pain points. They are certainly not as good, in and of themselves, as "components" from any of the above frameworks.

(I haven't actually used SolidJS or Vue, but I'm presuming they are roughly similar to Angular, React, and Svelte, all of which require a lot less fuckery up front, and do more for you.)

But, that stability. So this blog post seemed reasonable to me at first glance.

But after I finished it, I was a little more wtf? than when I was half way through. The last sentence (rather melodramatically IMO) is, "The component war is over."

Like, ...what "war"? Can't we just go ahead and use Web Components even if we do use Svelte, or React, or Angular, or...? Yes, we can; that's what my teams have been doing for a while now.

So where's the war? I think he's conflating two things. Web Components were indeed intended, at least originally, to be useful for framework authors. Who apparently aren't superfans, of either web components generally, or this blog post specifically.

OK; that's actually sort of orthogonally interesting.

But, in any case, we mere web app developers can indeed just go ahead and use Web Components. They're part of the browser platform now. And we can also use whatever frameworks offer enough ROI to make it worth using something that isn't part of, but rather sits on top of, or compiles down to, the browser platform.

So after reading this whole post, it seemed to me that it wasn't saying "you should use web components, they're awesome!" but instead saying "you shouldn't use something that isn't web components, because that's lame and I don't like it, and moreover those framework guys shouldn't keep making those not-web-components things because the WAR is OVER!!" — which is self-evidently ridiculous.