Online since 1990 Yes! I started with Gopher. I do modern Web Component Development with technologies supported by **all** WHATWG partners (Apple, Google, Microsoft & Mozilla)
Lastly and regarding the conclusions, it usually doesn't really matter that much which one you choose
With Web Components (eg: <my-component) it does matter because the native connectedCallback fires on the opening tag. Not using async or defer could be a better choice
The topic seems to be quite conplex, so I would tend to choose the most simple and robust approach. Just.... what are the consequences?
Fetching scripts and possibly executing them early could make your app feel more "snappy" and responsive, though in most cases I suppose the differences will be in the range of 200 ms or so, but the more important thing for me: Will it be recognized by the user?
It´s worth to recap what a browser really does behind the scenes. See this great post on logrocket. Building the DOM is only one step, but there are multiple steps to be done, before a page is rendered. So, anything done before first render may delay the FCP, but will lead to a consistent result.
But what happens, if you wait for DOMContentLoaded? Will actions done in the event it still be included in the first render cycle, or will it cause a new one? If the content changes, you will possibly get a layour shift, so the content is rendered and just rerendered with a different layout, which looks not great.
I´m really not sure how to deal with this topic, expecially on large sites.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
A complex topic indeed. I'd analyse each use-case individually as there is no golden rule here, profile your large app so you can see what is blocking you. I've seen companies spending monies in thousands trying to optimise the wrong thing.
@dannyengelman using web components you need to first introduce an unknown tag into the DOM just to tell the browser what it is afterwards.
If you analyse it, it's no different than creating and injecting an HTML tag into the DOM from a script, or adding some feature to a given selected HTMLElement.
By that I mean that you are in control of this "afterwards" just like in any other script; you can also use async/defer and inside your script, wait for the proper event, then define your web component/s, and the result would be the same I assume.
Online since 1990 Yes! I started with Gopher. I do modern Web Component Development with technologies supported by **all** WHATWG partners (Apple, Google, Microsoft & Mozilla)
@dannyengelman using web components you need to first introduce an unknown tag into the DOM just to tell the browser what it is afterwards.
If you analyse it, it's no different than creating and injecting an HTML tag into the DOM from a script, or adding some feature to a given selected HTMLElement.
You are wrong here; you can use customElements.definebefore DOM is parsed.
This can easily be checked with element instanceOf HTMLElement
Its just that 89 out of a 100 developers do not know/do this. They fall into the connectedCallback trap and never investigate WHY their code doesn't work, and whack on async or defer thinking they solved the problem.
So Web Components are totally different from (oldskool) create-DOM-after-DOM-is-parsed scripts.
Define Web Components early (before DOM is parsed) for all GUI stuff.
Define Web Components late for all stuff that can wait (like the oldskool way)
Note: 1. can be two stages, like with icons: define the GUI ASAP, add interactivity later
This can easily be checked with element instanceOf HTMLElement
This just means that the code is available in the DOM. I suppose it will be executed when HTML is parsed which is not much different from executing a script somewhere inmiddle of your HTML code.
Anyway, this could be an advantage as HTML expression is usually paused as long as scripts are executed, but I suppose the differences will be minor.
Online since 1990 Yes! I started with Gopher. I do modern Web Component Development with technologies supported by **all** WHATWG partners (Apple, Google, Microsoft & Mozilla)
Difference is major when GUI Web Components are created with render blocking and inlined <script> in the <head>; then get enhanced to full interactive GUI after DOMContentLoaded
Inline the GUI required CSS as well (I mean bare CSS, not Tailwind) and the first HTML page should be 10 to 15 KB at the most... Eat that Vue,React.
I suppose, Tailwind (or any CSS in JS solution) will give another twist to this story, but this possibly would fill a complete post. Anyway, an interesting story...
Online since 1990 Yes! I started with Gopher. I do modern Web Component Development with technologies supported by **all** WHATWG partners (Apple, Google, Microsoft & Mozilla)
Sorry this was a misunderstanding. Even if you do not use a bulky package like tailwind, any JS that manipulates global CSS might cause strange effects like Layout shifts and unexpected delays. But this would fill another post I suppose.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
With Web Components (eg:
<my-component) it does matter because the nativeconnectedCallbackfires on the opening tag. Not usingasyncordefercould be a better choiceDev.to post: Web Component developers do not connect with the connectedCallback (yet)
The topic seems to be quite conplex, so I would tend to choose the most simple and robust approach. Just.... what are the consequences?
Fetching scripts and possibly executing them early could make your app feel more "snappy" and responsive, though in most cases I suppose the differences will be in the range of 200 ms or so, but the more important thing for me: Will it be recognized by the user?
It´s worth to recap what a browser really does behind the scenes. See this great post on logrocket. Building the DOM is only one step, but there are multiple steps to be done, before a page is rendered. So, anything done before first render may delay the FCP, but will lead to a consistent result.
But what happens, if you wait for
DOMContentLoaded? Will actions done in the event it still be included in the first render cycle, or will it cause a new one? If the content changes, you will possibly get a layour shift, so the content is rendered and just rerendered with a different layout, which looks not great.I´m really not sure how to deal with this topic, expecially on large sites.
A complex topic indeed. I'd analyse each use-case individually as there is no golden rule here, profile your large app so you can see what is blocking you. I've seen companies spending monies in thousands trying to optimise the wrong thing.
@dannyengelman using web components you need to first introduce an unknown tag into the DOM just to tell the browser what it is afterwards.
If you analyse it, it's no different than creating and injecting an HTML tag into the DOM from a script, or adding some feature to a given selected HTMLElement.
By that I mean that you are in control of this "afterwards" just like in any other script; you can also use async/defer and inside your script, wait for the proper event, then define your web component/s, and the result would be the same I assume.
You are wrong here; you can use
customElements.definebefore DOM is parsed.This can easily be checked with
element instanceOf HTMLElementIts just that 89 out of a 100 developers do not know/do this. They fall into the connectedCallback trap and never investigate WHY their code doesn't work, and whack on
asyncordeferthinking they solved the problem.So Web Components are totally different from (oldskool) create-DOM-after-DOM-is-parsed scripts.
Note: 1. can be two stages, like with icons: define the GUI ASAP, add interactivity later
This just means that the code is available in the DOM. I suppose it will be executed when HTML is parsed which is not much different from executing a script somewhere inmiddle of your HTML code.
Anyway, this could be an advantage as HTML expression is usually paused as long as scripts are executed, but I suppose the differences will be minor.
Difference is major when GUI Web Components are created with render blocking and inlined
<script>in the<head>; then get enhanced to full interactive GUI afterDOMContentLoadedInline the GUI required CSS as well (I mean bare CSS, not Tailwind) and the first HTML page should be 10 to 15 KB at the most... Eat that Vue,React.
I suppose, Tailwind (or any CSS in JS solution) will give another twist to this story, but this possibly would fill a complete post. Anyway, an interesting story...
I said not to use Tailwind. That's a 479 Kb Gzipped download.
Do everything (for your primary GUI) native and in one HTML file, then PWA
Sorry this was a misunderstanding. Even if you do not use a bulky package like tailwind, any JS that manipulates global CSS might cause strange effects like Layout shifts and unexpected delays. But this would fill another post I suppose.