Can you build a web app with vanilla Web Components in 2024 - PART 2!

Source code: gist.github.com/cferdinandi/3...
Part 1: • Can you build a web ap...
Work on fun projects like this at the Lean Web Club. Sign up for free at !leanwebclub.com.
Hate the complexity of modern front‑end web development? I teach people a simpler, faster way to build for the web. Get free Daily Developer Tips at gomakethings.com.
⏳ Timestamps
00:00 - Intro
03:20 - Lean Web Club
06:25 - Web Components
43:11 - Conclusion

[@PDSRoxas]

Thank you, thank you, thank you for including aria and accessibility stuff. So many tutorials omit this, and it’s frustrating. Accessibility stuff should be built into codes and projects from the beginning.

[@gomakethings]

Couldn't agree more! It's sad that this isn't the norm in dev education.

[@davidluhr]

Completely agree on treating the DOM as the state of the application. It's so much simpler and the available DOM APIs are powerful. My personal favorite is using the `append` method. If the appended element is new, it'll add it to the DOM. If it already exists, it'll automatically move it into the new position with no additional work needed.

[@gomakethings]

I obviously had to keep going into the DOM a fair bit for this one, but case studies like this reinforce that it's the better approach for me: gomakethings.com/removing-react-dramatically-improves-performance-a-case-study/

[@CristianKirk]

Great stuff, thanks a lot!

[@gomakethings]

Thank you for the kind words!

[@NeilMerton]

I’m enjoying the series, thanks for putting these together 👍 Do you have any plans on showing option on how to encapsulate the web component code within the component itself and how that then gets consumed by the HTML? I hope this makes sense.

[@gomakethings]

Thanks! Can you clarify what you mean by this: "ow to encapsulate the web component code within the component itself and how that then gets consumed by the HTML?" I'd be delighted to make a vide about if, once I better understand what you're asking.

[@NeilMerton]

Sure. What I see in these two videos is you’ve got the ‘pick-at-random.html’ file that contains ‘pick-at-random’ element and below that the JavaScript to make it work. How is this then reusable? For example, I’d like to use it on a different page, how would I go about doing that. Let me know if you’d like me to elaborate further.

[@gomakethings]

@@NeilMerton Yep, that helps a lot. Thanks Neil!

[@NicklasIsraelsson]

Thanks for sharing! Very nice. Looking forward to the next session. One thing I would like to see is the thing at the end you briefly mentioned. How would you "upgrade" this to use the dialog element instead of confirm?

[@gomakethings]

GREAT suggestion! Let me add that to the list!

[@netssrmrz]

The event management feels clumsy. Do you have or could you do a video covering it in more detail? As in pros and cons compared to other methods. I'm wondering if I should change my approach.

[@gomakethings]

That's a good suggestion, thanks!

[@sueaustin6261]

would adding a title to the button svg serve as accessibility? i've heard to not mess with aria unless you really know what you're doing.

[@gomakethings]

In theory, yes, that should be enough. In reality, it's not. 😞 Many screen reader/browser combinations will NOT announce the unless you add an aria-labeledby attribute to the SVG, with a value that points to the ID of the . In the end, since you're messing with ARIA anyways, aria-label is the least complicated way to do that.

[@davidluhr]

@@gomakethings Only downside of `aria-label` is it isn't translatable. For buttons and links, I stick with visually hidden text, which I'm fine appearing if CSS doesn't load. For landmark elements, I use `aria-labelledby` and point it to the corresponding section heading.

[@gomakethings]

@@davidluhr Agreed! I've had accessibility experts argue both approaches to me over the years. For this particular project, I went with the easiest one to implement, but probably could have discussed the tradeoffs a bit more.

[@netssrmrz]

Good video. IMO a couple of mistakes though. One, the spec insists we do NOT add/remove elements in the constructor. Two, persistence (localstorage) should be handled externally to the component.

[@gomakethings]

Regarding the spec: it doesn't actually say that, though most people (including me, previously) interpreted it that way. "The specification recommends that, as far as possible, developers should implement custom element setup in this callback rather than the constructor." Does setup mean add/remove elements? Attach events? Something else? It's not clear. Hawk Ticehurst has a great article on this: hawkticehurst.com/writing/you-are-probably-using-connectedcallback-wrong/ What I do know is that setting up elements in connectedCallback is a bad idea, because it can lead to the same elements being rendered multiple times if an element is, for example, moved with the append() method. You can prevent it by using special .loaded properties or whatever, but just doing it once in the constructor() is, IMO, a lot more bulletproof and simple.

[@gomakethings]

Regarding localStorage, there are many ways to handle it. Outside the component (with some event to trigger the behavior) is one possible solution. Calling it a mistake is disingenous, though. What you really mean is "I would have approached this differently." That's fine, of course. The best and worst thing about JS is that there's always more than one way to do a thing. But the approach I used in this unscripted first pass isn't a mistake. It's just not what you would have done.

[@netssrmrz]

@@gomakethings re constructor: Spec seems very clear to me. MDN: "In the class constructor... you should not add new attributes or children". HTML Standard 4.13.2: "When authoring custom element constructors... The element must not gain attributes or children." And you can prevent double loading by using methods like replaceChidren(). Hawk's post is about event listeners and not rendering child elements.

[@netssrmrz]

@@gomakethings re localstorage: I'm not going to sugarcoat my take for a grown man. In my opinion, it is a mistake to couple this UI component to a persistence mechanism (you know why, I know why, everyone knows why). Granted your solution is passable as a first draft for educational purposes but it can be easily improved, and should be. In my opinion.

[@gomakethings]

@@netssrmrz I'm not asking you to "sugarcoat" anything. But let's be clear: your opinion is not the same thing as fact. You disliking something doesn't make it wrong. Senior developers constantly and arrogantly insisting something non-obvious is obvious is, frankly, why I have students. I'm asking you to engage in polite discussion. If you want to do the techbro reply guy thing, this isn't the right channel for you. This is the only time I'm going to say it. Next time, you get blocked.