DOM ready events considered harmful | HTTP 203

[@ChromeDevs]

Subscribe for more HTTP 203 videos → goo.gle/ChromeDevs

[@jitumove2247]

MATRIX #1 USA.

[@talhaakram]

I really love these series, always end up taking away a lot from every episode I have watched. The hosts always do a great job explaining difficult concepts in a way that is easy to understand.

[@meqativ]

true

[@AntonKryu]

These videos show how far web development has come. Without them I would find features and would make no sense of them. Thanks.

[@roman0d]

The trick with the custom components is really clever. Personally for me, I always found MutationObservers cumbersome (still useful, but I wish it somehow was shorter - not that I have an idea how). Don't forget to disconnect your MutationObserver if/when you don't need it anymore - especially if you are observing the whole body.

[@rizkiaprita]

why is that? i probably using observer recklessly all this time 😓

[@roman0d]

@@rizkiaprita you mean why disconnecting observers? Disconnect mean "stop observing", which in turn means that your code will not continue running for each and every element - that's just a performance thing (also can be other issues like errors if not written correctly, but that's secondary)

[@PeterBriersPlus]

You really are THE guy to explain hard things with such clarity Jake. Thank you for all this. :)

[@cassieevans8790]

Right?!

[@cassieevans8790]

@@PeterBriersPlus oh it's a struggle. I try to look at a couple of web apps before breakfast to keep up with the kids, but sometimes lose my bifocals so I have to squint at them.

[@PeterBriersPlus]

@@cassieevans8790 :D

[@nathnolt]

I think it would be really cool if you did a deep dive in screen readers, how screen reader users use the web, what they appreciate in a good website, and annoyances they have with other sites, or other common pitfalls.

[@Manish-fm5iv]

Love the history because I did some of these things without truly understanding why apart from the fact someone on Stack Overflow said so.

[@offroaders123]

Thank you *so much* for covering the Custom Element lifecycle and how you can work with the `connectedCallback` order sequences! It makes more sense now that you should respond to all DOM events for the component, rather than only when it is "fully parsed", since it never actually fully finishes parsing, because of the nature of how the web works 😄

[@BenjaminAster]

Ha! Nice to see you here, Brandon!

[@offroaders123]

@@BenjaminAster Woah, fancy seeing you here! Small world haha

[@emilemil1]

I've been using a wonderfully ugly hack solution in the past. Create a promise in the head, have the async script await that promise, resolve it with a script tag after the element. The script will run as soon as possible after the element has been parsed.

[@IceMetalPunk]

...I'm with Jake, when Cassie didn't recognize the jQuery I immediately felt my hair turn white and my back start spasming. *Sigh* It's always lovely to feel ancient at age 31. Just don't talk about music or I might turn to dust 😅

[@lllIIlllI]

If it makes you feel any younger I'm younger than Cassie and I've seen it.

[@cassieevans8790]

I'm older than you mate! Just not older in web years. Late 20's career shift ☺

[@cassieevans8790]

We can both pretend to be young and sprightly for a few more years I think.

[@IceMetalPunk]

@@cassieevans8790 That does make me feel a little better, thank you ☺

[@yapet]

It’s funny how this exact topic in exactly the same detail is explained by Jake in HTTP 203 podcast more that 2 years ago! It just so happens that after watching this vid, I was hungry for some more 203 content, and came onto “how to avoid getting UTF’d by text encodings” episode. Podcast is a nice thing to have (only if you didn’t took half a year pauses between episodes 😃)

[@alanbloom20]

Extremely informative. The guy who stops the video after the answer is given at the beginning is missing important context 😂

[@DavidDarnes]

Not watched this fully yet, but just wanted to say I like that someone is putting in fun little post production effects. Adds a little extra fun 😊

[@eccenux]

Actually if you are tempted to create a custom element just to get a div-ready event you might as well use a script tag. A script tag put directly after div will be executed when the div is ready. Easy, readable, always works.

[@jakearchibald]

If that div has a src, then it'll block parsing of subsequent content while it loads, which isn't great. If it's inline, that's fair, but if there are multiple instances on the page it gets tricky in terms of where you'd place your utility scripts such as an animation library.

[@BenRangel]

4:40 I don't think I'm "that guy" but I do like the short answer here. Sometimes I watch these videos halfway and end up having this nagging feeling of "I know what the problem is but not the answer, gotta remember to look it up" but never do

[@dougrudolph5400]

I want to address Jake's quick hack that he brought up. tl;dr if you use custom elements, I recommend using a small wrapper library (reasons mentioned below), but a tool like Lit Element has a built in life cycle function that can tell you when a component has completed it's first render Thin wrapper libraries add some QoL functions and tools to your project that were overlooked in the original custom elements spec. For example, a common issue is you'd like to add HTML into these custom element components, but there is no simple way to achieve that without using something like `this.shadowRoot.innerHTML ="your-html-here"`. As most ppl know, adding HTML as a string is pretty unsafe. Another issue is that you can't detect if your custom element completed its first render. A third issue is that developers have grown accustom to some convinces like using passing around JS types as props, as well as having JSX like syntax using .map to return an array of components. To fix all this, Lit Element is a very very small library that includes solutions to the issues I'm describing. Highly recommend using this if you are making something interactive Also cheers for making another great video. I learn so much every time

[@egorkloos]

I remember that if there was a browser bug, you knew (back then) that it was "never" going to be fixed.

[@HolgerNestmann]

Great Video and quite fancy socks Jake

[@ribeirobreno]

The explanation on why the DOMContentLoaded event and the readyState related stuff was created seems off for me... the actual reason in my head is that we've always had the onload event which would wait for all content to be loaded including images, stylesheets, other scripts and even frames (the frames part is a bit murky, but pretty sure it is what it is) before being triggered. Some (probably most) of the older code running onload just needed DOM to be ready in order to bind other events and start doing it's thing, ignoring images and other stuff to download, parse and render. The defer attribute, in the other hand, was created to mess with the order of executing stuff with the inverse idea in mind: "the other things to load after don't need this script, even other scripts". And the implementation for the older IE versions mentioned in the video actually makes sense if you think like this and see that they actually worked similar to the way "async" works for modern browsers. The "problem" mentioned doesn't seem to be because people are using DOM ready events but rather their CDN which shouldn't be meddling there or including script tags blindly into their code. Now you made me miss IE... (not! hahaha)

[@jakearchibald]

The IE behaviour wasn't intentional, it was a bug. An unrelated DOM change shouldn't cause script execution order to change. In terms of DOMContentLoaded, I used the CDN thing as an example, but it doesn't need to be a third party script, it could be a first party script added by someone else on the team. Sure, you could lay a trap like DOMContentLoaded, then be careful enough to step over the trap, but why? What benefit does it give you over defer? I guess the only thing it proves is that you can safely step over that trap, but that seems like pointless showing off? The better coding practice would be to avoid adding traps to your codebase.

[@ribeirobreno]

@@jakearchibald About defer it seems fair, no reason to say it wasn't a bug unless my vague memory is correct and Microsoft wasn't working from the W3 spec (as was usual during the 90's). About DOMContentLoaded, the trap is blindly adding scripts to the codebase no matter by who or when or where. Semantics is important, so why would people use something that says "defer this to a more convenient moment later" when they actually meant to express "do this when we have the DOMContentLoaded"? If the standard says otherwise, isn't it the standard being crazy? Similar issue as the first pageshow event triggering after the load event when people have been staring at the page since before DOMContentLoaded: the spec is crazy, not the script.

[@jakearchibald]

@@ribeirobreno they weren't working from a spec with defer, but their implementation didn't match their own description of the feature. The semantics of `defer` on script elements is defined by the HTML spec. The crazy thing would be to use an objectively worse feature because you prefer its name.

[@ribeirobreno]

@@jakearchibald I fail to see "worse", except in the naming of things and the way the spec is written now. Think about this: If a younger developer reads a piece of code without knowledge of the spec, what is more understandable or easier to find the meaning of? defer, DOMContentLoaded or readyState? And, if this doesn't seem like a problem, ask yourself defer to when? In the end, a feature is just a feature and a bad practice (namely: including scripts blindly into code) doesn't justify using one feature over another but naming things in a self evident way may be a good factor to consider. After seeing the issue presented in this video, it does bring an issue with code quality which is that mixing defer with DOMContentLoaded may be a bad thing. In fact, we probably don't have a point of using defer at all: just use async, the "dom ready" events or change your script tag position in html depending on your intention.

[@jakearchibald]

@@ribeirobreno I don't think the naming is a good arguement. DOMContentLoaded - Images are content, right? They're in the DOM, so it must fire after images load! It doesn't, of course. Something like "parseend" would be a better name, and it would fire as soon as parsing is complete, and the document isn't being render-blocked by CSS. The behaviour I just described there is `defer`, not DOMContentLoaded.

[@murtazahussain6570]

Wow.. I am huge fan of your talks.. keep it up ❤️

[@Aragorn450]

These things are quite helpful for me, being just a BIT older than Jake... I cut my teeth in web development in those bad old days of IE and standards and then haven't really done front end development since. I've done a few years of Node recently so my JavaScript is up to snuff again, but not the web and browser standards.

[@jonathan-._.-]

the "and finally ..." bait :D

[@andreidvoynos6183]

1:27 Man I felt old when she said she didn't recognize that 😂

[@31redorange08]

She's very probably old enough, just hasn't seen many web apps, it seems.

[@cassieevans8790]

@@31redorange08 not doing dev when jQuery was a thing is pretty different from 'not seeing many web apps'. But yep! Same age as Jake. No need to feel old. Just 'young' in web years compared to Jake who's practically wizened.

[@31redorange08]

@@cassieevans8790 *Was* a thing? Still is, I'd say.

[@cassieevans8790]

​@@31redorange08 I spend all day in support forums, from my perspective, it's mostly React, Vue and static site generators that the kids are using nowadays. It's very rare that I see any jQuery. Obviously there's a huge difference between what's trendy and what's being used in the trenches. Wordpress is apparently around 43% of all websites after all. But it's not a unique opinion that jQuery's heyday is over.

[@31redorange08]

@@cassieevans8790 I very much agree! For pre-React projects, it's not that unlikely to meet jQuery. But all the fancy projects? Very unlikely.

[@okandperson]

Love that his remote is a Nintendo switch joycon

[@MelanieSumner]

Love the energy here! Thanks for the useful content, I’m always learning new ways to explain things from these videos. 👍

[@freevotube]

2:55 I'm sure you mean specicifically!

[@kissu_io]

Hehe, never saw that one in a codebase yet. 👌🏻 I guess this can also be quite harmful if it's watching too much things or placed poorly. Thanks for that one! 💪🏻

[@VarunGupta3009]

Humph. This could've easily been an email or a Chat ping.

[@CreedWylder]

Jake's bangs are 🔥

[@powerpiglet]

If the reason to not use DOMContentLoaded is that it will wait for the analytics.js script to load first because that script is tagged with "defer", why is the solution not to just switch that analytics script from "defer" to "async"? Then you could continue to use DOMContentLoaded with no speed penalty.

[@jakearchibald]

Right, DOMContentLoaded leaves you open to unexpected queueing. One solution is to police the queue so you never end up feeling the negative effects of it. Or, don't put yourself on that queue. I prefer the latter approach.

[@powerpiglet]

@@jakearchibald Thank you for clarifying.

[@electroluxv2]

Love your videos Jake

[@cassieevans8790]

muuutaaaationnsssss 🧟‍♀

[@lllIIlllI]

Why not just use a normal script in the body after the needed elements for the animation? The only negative is that its parsing will block the html parsing. Also I'm not sure if the html custom component is any different.

[@boiimcfacto2364]

Hmm. This episode could've been 30 seconds if you'd just told me the answer.

[@tanveerhasan2382]

What's the answer

[@sharkinahat]

Answer actually at 4:43, don't listen to the othe comments!

[@luongtd5]

Pretty clever hack with the custom element.

[@aldoperez4735]

the very first slide made me feel like a Dinasour

[@MominRaza]

4:48 Bye Thank you

[@JorgetePanete]

Are there plans to add native support of TS in Chromium?

[@jakearchibald]

No, but there's a somewhat-related standards proposal github.com/tc39/proposal-type-annotations

[@JorgetePanete]

@@jakearchibald Saw that but it isn't good enough if it still requires compiling TS, now that there's Bun (beta) with that support, and a faster (maybe not that better) execution engine, it should be added here too

[@MachineYearning]

Typescript is an awesome language, and I use it for every project where I need JS. However I think it would be a terrible decision to add it to the browser. We're still in the early years of type-safe JS variants, and there's so much to explore still, from better approaches to Typescript, to other competing standards. I've seen too many flavor-of-the month idioms come and go in the browser to have any confidence that we'll be using anything that looks like the current typescript variant in 5-10 years.

[@JorgetePanete]

@@MachineYearning It's a superset of JS, even using just JS with compile-time checks is enough to prevent common errors I despise JS and maybe WASM is what we need in the future

[@JLarky]

1:19 I made exactly the same sound

[@radenmulyadi2589]

Yeah defer, but recommendation said to use inline script

[@TrostCodes]

Okay, I've only just noticed that Jake is using a Nintendo Switch controller. Is that connected to the computer via Bluetooth, or is this presentation a new Switch game?

[@jakearchibald]

It's bluetooth + the gamepad API kzbin.info/www/bejne/pnqseX1jg66sm9U

[@channyeintun6411]

thanks

[@NoiseLeGGa]

Name a horror film where a MO would have been very useful at the beginning, but would have ended the story after 5 minutes. 🙂

[@BenRangel]

1:19 LOL, yes. To this day when I do DOM ready functions my brain still kinda thinks "How did I do the equivalent of jQuery ready again".

[@DaveCollison]

Socks vs Gradient.

[@whatthefunction9140]

Chapters bro

[@Max86421]

Competition is good... 😁

[@LeeSmith-cf1vo]

What if you do this? ...lots of stuff... ...maybe more stuff...

[@jakearchibald]

The plain blocks the parser, so it delays the defer scripts also

[@LeeSmith-cf1vo]

@@jakearchibald which in some cases might be useful... I mean the first defer will get the fetch started (hopefully) but then the 2nd plain script will start executing

[@jakearchibald]

@@LeeSmith-cf1vo and then later it will run again, which doesn't seem ideal

[@LeeSmith-cf1vo]

@@jakearchibald oh it runs twice? Yeah not good!

[@LeeSmith-cf1vo]

@@jakearchibald oh it runs twice? Yeah not good!

[@carlos.arenas]

4:47 this is how engineering rooms sometimes look like. The TL;DR members; then "the adults can talk"

[@ntgdpl]

Well, JS preload considered harmful as well

[@jakearchibald]

Why?

[@ntgdpl]

why ffs youtube deletes my answer every time, wtf

[@jakearchibald]

@@ntgdpl hmm, does it contain a link? I've had a frustrating experience with the spam bots when comments contain links

[@dyhcdjvddhh421]

You are muted! And we are observing.

[@Surefire99]

If only switching to defer was that easy. The fact that it doesn't work on inline script tags is just one annoyance.

[@rmarkette]

I agree. You still have to use DOMContentLoaded if your script is inline. if it is a small script (like less than 1k), it seems silly to trade that performance of avoiding another http request just to use defer.

[@MarcelRobitaille]

Or just don't load a tracking script

[@IceMetalPunk]

As mentioned, sometimes it's a CDN that adds it to your page, and you have no control over it. Other times, it's an analytics script (different from tracking) that you actually want for analysis.

[@MarcelRobitaille]

@@IceMetalPunk Fair enough for the CDN. I would consider a different CDN in that case. Not just for page loading time, but also because I want to control everything I'm shipping. I disagree. Analytics and tracking may be different ideologically, but we have seen time and time again that even "anonamised" analytics can be used to build a profile on someone. "that you actually want for analysis." I do not. I disagree with that business model. I have never put any analytics into any of my software.

[@IceMetalPunk]

@@MarcelRobitaille By "you", I meant "whoever is creating the app," not you specifically. There are legitimate uses for analytics, not just tracking. Just because it *can* be used maliciously doesn't mean it's inherently malicious (see: nuclear power vs bombs). No one is saying you personally should be using analytics, but other people should be allowed to do so if they choose.

[@MarcelRobitaille]

@@IceMetalPunk I am generally pro-privacy and anti-analytics. Even if there are good intentions, I read about big data leaks of millions of user's personal information about every week. Still, I agree with you that people should be free to add analytics to their software. And I am free to try to limit my use of that software.

[@ToadyEN]

This episode could have just been 30 seconds if you’d told me the answer

[@samhanna7382]

jake is soon going to have a bowl cut

[@kursatnacar27]

heyy

[@0LoneTech]

Well that's Microsoft in a nutshell for you. Refusing to fix things because they imagine someone might rely on it being wrong, even if it makes the original purpose of the feature inaccessible. It's how their specification for e.g. docx includes a bunch of formatting features that say "do this or that wrong, the way we did it in the 80s". And they didn't put *how* they did it wrong in the spec, for fear of not accurately reproducing their mistakes.

[@dailymeow3283]

IE was dead long time ago 🗿

[@ahmadsalehinnayeem]

sa here

16:20 facepalm

[@boheem3451]

No one says parzer. Except Jake.

[@developerfriendly]

why does every tech talk have to be funny

[@jakearchibald]

It doesn't, but I'm glad you found this one funny.

[@koffworld7857]

First comment 😊💯

[@chad_levy]

Complaining about video length is a valid criticism. You chose the least ideal way of addressing it by insulting your audience. You could have simply said something to the effect of “Here’s what you do. Ok, here’s why.”

[@IceMetalPunk]

So... your ideal way of addressing a problem is to deal with it but never acknowledge that there was a problem?

[@0LoneTech]

Knowing why may be necessary to understand if the solution presented is applicable to your case. And that sort of thing is indeed in here; different variants of what you might want to wait for, and how you avoid waiting when it is not necessary. Going "just use defer" is one step above "concatenate all your scripts and put them inline". It ensures you don't use parallelism.

[@chad_levy]

@@jakearchibald3926 The insulting part was around 4:50: “bye, now the adults can talk.” And it’s not so much that I was offended, rather I respect and appreciate your work and videos like this. It just felt unnecessarily dismissive and rude. That’s all.

[@jakearchibald]

@@chad_levy like I said, some folks have been actively angry about the extra detail in these videos. I'm addressing them. If you're not that guy, then I'm not addressing you.

[@jevvir]

@@jakearchibald I'm 100% behind you! There are tons of 10 sec quick tip shorts out there. I don't need that. What i like, is discussions and reasoning and how there are rarely one solution that fits all. You don't give people quick answers and expect them to trust you blindly. You give choices and pros and cons for each choice and it falls on to the viewer to make his own conclusions and decisions. Thank you for that! And also, I'd prefer if you wouldn't give out the answer in advance, i like to guess, which way the video could progress. You may include timestamp to the answer for the impatient ones :)

[@SameAsAnyOtherStranger]

I'm not looking for cutesy chit chat when I have my time to learn tech hat on.

[@permanent.tourist]

Then may I suggest you look elsewhere?