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.
Well designed Custom Elements do not require pre-rendering because the content is pure markup and JS is only added for interactivity. Ideally, SSR for a web component would simply involve populating slots from a database query, like any other server generated HTML. This is most beneficial for above-the-fold content. Beyond that, constructing complex elements offscreen is no big deal, especially if you preload components that will be used on additional views.
That said, I still think Enhance is a neat concept and a great example of how these new standards are driving the development of new frameworks.
@xwero there are a lot of benefits of a component-based architecture for building web apps—take for example a reusable Card component or Image component that might be reused many times to render the initial HTML for a page. If in your use cases you don't need any components until the user interacts with something on the client, great—and I would agree you don't need something like Enhance in that case. Enhance is very focused on progressive enhancement and the phrase they use is "HTML-first"—they really try to maximize what you can do with HTML and CSS in the initial HTML returned by the server, only introducing actual client-side web components where they're actually needed (in fact they have examples of selectively loading JS so you might not even have JS at all in some pages of your app, or others where it's just vanilla JS and it's not necessary to bring in any of Enhance's client-side libraries). I suppose you could think of it a bit like if you had server-side "components" in a language like PHP that you used to build the HTML of your page, but instead of using PHP you're using JS and syntax that matches the custom elements spec so you have nice consistency between server and client code.
Behind the scenes, the basic technique they take advantage of is the fact that you can put child elements inside of a custom element, and the visible result will be the same as if you did
<my-component></my-component>and have JS code in theMyComponentclass setting its innerHTML. So that's what it does to achieve server-side rendering, and then if you need to change the HTML on the client in response to some event, that's when it becomes a true web component (otherwise it just stays as a custom element with plain HTML).This video is a good introduction for anyone interested to learn more:
youtube.com/watch?v=RaDYBFC2lHY
You don't need web components to have a component based architecture. It has been done for years with classes as a hooks.
Progressive enhancement is a term I first seen after ajax was introduced in internet explorer 6.
HTML-first is a term that was invented to make frontend developers aware that using React or Vue for every website is not a good idea, in my opinion.
Components that can be used on the server and in the browser are called isomorphic components. I think is a solution in search of a problem because the tasks of the environments are different. On the server the main goal is to push the data out as fast as possible, and in the browser it is all about showing the data as fast as possible.
I'm sorry to burst your bubble but Enhance brings nothing new to the table.
I am still struggling when to use web components. I don't see a lot of difference between
<my-component></my-component>and<div class="my-component"></div>. I even think the class way is more versatile.Web components have encapsulation for CSS and javascript, but you don't need it if you target the right classes.
The only benefit I see is that they don't need a runtime like React or Vue, so they load less javascript if you do it correct.
I think web components have their place, but it our task to use them wisely.
Well it's great then that we have so many technologies to choose from—I was never saying that Enhance was something everyone needed or everyone should use :-) I did want to correct the record though and say it does bring something new to the table for a large number of use cases. That's not something I'm going to be able to explain just in comments on a blog post, but I would just like to point out that I also remember when the term "progressive enhancement" was first talked about, and so do the creators of Enhance. The creators of it are a very mature team who have seen things develop from the early days of vanilla JS to jQuery and then all the other libraries and frameworks, trying various libraries and seeing their pros and cons (I also did this), and then creating Enhance after a lot of careful thought and consideration to fill a gap that hadn't already been filled by other approaches. I have no affiliation with the Enhance team, and TBH I've only worked on some very simple side projects with it because at my job we use React... But as someone who has been around and studied different approaches to frontend development for many years, I do think their philosophy makes sense for a lot of websites—not all of course (no silver bullets and all that)—and I have seen its benefits by playing around with it.
So based on what I have seen and compared it with, I think you are making an unfair assessment when you say it brings "nothing new to the table". That may well be true for the apps you have built, and it also might not be your cup of tea even if you were using it for a site that's an ideal use case for it. So you're entitled to your opinion but it's an opinion and not a fact that's true for everyone.
I might have been too snarky with my comment. The thing I fear the most is that frameworks that go all in on web components are going to give another blow to the already tainted perception of web components. For me web components are not a React or Vue replacement, that is why I mentioned we should use web components wisely.
I agree that smart people put together the framework. But they are selling you their vision like any other framework. If you see a benefit in that vision, use it.
BTW, it's possible that in the future, the web components spec might have more direct support to facilitate web component use cases that benefit from server-side rendering - for example, see this proposal (which is also interesting for other reasons):
github.com/WICG/webcomponents/blob...
While I don't imagine that the W3C would ever expand its scope to have official specifications for server-side technology, I think it's certainly in the realm of possibility that eventually they could have some official recommendations (not a spec but a well-documented pattern) that tools like Enhance, Lit (the server-side part), etc. could implement in a more standards-based way.
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.
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!
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
😉
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. ;)
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.
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.
Totally agree! Web Components have huge potential, but the learning curve is steep without a clear, up-to-date roadmap.
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.
Programming Trends Change Fast. Learn What’s Next – Now.
⚠️ If you see “Nothing here,” try Desktop View 🖥️ — mobile fix coming soon! 🚧
programming0405.blogspot.com/