Hacker News new | ask | show | jobs
by danielvaughn 1294 days ago
Oh I should have been more explicit when I said that. I really like the reactive model - the idea that the UI is a function of application state is [chefs kiss]. I love it.

However, the idea that you need a “Center” widget just to position an item to the center of its parent…it just feels like GUI development took a major step backwards. I really can’t grasp why that decision was made. I’m open to having my mind changed but so far I’m like, thanks I hate it.

2 comments

`Center` is a result of Flutter having a coherent philosophy (design).

Specifically, instead of doing random mish-mash of layout (like in every other UI toolkit I know, including HTML), Flutter has a simple layout protocol that defines how a parent lays out it's children.

It's a simple, local protocol. ("local" means that the effect of layout is local to widget doing the layout, unlike in HTML where some layout properties effect more than just immediate children).

`Center` is a simple widget that lays out its child in the center of itself.

Why is it good and coherent design?

What if you need to position child 2/3rds on the X axis of the parent?

In Flutter you write (trivial) `Position23rdX` widget and you're done. An easy way to implement custom layout logic that plugs into a coherently designed layout protocol.

In HTML you can't. You can use layout properties that HTML gives or you're out of luck.

I've also worked (or dabbled) with win32 (no layout at all), WinForms, WPF, Cocoa, Gtk - none of them have anything like that.

I agree "UI = f(state)" rocks. That was the one thing React got right. But they never worked out state management, other than to kick off the Flux monstrosity that Redux ran with, and every other UI I can find.

As for what I call the "Lego model" of UI construction, while definitely off-putting, I think the "why" is prolly "simplicity thru decomposition". So we do a bit more typing but have a dead simple approach to building our UIs.

The nice thing about any Lisp with its macro capabilities is that we can wrap sth like Flutter to produce a library that remains Flutter, but hides the noise.

ClojureDart offers a so-called "widget" macro, and my Matrix library goes a different way, making every constructor such as "scaffold" into a friendlier macro.