Nice article, I always love these sorts of overviews. I think some of it’s terminology usage is questionable or incorrect, but that’s understandable. Modern JS engines are so complicated at a practical level it’s hard to split the difference between giving the reader a practical understanding of how they actually work without drowning in details vs an abstract understanding that is good enough to be useful. I’ve tried myself but it’s not an easy balance to find.
Contrasting the call stack against heap memory is a little odd, it either conflates stack-based memory allocation with the call stack in general (which is a higher level abstraction that exists as a stack data structure), or lightly encourages the reader to do so.
In that same line, a lot of these overviews of execution pipeline can be inaccurate in detail when various optimizations are in play. Assumptions about engine architecture can also go out the window when talking about more exotic engines as well - it’s not a given that certain things will always be heap-allocated or stack-allocated, etc.
Nice article, I always love these sorts of overviews. I think some of it’s terminology usage is questionable or incorrect, but that’s understandable. Modern JS engines are so complicated at a practical level it’s hard to split the difference between giving the reader a practical understanding of how they actually work without drowning in details vs an abstract understanding that is good enough to be useful. I’ve tried myself but it’s not an easy balance to find.
Contrasting the call stack against heap memory is a little odd, it either conflates stack-based memory allocation with the call stack in general (which is a higher level abstraction that exists as a stack data structure), or lightly encourages the reader to do so.
In that same line, a lot of these overviews of execution pipeline can be inaccurate in detail when various optimizations are in play. Assumptions about engine architecture can also go out the window when talking about more exotic engines as well - it’s not a given that certain things will always be heap-allocated or stack-allocated, etc.