Whether you smell this or not, things are changing for good.
Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilise them in your web apps
These are a specification of the W3 Consortium, and are a standard across all browsers (or are at least promised as such). This technology means that there might soon no longer be any need to rely on third party frameworks (you only need to rely on relevant tools for now), install bloat, or learn for months on end, to make a seemingly basic modern web application. If you want to write code for the future web right now, i.e where the buzz-following herd of web developers will be in, say, 2 or 3 years, this is the right technology for you. This article will help you get started.
You may ask why you should ditch the cool React, and the swag-ful Angular, and Vue 😎 and the rest of this post aims to explains this.
The stepping stones into developing applications for the web, or even static sites to some extent, have for very long been frameworks. You maybe spend two days trying to learn HTML when you get thrown at yourself words like "React", "Angular" or "Vue." This means that learning HTML(&CSS) and JavaScript is not enough to effectively write even beginner level applications.
You need to install some package manager like npm, go through some command line hell, (and assuming you are learning react, lets say) install create-react-app, run create-react-app, which will take a half hour or more even if your machine is above average (hard disks, ugh).
This is the easiest path and right now, you have not done anything. This here is just scaffolding for your code. Now you need more boilerplate react code, and alas, you need also Redux, and also 20 react libraries for that one animation (which is taken for granted in modern day web), and more... You need to make the choice between hooks and class based React (which does not mean anything to you, who just learnt about setTimeout last weak). Well it does not stop here, the hell that is, but you get the idea.
This is not the way writing code should work. If all frameworks out there ultimately aim to achieve the same fundamental functionality, and your client is using pretty much the same browser and the very same Internet, why is there not a standard way, which is common, and which we teach developers to build their applications, unless their project demands an exclusive, high level, opinionated framework, suited for their specific needs. If JavaScript Web frameworks right now pretty much do the same thing for me and you: normal, sane developers, looking to build web applications of the same sort of which millions already exist, why not? Why not future safe, non-isolated, plug and play?
(Please do not write bullets about how these buzz frameworks are different, they are not for me. They are not for my friend who wants to get into webdev, they are not for that comp sci graduate, they are different for you, a 25 year old JS developer, because Angular uses a two-directional data flow process where it updates the Real DOM directly while React updates only the Virtual DOM and abracadabra alakazam hocus pocus)
My point is that if you are a developer of the web, who is adequately skilled with JavaScript and some of the tools, you should switch your energy to the new standard: Web Components. Maybe not at this low level directly, but maybe try lit-html and Lit Element which are both very elegant solutions to reach framework-like functionality with minimal desire to bump your head on a wall. The article I linked above should be adequate.
Top comments (12)
I had this discussion at work. It seems admirable but ditching a framework doesn't seem very reasonable, instead waiting until the moment is right to take this on. The huge nail in the coffin for me is the death of html imports, a promising technology that would have paved the way. I think the web is going in a different direction, led by developers and the majority.
Html imports are dead? I was so excited to see those...
I was kind of waiting with the whole trying of webcomponents because i wanted to experience the whole package, which i think, imports are very much part of.
Yeah it's a shame but after polymer I think it was realized that we didn't need to achieve web components in quite the way the spec imagined it. Remember just because it's a proposal or in spec doesn't make it a good idea. Look at js with statements, that's an awful lot like destructing.
Spec does not make it good, agreed. Except it does for learners. All learners will around the world learn the same spec, and they will be confident that they don't need to use tools of which they have no knowledge (webpack babble npm node to name a few) just to achieve basic functionality.
But I'm afraid in business these tools are mandatory in modern JavaScript.
HTML imports are an excellent idea. It was perhaps not a great specification. But keep in mind it was the fact that browsers were going to be implementing ES Modules more than issues with HTML Imports that got in the way. That some of the same problems had to be solved with both and that they covered similar use cases. There was a sentiment: first, do this with the lower level, less abstract, ES Modules and then come back to the higher level, more abstract, HTML module and import feature better informed.
Browser vendors and engineers are making the mistake of forgetting that pandering to business interests is probably not what catapulted the web to millions of users. If it had been who the web was giving priority to designing for, obsfucation, data mining, and DRM would have been big priorities built in from the start.
This is the state of imports as worked on right now, I believe there may be an image import also. As for my opinion, I am trying out lit-html to see what I can do with the bear 🐻 minimum.
Yeah, since some new standards now have bigcorp sponsorships, and one particular bigcorp is inventing straight up web/user-hostile platforms from monopoly position, i guess pretty soon diversity will play much bigger role.
I dont know if it was such a big deal in other countries, but in mine, everyone was switching to Firefox like crazy ~10 years ago and 46% of users are using *AdBlock.
This rebellion against a giant greedy corp. usually needs a match on gasoline, like latest moves to kill adblocks in chrome.
(I've gotten the impression that HTML Imports from the Polymer days are definitely dropped and succeeded by...HTML Modules? And some other stuff, maybe. I dunno if that's what it looks like, been too busy to take a look. But "some kind of HTML imports, not necessarily 'HTML Imports.'")
Just an opinion (so take this with a metric ton of salt) but I'm not sure that we should talk about Web Components and other popular frameworks/libraries as if they were competing technologies or opposing methodologies.
Most of the popular frameworks can use Web Components with no issues and at least a few of the frameworks can be configured to produce web components (Svelte comes to mind).
Framing the conversation as "WC's vs. Framework" starts the conversation with someone feeling as if they have to defend their stack. Considering the amount of time and effort most of us put into our work, that conversation will never end well.
Which is a shame considering how useful WC's are both alongside and in lieu of a stack.
Web Components complement frameworks very well, and it is not frameworks vs web components for everyone. It is frameworks vs web components where it does not matter to your project what framework you use (i.e you are using fundamental functionality, common in all such frameworks which is provided by spec now)
Note this from the article:
"This technology means that there might soon no longer be any need to rely on third party frameworks ... install bloat, or learn for months on end, to make a seemingly basic modern web application."
I think this exaggerates a bit and that doing so isn't in the best interest of anyone. Application frameworks are designed for building applications and doing so "at scale" (which in this case means lots of humans working in the Bay Area, rather than lots of users or anything else).
Web Components aren't. They're for extending HTML with custom components. That's fine. Especially when you consider that people tend to over-use application frameworks when they don't actually need them.
But WCs won't replace frameworks for everyone, nor should they. And the frameworks will evolve on top of and around them. That's also fine.