The future of plugins and extensions with Hype

Yeah, the reality is that there are definitely times when one would want and wouldn’t want effects to be previewed live. Right now it is both a feature and bug (depending on the effect) that these occur in the scene editor. I can see that a plugin should be able to be notified when it is okay or not okay to render.

Also it might have it’s preview code be removed on exports.

Yup, any plugin system would need to be able to identify and export differently based on the editor vs. export environment.

Here is a quick example but I am not getting all green Div’s in the GUI? (12,7 KB)


BTW I loved the times when we could enable the JSContexts. It would fire up the safari inspect allowing to peak into the WebKit stage used in the Hype GUI.

Interesting, this is a bug.

For the scene editor, we run the head html through a tidy process to ensure that mangled head html code won’t interfere with editing. (Of course valid head html still can in many other ways!). The tidy method we use isn’t smart enough to know about the <script> tag, and so is converting the for loop from:

for (i = 0; i < divs.length; ++i) {


for (i = 0; i &lt; divs.length; ++i) {

This is invalid javascript, and therefore failing.

I thought this could still be done? Regardless, this is how I investigated:

defaults write com.tumult.Hype4 WebKitDeveloperExtras -bool YES

HURRAY! It’s back… :heart:

This works :slight_smile: until it get’s fixed… avoiding the symbol “<”.

		var divs = document.querySelectorAll('div');
		for (i = 0; i != divs.length-1; ++i) {
			console.log (divs[i]);
			divs[i].style.setProperty('background-color', 'green', 'important');



I am not sure what your plans are for the long run, but for the immediate future I’d appreciate some Hype tags like IE had back in the days (and a fixed parser!). This might just be really great…

<!--[if HYPE]>
This is rendered in the Hype GUI but will be stripped in the exports

Other solutions? Ideas? Having extended Symbol Bundles package all this would even be better (including them having a portion running on HypeDocumentLoad).

That may be the best way to do it… I was also looking into media queries with environment variables for CSS-specific cases but it doesn’t look like those are yet supported. For plugins specifically though I think it is fine if things are well defined – these are more of a case for standard CSS/JS that may interfere with a user’s experience but it is ultimately wanted.

1 Like

So I had a good nights sleep on the topic and what do you think about structuring the plugins around callbacks / events like the current event system (Hype‘s Observer Pattern).

So many of the same events would be triggered on an dedicated listener array specific to the IDE (like HypeSceneLoad and many more new and IDE specific etc.). The hypeDocument would contain a reference to a GUI specific API (in the long run with some modifiers maybe even registering custom GUI elements in the side panels or adding stuff to the stage that Hype then „knows“ about) and Element would contain essentially the target and Event as usual.

<!--[if HYPE]>

/* callbacks */
function onSceneSelected (hypeDocument, element, event) {...}
function onTimelineSelected (hypeDocument, element, event) {...}

/* Setup Hype IDE listeners */
if("HYPE_IDE_eventListeners" in window === false) { window.HYPE_IDE_eventListeners = Array();}
window.HYPE_IDE_eventListeners.push({"type":"HypeSceneLoad", "callback": onSceneSelected});
window.HYPE_IDE_eventListeners.push({"type":"HypeTimelineSelected", "callback": onTimelineSelected});


Hope this makes sense! Exciting.

By the way. The conditional tags could potentially also solve 3rd party issues by removing these bits when rendering the head HTML to the IDE WebKit-Instance. Note the negation with the not (!) exclamation !HYPE.

<!--[if !HYPE]>
<script src="https://someserver.tld/1.2.3/weirdLibrary.min.js"></script>

First attempt at a “full” IDE plugin…


Nice, I like this idea; makes sense.

It might be the case that plugins can be loaded/unloaded so there may need to be a bit more bookkeeping or formalization on the functions (say a plugin makes functions with a specific name it wants a callback to).


Not sure what your exactly thinking about? Maybe make an example with dummy code.

On my part I was thinking about any function we could call in the Hype IDE is accesible through an IDE-API much like the one already provided (hypeDocument.COMMAND). We can retrieve it on a document or scene level with an IDE init event callback. And then triggers stuff view with it (like adding Timelines, Elements, Keyframes) in the IDE.

In the other direction Hype emits event callbacks and notifies JS and we can react to things like (attribute changes, elements added, scene switched, timeline switched, keyframes added and fire our code and occasionally modify values or halt default execution with the return of the callback).

Just my limited perspective as I don’t know anything about the setup your running, but I appreciated the ways things are done in the exported portion and how extensible this makes Hype already.

Much appreciated that this is on the table at all!


A structure like:

class MyPlugin {
   function sceneWillChange() {
     // ...

   function sceneDidChange() {
     // ...

   function playheadDidChange(time, timeline) {
     // ...

   function loadInspectorItem(parentContainer) {

   function elementNeedsReload(elm) {
       // ...

Since everything is contained under a specific object, it can more easily be loaded/unloaded.

1 Like

Keeping in mind that a plugin consists of an portion that should be in the export and a portion that takes care of the preview in the editor… I was still under the impression we are talking about the “extended symbol” approach. So loading and unloading comes down to removing or adding that symbol in the library?


are we now talking about a full fledged new entity called “plugin”? If we get a more powerful and dedicated plugin interface then I totally get it. Then the class would also define functions that return specific portions of code (or snippets of HTML, JS and CSS) it wants to run/include in the case of exports or previews in the IDE.

If plugins isn’t just the extended symbol it might even take over some / all of the export logic callbacks currently in Python (and grandfather them). It could be potentially even better then the Python approach as it does allow state to carry over from call to call and is more accessible to all people familiar with JS. Meaning the class instance could potentially hold state across the entire export process.

If plugins is distinct from extended symbols the possibility to run code on DocumentLoad from a symbol level would still be very much appreciated.

Custom parameters / interface in the IDE for either Plugins or extended symbols is already achievable with the little used approach from the exporter scripts …

def document_arguments():
	return ["clickTag"];

def extra_actions():
	return [
		{"label" : "Ad Exit", "function" : "alert", "arguments":[{"label":"Alert", "type": "String"}]},
		{"label" : "Expand", "function" : "console.log", "arguments":[{"label":"1stMessage", "type": "Expression"}, {"label":"2ndMessage", "type": "String"}]}

… so basically we would need that as an interface in the class or/and as some setting in extended symbols. Depending on the final approach.

I thought we were talking about a plugin system, not a symbol that has some associated IDE scripting abilities :slight_smile:.

But yes, there is overlap in some of the requirements of what a next-gen symbol, plugin, and export script require! One doesn’t preclude the other for future plans.


Move here from other thread

Some thoughts (my opinion):

Hype is (still) on the trajectory of a big monolith that offers everything in a very controlled way. It focused only on its own capabilities as seen in the animation engine and the runtime. This constrains gave it its “powers” in world of browser wars and vendor prefixes as it could be the abstraction layer that make features work across devices.

Going forward the “basics” are slowly coming together across the browser sphere and the browser wars are pretty much over. If you would conceive of a Software like Hype today it would be much more generic and try to be an assembly hub for all the technologies emerging as they overwhelm even a big team of developers.

Plugins could solve this as it distributes the load across people implementing stuff and making it compatible and easily accessible. If Hype goes the route of plugins many of the things that already take up space like Matter.js, waypoints, sound support etc. could be plugins. Leaving you with a choice to even replace basic features with another approach provided by a plugin.

Only big problem I see with this is the animation engine is so custom and baked into the runtime (symbol lookup etc.) that it won’t be replaceable and it’s not the intention of Tumult to consider it therefor … this is a problem as many other plugins need a way to changes values over time and would always have an extra dependency on a tweening engine or each plugin will have to come up with its own approach.

1 Like

Thanks for your thoughts!

In many ways, items like waypoints and matter.js are already plugins in that they are conditionally loaded. Yet there’s a certain level of heightened runtime awareness these need. For example, just bridging matter.js and the Hype runtime is nearly ~1600 lines of code, with ~200 of which are highly interleaved into other Hype features such as flexible layout, movement, animation, vector shapes, and so forth. With any plugin API, there’s a balance between simplicity and reservation for 1st party features against expressiveness for 3rd parties. In cases like physics, I don’t even think a basic runtime could consider all the right end points – even call ordering can be highly important. This is just to say that going “full plugin” as a runtime structure can lead to interoperability issues or missed opportunities to combine features.

The flip side is that the Hype app and runtime were both developed knowing that there would always be new CSS properties to integrate, so adding property support is very easy and ripe for being part of a plugin structure (along with a few additional hooks).