Hype Runtime

The runtime is the abstraction layer enabling the projects you create in the Hype desktop application to run across different browsers. Even though Hype renders its output using HTML5, it introduces a set of new concepts like Scenes, Layouts, Animations and Shapes in the application. These concepts require unique functions to be rendered, hence they need to be managed by a JavaScript-powered runtime. The runtime works as a layer between what the Hype project file wants to accomplish and what the user's browser capability offers, smoothing out vendor specific quirks. In recent years the browser capabilities are on a trend of unification and empowerment. Trends like Progressive Web Apps, CSS Animations and cutting-edge hardware support are on the rise. Keeping track of the latest developments is certainly a fun endeavor I recommend doing, but in production one just wants to open a familiar setting and start doing the job. The Hype runtime, even though sometimes limited, offers exactly this unified experience.

Bundling and caching

The Hype runtime is bundled into every export. Therefore, by default Hype doesn't leverage a central Content Delivery Network. This isn't a bad thing as it makes sure that the exported document JavaScript is delivered with the matching runtime. That said, Hype offers an official CDN since version Hype 4.x and this feature can be enabled under advanced exports. You can also set up and use your own runtime repository.

Avoiding multiple versions of the runtime

One thing to watch out for is the Hype Runtime version. As you deploy multiple Hype documents on a single page, updates might create additional file requests and download weight as meanwhile the runtime version might have changed. The Hype Runtime is loaded based on its version and checks to avoid additional request will therefor fail when comparing version. That leads to twice the load as Hype documents load the appropriate Hype runtime version. Imagine the follow scenario:

• You deployed two Hype documents. Initially, they have the same runtime version as they are created with the same Hype runtime dependency. Hence, after Hype loads the runtime the by request of the first Hype document the second Hype document finds the runtime already in memory (or at least in the process of loading) and doesn't request it again.
• After a half a year you need to update one of the Hype documents and re-deploy it to your web host.
• Now Hype requests two runtimes as they have different version each needed runtime is a separate file request.

The solution would be to export all Hype documents when you update your project or disregard the additional requests and weight this puts on your page load. This "problem" can be disregarded if you only have a single Hype document on your page but gets worse if there are even more than two Hype documents, and they are updated individually over long time periods.

Hype runtime repository files

You can find all the latest minified runtimes in this repository.