Whether you smell this or not, things are changing for good.
Web Components is a suite of different technologies allowing you to create reusable cu...
For further actions, you may consider blocking this person and/or reporting abuse
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.