| I'm not with Haiku but I'm working on something similar, so I'll chip in with my 2 cents here. To get good performance out of interactive web animations, you need the code that handles input to be in a really tight loop with the value that's eventually painted to the screen. The CSS Animations API really destroyed interactive design on the web for a long time. The reason is that they were fully declarative and had very few hooks for interacting with JS code, it's difficult or sometimes impossible to do things like chain/interrupt/restart them. Developers could work around that with hacks like using the style property on a div to override the animation classes when being interacted with, and then relying on the animations defined in classes for everything else. I've tried to write code like this, it's brittle across platforms and very hard to maintain. In addition, the global flat document structure of HTML makes it very hard to ensure that other code doesn't interfere with yours. My point is, you can't write a good animations editor for the old web because it just wasn't possible to do them well enough using the old API's. Newer API's (CSS Variables, Web Animations, CSS Flex Box) and better component abstractions (React / Web Components) make it a lot easier to do something like Haiku. My tool just takes an intermediate JSON structure and generates React or Web components. The animations for React are handled by React Natives Animated library, and the Web Animations API for Web Components. Flexbox + CSS Transforms are leaned on for keeping the structure or the generated components consistent. Generating performant animations on the web really isn't that hard anymore. The really hard part is defining a common set of API boundaries to make the generated components reusable and composable. Doing this is complicated because of the lack of proper module loader in JS, its dynamic types don't help either. From the video it looks like Haiku is using a library from AirBnB called Lottie to handle the animations. Then they turn around and wrap that in a React component + others forthcoming. I wish I'd known about Lottie before starting my project, it probably would have saved time. I'm not sure that Haiku can pull of component re-usability with Lottie though, depending on how much of a black box it is, good luck to them on that front. |
> From the video it looks like Haiku is using a library from AirBnB called Lottie to handle the animations. Then they turn around and wrap that in a React component + others forthcoming.
For the Web, Haiku Core is our renderer. We don't use lottie-web; we use Lottie only to export Haiku Core for rendering on iOS and Android.
Haiku Core uses "the fastest parts" of SVG + CSS + JavaScript to render its animations. Nothing magical here, it's just using web standards, though it was important for us to build around SVG+DOM instead of canvas so that you can still use the Web for what it's best at: rendering documents.
Haiku Core is a component format explicitly defined for reusability — and hackability. Haiku components for the Web aren't 'generated' or 'exported'; the design source file is the code source file. And due to the way that Haiku handles state (strictly internally) and data flow (strictly message-passing,) they work in any codebase, as polite and predictable guests.
EDIT: P.S. tuchsen, I'd love to chat with you some more. Can you email me zack@haiku.ai ?