Here’s a condensed version on how Hype animation loading works:
- The entry point to the Hype animation is the
*_hype_generated_script.js file. This contains the data for all your animations and elements, along with a little bit of code to help manage loading the runtime. This gets loaded first.
- This looks to see if the Hype runtime (say
HYPE-584.thin.min.js) has been loaded yet.
- The runtime is object-oriented, so it looks to see if the HYPE object exists, and if so, it makes a new instance for the specific animation and kicks off the animation.
- If it has not been loaded, then it makes a list of animations to start later, and puts itself on that list. Then it sets a variable saying that it is in progress with being loaded. Finally, it initiates the download.
- If another animation comes along (driven by
*_hype_generated_script.js) it will see that the download is in progress, and will simply add itself onto the list of animations to start later.
- When the runtime is done being downloaded and parsed, it will then create a new HYPE instance for each of the animations on the start later list, and then starts them. (Any animations that come in later are step #3)
So in this regard, there is an amount of “loading” that has to be done with the runtime for each animation - mainly setting up state and kicking off animations. But it does not need to do the heaviest steps of a network download and parsing the script.
There’s a little bit of extra magic that happens if you have two identical animations on the same page. When the second one is loaded, Hype will notice that there is a conflict in the names and ids. Hype will change the ids for the second animation so it will continue to work in most cases. (this is part of the reason for the
document.getElementById() - we can keep track of what was intended and return the correct element, even if the Hype runtime changed it under-the-hood).