Yup. Anything layout-related could be costly to read, and could force a layout to occur if modified since the last read (even within the same synchronous javascript code). Most things are not deferred until the next layout pass, which is one of the reasons virtual DOMs got popular: it batches changes for you.
Properties are to allow dynamic actions for what appear to be simple variable accesses. They don't magically make those as fast as accessing a variable; they are a syntactic convenience to allow assignment and using the value implicitly rather than having to invoke a function/method. They could have cached the value and kept a dirty flag, but then everything that affected the value would have to be sure to mark it as dirty or result in subtle bugs.
The biggest performance bomb you can have in your code is a loop that does something like
for (...) {
el.style.height = `${something}px`;
whatever.value = el.style.offsetHeight;
}
This forces the browser to recalculate layout multiple times in a single frame. Separating layout changing code from measurement code will help a lot here (most frameworks out there have solved this so we don't have to be too concerned about it though).
Yup. Anything layout-related could be costly to read, and could force a layout to occur if modified since the last read (even within the same synchronous javascript code). Most things are not deferred until the next layout pass, which is one of the reasons virtual DOMs got popular: it batches changes for you.
Properties are to allow dynamic actions for what appear to be simple variable accesses. They don't magically make those as fast as accessing a variable; they are a syntactic convenience to allow assignment and using the value implicitly rather than having to invoke a function/method. They could have cached the value and kept a dirty flag, but then everything that affected the value would have to be sure to mark it as dirty or result in subtle bugs.
The biggest performance bomb you can have in your code is a loop that does something like
This forces the browser to recalculate layout multiple times in a single frame. Separating layout changing code from measurement code will help a lot here (most frameworks out there have solved this so we don't have to be too concerned about it though).Afaik let in JavaScript also has a sizable penalty too, if not quite as bad as const. Var on and on.
Let and const have a "temporal dead zone" before initialisation that distinguishes them from var, which is just undefined:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Runtime TDZ checks can be performance issues:
https://vincentrolfs.dev/blog/ts-var