[striking]

Finally.

I'm hoping that a native UI toolkit that can be used via FFI from nearly any language might take a chunk out of the Web-as-application-delivery-platform mindset.

I don't blame anyone for making non-native apps with Electron and HTML5, because it's so difficult to make them work on every platform. But here's to hoping someone finally got it right, and that native applications can take back some ground.

Death to the battery-eaters and memory-fillers. Let the OS do the heavy lifting.

[karim]

Well, plenty of people tried this approach (off the top of my head, wxWidgets, Tk (the TCL framework, still powering Python, Perl and Ruby GUIs), FLTK). Unfortunately, all those frameworks fail for the same reason: they're all 90% there but fall short on the small details.

Still, let's hope that libui does great --- it's already quite a feat to have the basic window controls working the same on three different platforms.

[ArkyBeagle]

I've used Tk many, many times as a foundation of a temporary strawman interface while the real UI experts ... do whatever it is they do. I've also used it for custom instrumentation GUIs.

That 90% constitutes a lingua franca.

Not knocking the nice UI/UX folks - they work their corner, I work mine, and it's nice to have a technology to bridge schedules. My observation is that that 10% consumes as much as 1000% of the schedule at times :)

[Arnt]

The first 90% are easy, the next 90% wear you out, and the final 90% are what makes a good product...

In my experience, the story of using a layered UI like this is that for a short while you use it, then customers start asking for features it cannot deliver and you start writing platform-specific code, then after a while the portable code is a minority. At some point there's a meeting in which someone points out that a particular platform is 90% of the value and wouldn't it be better to make do with just that 90%? Are these other platforms really worth the effort?

[ArkyBeagle]

ObDisclosure: I'm in the embedded/middleware space.

I dunno. My peers don't write UI much at all; I do these things as force multipliers for my own nefarious purposes.

None of it gets "published" in a formally supported way, so I don't have any accountability for 'em. They're intentionally ugly but not dissonantly so. The design is "look, but don't touch." I mainly use them to anticipate integration errors and do something useful to aid in diagnosis of those. The theme here is "it ain't me, babe" or "holy cow, thanks for finding that" - determination on that axis.

But I also put adequate instrumentation in to exploit in the first place. Seems to be a lost art.

To me, the perfect user interface is no user interface at all - maybe a "push to start" button - a physical button. Second best is command line/scripting, third is the sort of thing I write.

In the embedded space, you might get a perception that this is cheating. I just smile.

[register]

This is not the same approach. Wxwidget is C++ which makes binding to other languages cumbersome. The same applies also to TK which is binded trough an embedded TCL interpreter.

[sdx23]

Also TK doesn't offer native looks. Wx tries, though I'm not sure how good taking into account all platforms.

[networked]

Since version 8.5 Tk ships with themed widgets that by default try to look native on Windows and OS X by leveraging the respective platforms' native GUI toolkits for drawing.

For the details see https://tcl.wiki/14796.

[creshal]

Wx tries, but IMO fails to varying degrees to feel "right". WxGTK in Linux is okay-ish (everyone expects shitty UX from GTK programs anyway); WxMSW is an eye-sore. I haven't dared using Wx under OSX yet.

[mwcampbell]

What makes wxMSW an eyesore? Is it anymore of an eyesore than plain Win32?

[vram22]

Can you elaborate on your points? including this one:

>WxMSW is an eye-sore

[Arnt]

FWIW when Trolltech started there were about a dozen ads in each issue of Dr. Dobbs Journal for libraries like this one.

What's old is eventually new again.

[mhd]

The OS probably won't do the heavy lifting for a text editor. Native text controls/widgets are sufficient for simple tasks (like this textarea I'm using right now), but for anything more complicated, editor authors usually have to implement their own stuff. And that quickly gets really complicated... (still not as bad as a full-blown HTML renderer/layout engine/scripting system -- usually).

[atilaneves]

Having a C API for easy FFI doesn't imply a C implementation

[pcwalton]

I actually think that CSS is better for drawing with modern GPUs than native UI frameworks are. CSS is declarative, which enables global optimizations--very important on GPUs, where state changes are expensive and overdraw hurts. By contrast, native UI frameworks were designed for slow CPU rendering in the '90s via legacy APIs like GDI.

[skrebbel]

I believe you, but still my layman's observation is that the average cocoa/win32 ui feels much snappier than the average web app. I have no proof but I'm pretty sure most people here would back me up.

If it should be faster with CSS, why isn't it? In fact, I develop a web app. What am I doing wrong?

[pcwalton]

Because browsers are not currently architected to make good use of modern hardware.

[wander_homer]

Maybe because the GPUs aren't used efficiently with the current technology. E.g. Webrenderer for Servo was designed to make great use of GPUs right from the beginning and the first results are really impressive.