Hype and Flash (shortcomings and benefits)

I thought I would share some of my observations since using Hype (compared to the Flash).
Flash had to die for many reasons and one of them was also it’s core benefits. I’d provided a unifying plugin and therefore environment to run in. I loved it as I could just forget about browser wars and platform specific implementation details back in the end-90’ties. Hype also provides a runtime with workarounds that offer a more coherent experience. This I do love about it.

But why did Flash have to die and what is the risk for Hype. Both systems invented their own little world and API and drive the user into a little parallel world/cave. Hype has a more open nature then Flash had as it runs on to of the regular web technologies and can potentially interact with the rest of the content living on the page. But still … Hype (and so was Flash) are the innovative solutions for shortcomings of a slow evolving and complicated stack of web technologies …although these technologies start to include many of the features that these tools deliver into the browser stack itself.

We are certainly not there and the tech still can profit from a interface to “click it together” rather then having to hand code it but the abstraction from the bare browser can potential become thiner and thiner over time.

I love the way Hype solves problems for me but am very aware of the shortcoming that a single system introduces. Since more then a decade I am not putting my eggs all in one basket anymore. I’d wish the little parallel world these systems (like Hype and Flash) introduce would be more native and educational to the actual functions of the browser technologies. Although I must hand it to Hype that at least it is opener to and based on the web stack and the single point of failure a product like that present would be less dramatic … It was pretty devastating last time waking up on that sinking Actionscript boat with that burning Flash-Banner on it’s sail after captain Adobe drove straight into an iceberg a couple of years ago.

“Darling, where have all the Flash developers gone?”.


It’s true. Limited skills only takes you part of the way… My take on it is that easy software should offer the entry to the world beyond the surface of easy. I love the way of Apple simplicity but sometimes I hate this approach for limiting the user and keeping him in a sandbox of “easy”. Like a parent that doesn’t trust in the abilities of it’s child (yet). I used MS FrontPage in the end 90’ties to teach some HTML to colleagues that only did design. It was great because the Software had this two tabs “design view” / “code view”. You could actually switch from one to another and see what your visual edits changed in code and vice versa. Okay, HTML and the web was much simpler and easier then (and we loved the hell out of these tables, prior to CSS). Great educational value right there. And even if you never left design view you could work with somebody who did only coded and he could change some stuff and switch it back to design view. Maybe one day you would become curious as a designer and look under the “hood”. I am just saying and my point is that software should open the possibility to learn beyond it’s own constrains it applies to get something complex simple. Hype does this but also not. It offers the simple way of manipulating design and animation with it’s own animation and layout engine solving lot’s of the frustration of doing these visual things in plain HTML (and for that I love it). On the other hand this layout and Animationsystem is limited to Hype and gives you a hard time to use other ones or learn things like CSS-Grid, CSS-Animation and CSS-Flexbox inside of Hype. Another thing I totally understand is the limitations on the API as this introduces a contract as Jonathan would say and limits the future development of Hype. This is why Hype extension project started in a sense. One thing that is changing is that as far as am following this correctly Hype is exposing some of the goodness under the hood so we don’t need to load already included capabilities twice. I mean exposing a connection to Matter.js (if it’s loaded). I would also like to see the same with Paper.js if possible, though. I am grateful that Hype exists and am certain that many pure designers already benefit from learning concepts like ID/Class, listeners/behaviour and Javascript trough the visual GUI!


Paper.js is a really cool project. It is a bit different than Matter.js though - Hype v4 doesn’t use any of Paper.js in the export whereas Matter.js is only used in the export, so we could change some things around to fully expose it for v4. Paper.js is only presently used for the pencil tool smoothing, though our usage may increase in the future.