Hacker News new | ask | show | jobs
by mike_hearn 3312 days ago
From a quick look at the sample code and a scrub through the video, it sounds a lot like JavaFX, especially when combined with the Kotlin TornadoFX extensions.

Relatively recent build of a custom widget toolkit? Check.

GPU accelerated 60fps compositing, render and animation layer? Check.

IntelliJ as the IDE? Certainly. Although JFX is perfectly usable from any Java IDE?

Cross platform including across iOS and Android? Check. (except JFX also does Mac/Win/Linux).

Fairly standard layout and box packing model. Check.

Material design? Via a third party company called Gluon, check.

Functional reactive design? Check.

Async/await? Yes, Kotlin has coroutines that integrate with JavaFX.

Hot reload? Actually yes, JVM+TornadoFX has some support for this, although it's not as slick as what Flutter can do ... the view you're working on will be sometimes be thrown out and rebuilt. But if you change your CSS or the behaviour of e.g. event handlers, then you can do hot reload.

There are some differences I see. Dart focuses more on AOT compilation. Another is immutable widgets in Flutter. That one I'm not convinced about at all.

> You can respond to events, like user interaction, by telling the framework to replace a widget in the hierarchy with another widget. The framework then compares the new and old widgets and efficiently updates the user interface.

No explanation for this odd design is provided. I suppose they believe it is self-evidently superior, but that seems like a lot of overhead for very little to me. After all, GUI is pretty much THE standard definition of a big pile of mutable state, and trying to pretend its not by just generating more garbage than a normal GCd toolkit would seems a little strange.

2 comments

Flutter has stateful widgets too, and they can be arbitrarily nested with stateless widgets.

Stateless widgets are useful for static boilerplate that only changes when moving to a different screen, or when swapping out an entire subview. Supporting arbitrary mutations is extra coding that's unnecessary when it's not going to change anyway. Why implement it when you don't have to?

Note that even with entirely stateful widgets, if the whole layout changes, the whole subtree generally to be thrown out which also creates garbage.

>> You can respond to events, like user interaction, by telling the framework to replace a widget in the hierarchy with another widget. The framework then compares the new and old widgets and efficiently updates the user interface.

>No explanation for this odd design is provided.

I suspect that's to support how they provided both an iOS and Material design look and feel. For example, there isn't a single button widget with different styling. There's a CupertinoButton and a RaisedButton.