I've been increasingly interested in Web Components and trying to understand how I can rewrite my historic code to use this standard. Most developers I talk to though are pretty much frontend===React: what is this strange thing you're talking about?
The dominance of virtual DOM frontends with complex lifecycles and associated tool chains means that people have invested a lot of intellectual and emotional effort into these tools and genuinely think they are the best way to deliver web experiences to people. This post is not going to change their views and I think it is genuinely hard to do that. Enterprise computing is probably going to be using React, Angular and other frameworks for a while yet.
If you are not particularly wedded to a particular frontend approach then Web Components have a few things that make them interesting. Firstly, they are standards compliant. They are available in all browsers, work consistently and require no libraries, bundles or WASM compilers to run. It is easier to re-use Web Components because of this standards approach as the baseline functionality is clear across all deployments. This simply isn't true of VueJS and React. When you make a choice of what is essentially a mini-language you are then stuck in that ecosystem with no shared runtime. Weirdly I've seen Web Components used as bridge between different components in production and it actually worked quite well, allowing different rendering and event handling approaches but co-ordinating state.
Web Components offer the opportunity to try and get back to progressively enhanced experiences that with reduced dependency on virtual rendering and Javascript could be more sustainable. They are easy to add on top of regular HTML and seem to fail with more safety than virtual rendering which tends to completely fail on a problem leaving a blank page or component.
The final thing that is interesting is that Web Components are a lower-power solution, they literally just allow you to create new elements and encapsulate behaviour. They are not also trying to provide a styling, state or templating solution so you are able to compose them with other technologies. Some people like ShadowDOM, some don't but by having smaller modules of standards-based behaviour people can use a common-base to take different approaches.
If you haven't looked at Web Components it doesn't take long to work through the basics and I would really recommend knowing them alongside any preferred virtualised framework you may have learnt or used day to day.
Top comments (9)
You are certainly right about the lock-in of these frameworks. However with SSR being the trend it is nowadays, frameworks like React can be used without browsers even needing to have JavaScript enabled in the browser.
That may not sound like much of an argument, but there really are some valid cases where you would need the UI to still work without JavaScript. What would be your take on that?
Can you name those valid cases?
Sure, I once read about a case where they were developing a website for suicide prevention. The design philosophy there was that the site should always present the information, the site should not be dependent on JavaScript to display, just in case it was turned off.
There is a growing number of people that choose to turn it off because they do not want to be tracked.
Lastly, although screen readers and other accessibility tools nowadays can cope pretty well with the modern web, those tools still struggle with SPA's.
"I once read"
"a growing number people"
Where are the sites that actual do not run on JS?
You can turn off JavaScript and see for yourself. Government websites would be a good place to start.
Fair enough, answer me this though. One of the selling points is that you could use them in any framework. So when switching from Vue to React or Svelte and with the use of SSR like Next or SvelteKit, for whatever reasons (performance?). Will those Web Components still hold up on the server side?
First of all, web components is a really good creation .It has solved some special problems in some station, but I did't think it could be applied widely because of:
2.Development Efficiency, Although, it has like: lit,omi etc base web components framework, accomplish a web component is harder than use Vue, React..(Specifically reflected in: no css html Syntax Tips, want to use css framework...)
3.SSR work, Although, declarative shadow dom become more and more complete recently(92% browser support), it does't means this will suitable for all situations, as modern front-end server rendering becomes more and more complex, there are more and more situations
I'm not sure why you think Web Components have to be written in an imperative way, I'm not sure that's true but its unclear what you mean by imperative here.
As I say in the post, I don't think it is possible to change the mind of people who like frameworks like React etc. and I don't think it is worth the energy to try and do so. There is a lot of confusion about equating Web Components with these frameworks, which I think is present in your comment (in the way you talk about CSS and SSR). Web Components aren't a framework so why try to compare them?
I mostly write backend code, and web components can be used without jumping through hoops to pass data.
It is also easier to control the javascript and css that is send to the browser. Sending a template engine to the browser, always felt wrong to me.
The newest javascript frameworks are more in line with my view of splitting frontend and backend work. But if a backend developer wants to create a frontend contribution they need to learn the custom way of doing things in that framework. That knowledge can't be carried on to another project that doesn't have that framework.
Web components will work without an extra framework.