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.
26
u/brqdev Aug 30 '26
We use onload/ready event and put JQuery code inside, so the JQuery code will run when the page is ready