The real problem with Web Components is simple: There is no clearly defined road to success for using them. No singular go-to guide. Up until recen...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
The first source I go to for all things HTML, CSS and javascript is MDN.
Are you alluding their web component guides are not up to date?
I think most frontend developers are too comfortable with doing everything in javascript/typescript, with an API they picked. And I think that is real problem. People invested too much time and effort in learning a third party way to create HTML.
Apart from the clickbait title, I think it is a good post!
MDN is absolutely the most up-to-date resource. But the information isn't exactly laid out in a simple way that is easy for someone who doesn't know where to start.
As for the clickbait... I would apologize, but it's working exactly as intended. π
Clickbait, if it ain't broken don't fix it :)
If you're using web components (or just custom elements without web components) and want to do server-side rendering, definitely check out Enhance: enhance.dev/. That way you can have all the benefits of custom elements and web components, and still have the SEO and performance benefits of SSR. For simpler pages, you might not even need any client-side JS at all and can still use custom elements and slots to render your HTML.
Awesome! Thanks for sharing! This looks very slick, I will definitely be giving it a test drive.
Yeah and they even have a WebAssembly version that lets you integrate it into any server-side language with WASM support, so it's not limited to JS on the server.
It is a very opinionated solution, I like my backend code a lot more malleable.
Also all the HTML I seen in the documentation is a javascript (template) string. This is something I avoid using web components.
So it is not my cup of tea.
Interesting take - to each their own. There are certain aspects of how they recommend managing state and passing it to components that I didn't like that much from a DX standpoint, but you don't have to use it in that way if you don't want. At the end of the day it's mainly just a tool for SSR, so that you can use the same custom HTML elements as on the client without having to do double the work by writing your server components with some other technology. There are also other tools out there for server-side rendering custom elements for those who want an alternative to Enhance. The important thing is that unless your app is behind a login, and you know that your users will all have a fast internet connection, server-side rendering is important for optimal SEO and UX. If it weren't for that then I would just advocate for using custom elements and web components directly without any other tools.
I wouldn't know what the benefit is to prerender web components and even less custom elements?
I think the most uses for web components will have a personalized output, like a user name, the content of a shopping cart. That is not relevant to score higher on search engines.
For the user experience I would think devices are fast enough to render a limited set of start data. You are not going to parse thousands of lines of json in a web component?
I think it wrong to see web components as an equivalent of React or Vue. Web components are not meant to generate full pages. They should be used when the combination of HTML, CSS and javascript becomes cumbersome.
I also like the web component, because I maked a frameworkless game development, where the main power was a single component with easy view ( and edit ) the lot of assets and idea of game.
flogon-galaxy-library
The details: dev.to/pengeszikra/javascript-grea...
So I upvote the work with web components, fare less resource need for that. Save the World!
This is right on time! I was literally looking for meaningful tutorials on this, and rather quickly came to the same conclusion. This is a very well written article with great explanations and examples. I'm really not a fan of frameworks because they abstract away exactly this part of the process. It keeps developers from being true JavaScript devs and pumps out react masters or angular etc. When they're just leveraging the core functionality that's been provided. It just takes a little time to learn that as opposed to using someone else's syntactic sugar. I'm sure people will defend their framework of choice, and that's ok. I'm not here to debate if they're useful, because obviously every job posting wants you to know at least 2.
pretty cool seeing web components get broken down like this - stuff always sticks with me better when i see real examples up close. ever notice if you learn faster by messing around with new code or by reading docs first?
Having good docs definitely helps to understand how things should work. But I love to experiment and push things to their limits. And I originally learned JS by dissecting websites decades ago. We didn't have tutorials or good documentation back then. Trial and error or getting inspired by someone else's idea was really the only way learn.
You fall into the same trap, you explain Web Components
by explaining its technology.
Every Web Components course teaches about "the car"
by explainining how the engine works.
I haven't seen a Web Components course yet that starts with the WHY
A car is about the journey you can take.
Similar, a Web Components course should begin with
10 distinct examples what Web Components can do.
If the intended audience is people who are already using component frameworks, then that's kind of like selling a car to someone who already owns a bicycle: they know what they'd want it for, they just aren't convinced that it's gonna be better at it than what they already have.
Boring people with examples of why they would want a thing they're already using is only going to make them stop reading before they get to the part that matters.
@dannyengelman You know this is Part 3 in the series. You have commented on both previous parts. I have already covered the "why" aspect, quite thoroughly.
@darkwiiplayer Exactly. This is meant to be a practical tutorial for those who are already interested. Part 1 was a total hot-take which weeded out those who are not and enticed those who may have been on-the-fence.
Put the cyclist in the Ford Mustang driver seat.
Give them only 7 lines of code they can immediatly play with
I was sold on HTML in 1994 with only
<H1>(I was a Gopher developer)You don't sell Web Components to
useEffectnerds by showing them MutationObserver.You don't sell Web Components by showing MutationObserver.
Totally true.
If Web Component teachers can't come up with those 7 lines of code, the technology or them teachers suck.
Where is the Mustang?
And yes, because "Web Components" encompass multiple technologies, the teacher probably needs to come up with multiple scenarios.
But still max 7 lines, for lets say, 7 scenarios.
You're analogy of car vs engine is flawed. If I were discussing the engine I would be describing the implementation details of how browsers make these features work.
What I have done here is hand over the keys to a car and showed the basics of starting the engine. Nothing more. You don't head straight onto the highway when first getting behind the wheel.
In the previous article I discussed some well established component libraries. If experienced readers want to jump right in and get rolling they have options to do so. The rest of this series will be for those who want to learn the core concepts behind this set of tools in order to fully master them.
Here in NL you will be on the highway in your first lesson at 16.
BUT, there is a certified instructor in the car, who has double controls.
Same can be done online for Web Components
<html-textarea>, <css-textarea>, <javascript-textarea>that drive a resulting<iframe>Entries monitored, layered feedback, maybe some AI?
I get the message, I have to put my money where my mouth is....
just waiting for Codex to do the work:
"Create a Web Component Tutor with 0 dependencies, only Web Components"
Pretty cool seeing a real guide thatβs not all hype or out of date. Stuff like this actually helps me get past the messy intro stage.
hmm, the article title makes it look like the author will critic web components, but didn't. lol
π
Love how you break this down, it's always felt a bit mysterious to me.
What's been your favorite real-world use case for custom elements so far?
That's a tough question to answer because I use them for so many things. But I think, if I had to pick a favorite, it would be this svg icon injector.
Thanks for this. I'm building a Web Component myself and have struggled with a lot of it. Good to know I'm not alone. ;)
Good one
Thanks for the write up.
I've only vaguely looked into web components in the past. To this day I'm still waiting to get "sold on" by web-components, but still find limited reasoning behind why I should look into it as a technology.
There is a mention of:
So I'll keep an eye out, as practically what web components needs to offer is something that makes it worth to switch compared to tried and true alternatives. Otherwise it will just stay a curiosity of mine.
This is a decent overview, but the title is just clickbait. There is no problem. All of this is documented the same place and in the same exhaustive manner as every other web standard: MDN
This is the first practical tutorial in this series. There will be more to come. I guarantee that I will be covering much more than these basic concepts.
But you're wrong about there not being a problem. The problem is that framwork-centric devs think that there is a problem. The title serves to hook that audience. You may call it clickbait, but the correct term is Sensational: Presenting information in a way that is intended to provoke public interest and excitement, at the expense of accuracy.
I think misdirection is the correct term. Letting people think it is about the left hand, but everything happens with the right hand.
I wanted it to be good, only support in Apples browser is not good enough.
If you look at the web platform tests you will see that the only area where Safari really lacks support is customized built-ins.
None of the other top interop issues have anything to do with Web Components
Safari's position on customized built-ins is well known and not really a blocking issue for using Web Components in production. This feature is a small segment of the toolkit and I have never felt like I was missing anything by not using them.
Totally agree! Web Components have huge potential, but the learning curve is steep without a clear, up-to-date roadmap.
Programming Trends Change Fast. Learn Whatβs Next β Now.
β οΈ If you see βNothing here,β try Desktop View π₯οΈ β mobile fix coming soon! π§
programming0405.blogspot.com/