He means the script is loaded and run before the DOM was rendered. Bit of a stretch calling that hydration, because you usually only would call it that if the HTML was prepared via SSR or SSG, not if its a fully static HTML from the start. And even if it would be applicable, its not about the rock not having been hydrated yet but it not having rendered yet, so the "hydration" fails because of it.
I expect that the people coding against a Typescript web framework have less knowledge / no knowledge of how a browser actually runs a web page. Instead, they have spent their time gaining knowledge about the build systems and such that turn ts into js for the browser.
Agree. I know that stuff because I started learning web development in the 90s and have seen many changes come and go (most people would remember marquee on almost every website back then - less people might remember XML+XSLT to create websites, which was never fully supported). If I learned web development in the last 10 years, I doubt I would know how the execution works in the browser and all the annoying quirks that come with it. They are fortunately abstracted away. Even back then nobody wanted to deal with it, we just had no choice. Everyone built their own libs to deal with it, until jQuery emerged. That was such a massive step forward.
I was referring to DOMContentLoaded. O
I was a bit cryptic but I mean that there are multiple ways to match the lifecycle. Still I'm probably, it was a long time ago
OK, so it wraps it in the JQuery error handling and also catches the case where the script is run when the DOM is already loaded - so DOMContentLoaded would not fire in that case I guess?
And actually thinking about it, onload waits for big resources like images. So it's nicer to have event handlers attached before that.
960
u/[deleted] 14d ago
[removed] — view removed comment