3 ms·

This sounds a lot like Tumult's Hype: http://tumult.com/hype http://tumult.com/hype One of the primary complaints about Hype is that its HTML / CSS / JS outpu

This sounds a lot like Tumult's Hype: http://tumult.com/hype http://tumult.com/hype One of the primary complaints about Hype is that its HTML / CSS / JS output isn't very clean. I wonder if Google's tool produces better output. EDIT: Looks like not: https://news.ycombinator.com/item?id=6470640 https://news.ycombinator.com/item?id=6470640

tumultco 13y ago
Tumult Hype's exports are essentially 3 lines of HTML so it is easy to embed in other documents and output mostly takes the form of JSON animation data and a JavaScript runtime file. It isn't meant to be hand-edited or even read, since we minify heavily to keep file sizes extremely small. While everything has its tradeoffs, we went with this approach because: - Our app has a lot of animation and interactivity capabilities not meaningfully expressed through anything but JavaScript. For example, we don't use CSS3 Animations nor transitions because they aren't powerful enough (pausing, synchronization, etc.). - We have better control over how we express the DOM to the browser. There's plenty of browser bugs or incompatibilities which sometimes require us to on-the-fly change the DOM structure or which properties we are using. - The user could easily bork the output so it could not be read back in - No tool will ever produce output that will appease everyone :) We provide lots of hooks in and outside of the runtime for your own JavaScript and HTML so you can still customize quite a bit. So it isn't that our output isn't very clean (in fact I'm quite proud of the runtime and how we've been able to add features without increasing bloat); it is that edits are meant to happen from the app itself.
- wakkalakka 13y ago
  Thank you for the thoughtful reply. I do in fact agree it is probably unreasonable for people to expect automatic code generation to be hand-editable without disturbing the machine-editable workflow, but it is something that comes up a lot. I see that Google's tool also seems to produce rather inscrutable output (see my edit to my original post). This does sound like one of those really hard problems where is pretty much impossible to balance the needs of the machine-modifiability with human-readability. Thanks again for the reply!
  - tumultco 13y ago
    Yes, we ultimately felt it was a fool's errand, especially because we're a startup with limited resources so we need to focus on the right problems. When we launched version 1.0 long ago it seemed like this wasn't necessary for a "minimum viable product" considering we're targeting graphic designers who might not have as much coding experience anyways. There hasn't been much that's swayed us otherwise -- I think it was the right call.

tumultco 13y ago

Tumult Hype's exports are essentially 3 lines of HTML so it is easy to embed in other documents and output mostly takes the form of JSON animation data and a JavaScript runtime file. It isn't meant to be hand-edited or even read, since we minify heavily to keep file sizes extremely small. While everything has its tradeoffs, we went with this approach because: - Our app has a lot of animation and interactivity capabilities not meaningfully expressed through anything but JavaScript. For example, we don't use CSS3 Animations nor transitions because they aren't powerful enough (pausing, synchronization, etc.). - We have better control over how we express the DOM to the browser. There's plenty of browser bugs or incompatibilities which sometimes require us to on-the-fly change the DOM structure or which properties we are using. - The user could easily bork the output so it could not be read back in - No tool will ever produce output that will appease everyone :) We provide lots of hooks in and outside of the runtime for your own JavaScript and HTML so you can still customize quite a bit. So it isn't that our output isn't very clean (in fact I'm quite proud of the runtime and how we've been able to add features without increasing bloat); it is that edits are meant to happen from the app itself.

wakkalakka 13y ago
Thank you for the thoughtful reply. I do in fact agree it is probably unreasonable for people to expect automatic code generation to be hand-editable without disturbing the machine-editable workflow, but it is something that comes up a lot. I see that Google's tool also seems to produce rather inscrutable output (see my edit to my original post). This does sound like one of those really hard problems where is pretty much impossible to balance the needs of the machine-modifiability with human-readability. Thanks again for the reply!
- tumultco 13y ago
  Yes, we ultimately felt it was a fool's errand, especially because we're a startup with limited resources so we need to focus on the right problems. When we launched version 1.0 long ago it seemed like this wasn't necessary for a "minimum viable product" considering we're targeting graphic designers who might not have as much coding experience anyways. There hasn't been much that's swayed us otherwise -- I think it was the right call.