I really like where the author went with this. Everytime I read something like this though I can't help but think how we as developers really need a better low level, UI framework for cross platform applications. What the author has done here is a cool idea, but ultimately this still feels flawed, and like it's a workaround to the difficulties of writing a cross platform UI. Everytime I read something like this I can't help but think about how great a low level, cross platform C (or C ABI) library would be (think something like libuv but for UIs). Such a library would abstract away the OS specific system calls of the UI while still providing the ability to easily do things like:
* Create a window
* Draw to the screen
* Declaratively (i.e. html like) add UI widgets to a scene
* Apply CSS like styling (like QML, JavaFX, or XAML)
* Use native file dialogs, menus, notifications, etc
* Statically link as a single dependency
I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. It needs to provide common UI elements like buttons, textboxes, divs, grid layouts, etc, but judging by the popularity of electron - I don't think those necessarily need to use native elements.
Qt is close to this, but it feels heavyweight and in my opinion its biggest flaw is that it's difficult to link to an application and setup a development environment for. Tk is kind of like this, but way too limited. JavaFX is a really good example, and would be perfect if it wasn't Java only (same with WPF but it's C# only). Right now the closest attempt to something like this that I know of is https://github.com/andlabs/libui
I think libui could even be a starting point for such a library, but the library I'm thinking of would need some type of declarative UI support (i.e. html like, maybe even support for a subset of html), built in support for styling, and less of a focus on using native widgets. I really wish somebody would build something like this.
I don't think cross-platform UI toolkits should exist, period. Your cross platform code should live underneath the UI layer, and you should write a custom UI for each platform you're bringing your logic to.
Mac apps should look and feel like mac apps, windows apps should look and feel like windows apps, etc.
Trying to abstract away all these platform differences either nets you a lowest common denominator that doesn't feel at home on any platform, or is so complicated to develop for that you end up doing more work in the end (and still isn't as good as writing native UI's for each platform.)
I hear this preached all the time but I honestly don't believe it.
Few third-party applications I use on my Windows computer have a native (or native-looking) UI. Blender, Photoshop, text editors/IDEs, DAWs, video editing software, even web browsers... The only real exception is the file dialog and the window frames.
If they went to match the native UI they would dilute their brand at best and lose usability at worst.
One thing I can do in almost every Windows application is press Alt, or Alt+F, and use the arrow keys to navigate the menus. This has been broken forever in Electron's menu. It's my biggest complaint, even above RAM usage now that I have enough RAM. I guess the Electron devs can take that as a compliment if they want to, but it still gives me a "damn you Electron" moment every few days.
I think it's the sum of those little inconsistencies that bug people about cross-platform apps. On the other hand, people now spend so much time in the browser that a browser-based desktop application can probably feel more natural than a native UI if done right.
There is a base assumption not stated here: that the platform's UI is superior.
Mostly I'd agree. And there are undeniable benefits to supporting what other apps support, which is typically biased towards the platform's stuff.
It's not at all inherent though (TV controls are frequently utter garbage, for example). And the various dimensions of "better" don't always optimize for what the user or dev wants.
Here's the tired counter-argument: I'd rather have an app with a slightly awkward ui for my os, than no app at all. The advantage of these cross platform toolkits (and our bane), is that it makes it significantly easier to make build for other platforms.
> Here's the tired counter-argument: I'd rather have an app with a slightly awkward ui for my os, than no app at all.
I agree. However, I also think that this has an undesirable effect of discouraging a platform-specific app from being created, especially in niche markets.
I think it's great that so many apps are available for mac or linux that wouldn't otherwise be available. Electron provides a baseline that simply is much more difficult with platform specific code, or other cross platform applications. It's not all in the box, and far from perfect. But the fact is, I get to use VS Code, Teams, Spotify (I know not electron specifically, but similar enough) and a handful of other apps everywhere I run.
For the most part I stick to cross platform apps, if that means a "lesser" electron based app, so be it. And most of them look far better than other cross platform and even native options a lot of the time.
It sounds like your main concern is preserving the native look and feel of the OS.
I understand the argument, but I don't really understand the reasoning behind it. This is probably me being naive, but (assuming any performance problems are solved) the only reasoning I see to prefer native OS widgets would be to preserve compatibility with adaptive technologies (i.e. screen readers, OS keyboard shortcuts, high scale displays, etc), and to allow for automation of the UI.
Maintaining compatibility with adaptive technologies and allowing for automation both seem like good arguments to me. I think it would be challenging to solve those problems, but I think it could be done. Html already has mechanisms to deal with this, so I think another tool kit could take a similar approach.
Preserving the native look and feel however, doesn't seem nearly as important to me. I usually customize the look and feel of most desktop applications anyway. For example, changing the color scheme of my terminal, text editor, and IDE. I would hate it if I was forced to use the OS defaults. For example, on osx it's not possible to customize the look and feel of the iterm window, where as with hyper (an electron based terminal emulator) it is possible, and I find that I strongly prefer the later's UI (despite the electron performance issues). Even chrome allows me the ability to customize its UI. Of all the desktop applications I regularly use, there's very few these days that exclusively use the native OS widgets - at the moment evernote is the only one that actually comes to mind.
With some exceptions, users seem to manage pretty well on the web where every website already implements a different style of UI. For simple widgets like windows, buttons, textboxes, checkboxes, etc minor differences in style just don't seem like an issue to me. I think users will be able to visually identify a button even if it looks slightly different, and the advantage of allowing customization feels like a worthwhile tradeoff. For more complex UIs (like 3d renders, music editors, video editors, or games) most seem to already implement customized UI elements anyway.
What you're suggesting actually feels like a step backwards to me, so I'm genuinely interested to understand why you would want to maintain the same look and feel between applications? How do you currently customize the look and feel of your own environment?
> With some exceptions, users seem to manage pretty well on the web where every website already implements a different style of UI.
That's not necessarily true. It's easy on a site like GitHub, where they actually have a UX team and user studies to guide their decisions, but stuff like the Intel HD Graphics Panel would be better if they had just used stock WPF.
For many small or hobbyist projects it is not feasible to implement and test multiple UIs. If you have the resources and want a polished smooth experience then implement the UI layer natively.
That said we're not quite there with code sharing of non UI code between web, desktop, and mobile platforms. It's a niche that Kotlin is trying to fill but time will tell if it succeeds.
Yes, if you want to do it professionally and keep up with the developments of a platform you will you have an ongoing cost for a whole product team for each of your target platforms. That additional cost ($500k-$1m per year per team) is very rarely worth the slight upside in usability, and there are probably many potential products that the team could work on that are more beneficial to the company.
Well, I don't see the value in having multiple UI platforms in the first place. So I would rather have one very good UI toolkit for all platforms than having a lot of pros and cons for all the native toolkits.
I think the most common place to find people with your opinion is in mobile app development. And I in my opinion there are two major reasons here at work:
1. Apple is very good at building UIs
2. Mobile devices are comparable weak in processing power, while their use-cases mostly always require an instant & animated result.
So on the one hand iOS users expect the same quality when you build a custom UI and that is hard to match when you start with a UI project. The second reason might be the cause why web-based UI are kinda hard to build for mobile apps. I mean I heard a lot more mobile developers complain about web-app performance than desktop app developers. But maybe that is just because of the different rendering engines.
> you should write a custom UI for each platform you're bringing your logic to
The question isn't of "bringing" your logic to a platform, though. The question is how people who you don't care enough to provide first-party support for, will run your application.
Consider a situation where someone codes native apps for Windows and macOS, but also provides an electron app as source. Who is that app for? Everyone who is using any other platform.
Also consider the "native-ized" apps that exist to wrap web-apps that never created a native app at all. For example, there are numerous Electron wrappers for the Facebook Messenger web-app created by third parties who just wanted to be able to use Facebook Messenger on their PCs as an "app" rather than a webpage.
This doesn't work, though, and we can use Qt and wxwidgets as the reasons why.
Qt has tried a lot of different ways to render GUIs. Traditional qwidget applications use, depending on the widget object, either native platform specific controls that you try to uniformly mutate despite the stylistic differences, psuedo-themes Qt writes for non-standard elements or things that aren't universal and thus you need a facade for where they try to impersonate the native toolkit (this is why so many Qt programs on Windows "feel wrong"), and user-styled controls that don't even attempt to be native but you can mix those freely with the base widgets that emulate the native look and feel. This is how VLC can have its volume slider look the same everywhere.
Then in Qt4 and much more comprehensively in Qt5 they moved to QML, which completely drops the idea of trying to use native window systems and renders the entire UI with 3d acceleration. They also, at first, made no attempt to even provide common toolkit elements - you got basic drawing primitives and the ability to query get a color pallette that you are told by Qt should be the "native" colors.
Turns out not a lot of people took off with that offering so Qt developed QtQuickControls1 - which was a giant mess of depending on qwidgets to map native widget styling into the OpenGL scenegraph they had. It actually did somewhat work, but only insofar as you got buttons that looked native - go try resizing these Controls 1 windows and you discover a lot of incongruency, especially on less practiced platforms like Android, especially where faux-native widgets and GL components mixed.
QtQuickControls2 I feel is an accurate representation of what all GUI development has to be - if you want native look and feel you do need to do some manual management to get it, making your own themes and having logic to change the design to accomodate the target platform. But it also is meant to make good looking software by using the style guides of platforms rather than the lower level actual widgets - the original release has Material and Universal from Google and Microsoft respectively. They don't try to look native, but they try to preserve the stylistic guidelines of the host platforms. They later added a few other options - a "desktop-like" theme, one that you can easily restyle with generic images, and a default that is super plain.
Wxwidgets presents the other extreme. It tried super hard to never implement a widget itself - it was always meant to be a facade over native toolkits. In other to accomplish that they had to sacrifice ergonomics and introduce means to distinguish the platform native widgets that don't map cleanly across platforms. You never get a perfectly universal cross platform UI this way, but you also don't benefit from native toolkit workflows because you are trying to abstract something that isn't a 1 to 1 mapping.
There is one more aspect to all this - native toolkits generally blow chunks. And that precludes how Windows has at least three actively maintained "first class" GUI toolkits now. All first party toolkits today are derived either from bitmap or raster graphics, mangled over years or decades to support new paradigms that they weren't meant to, and to this day have errant behavior abound and little to no consistency due to their backwards commitments.
That would not have been a problem if we were all still operating on computers without GPUs with displays from 1995, but the evolution of hardware keeps pushing on our desktops to take advantage of the resources available - in particular, GPU acceleration. 2d acceleration is completely dead. If the world made sense and legacy could be eschewed for reason every desktop would be from the ground up built on 3d acceleration. I haven't checked in a while but I believe it wasn't until Windows 8 that Microsoft dropped the non-accelerated bitmap Windows desktop for 2d acceleration. KDE on Linux went through a huge churning to migrate their desktop to 3d acceleration and that still only applies to their newer tech - anything QML based - while the bulk of KDE applications are stuck being unaccelerated qwidgets programs. Gnome is in the same boat, and never made the leap to a 3d UI paradigm across the board that they should have made when GTK3 broke everything.
Because mixing these two worlds is just an exercise in suffering, but every UI design on every platform either has to wage the war or just succumb to using the broken old bitmap style with hacks to try to make DPI scaling work.
Not all the blame should fall on UI designers though - this is a structural problem. Before Vulkan we had no seriously universal and working acceleration API. You could not rely on OpenGL a decade ago much less now - just look at Godot, whom released their 3.0 with OpenGL ES 3 and is now forced to adopt an ES2 renderer since so many ES3 implementations on both desktops and mobile are broken. There was simply no universal API to ground the foundations of a "next gen" 3d toolkit in, which is why Qt supports a myriad of backends to QML including an unaccelerated one they were forced to implement because so many edge cases broke the renderer.
Call it the 14 + 1 standards problem, but whoever writes a declarative toolkit built on Vulkan that can be like QML except without all the attached baggage (theres a reason the Rust QML crate has been dead for over a year) would be my choice any day. Its just a hard engineering problem, not just because Vulkan is hard, but because providing simplicity to start without constraining possibility and expandability is an even harder design problem.
Maybe the answer will come from game engines? The overlap gets more and more blatant every day - I've been having a lot of fun in Godot and I ask myself why not just do general GUI development in here. Its accelerated, cross platform, and the scripting is a joy. It just lacks API coverage for comprehensive support of what apps expect since its only meant to make games.
There is a point that is always missed about Electron - UI.
By using HTML, CSS & JS you have an extremely rich toolkit to create UI with constant improvements from browser vendors and standards bodies.
If a designer can create a pattern library in sketch then chances are it can be implemented using web technologies.
This is a much bigger and more active open platform when contrasted to the capabilities of a particular framework and community.
Theres another topic around whether you should detour from the OS UI look and feel. But most designers and product owners worth their salt are conscious of keeping known UX patterns and least surprise.
> I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language.
----
Is well know the problem of try to do a cross-platform GUIs. But in the other end, the necessity to do that have increased with the arrival of mobile and the emergence of OSX as a viable target for commercial apps.
Is kind of ironic that is easier to port a full 3d-game but a “simple” business app is a huge undertaking :)
The key, IMHO, is decouple some tasks (kind of separate “back-end” UI from “front-end” UI).
We can do “partial/almost” cross-platform UI, if we think that some stuff can actually cross cleanly:
- Layout (the big one, IMHO) with something like https://yogalayout.com7. This one was my main block before.
- A well defined way to separate the back from the front UIs. The ELM architecture is a good contender (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) (called Update-Model-View, similar to react + redux but simpler and easier to call servers/async)
A big chunk of the logic is totally cross-platform and “only” need to adapt the render of controls. This way of working allow to work with pure objects for the model and the view without actually commit to exactly what is the view UI. Instead, is delegated to the “update” side. It can totally be just in-memory, testeable object.
Dispatching, events and similar stuff, that is not visual. This need a bridge but I don’t think will be complicated.
Then finally, the rest can be fully native:
- Controls
- Drawing
- Animations
- Call to native libs
This mean that we build components instead of a class hierarchy and is possible to swap what is a “control”, like, from HTML to iOS Views without moving the rest of the logic.
The big question is what to use for coding this. I’m using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with elements.
Wish to have a coding partner to do this :slight_smile:
There’s a fast-growing interest to create something like this in the Rust community. An unofficial working group led by a Mozilla employee is being formed:
In fact, there are many downsides performance wise when you think about electron:
- it is as slow as any other web rendering engine
- it uses as much memory as any other browser
- you have huge binaries
The key benefit of electron is that you can easily build cross-platform apps which run on every notable platform. Many of the general weaknesses of electron can be eliminated by building a Progressive Web App, but that doesn't solve the performance challenges that come with building a web app.
Performance wise web apps are very slow when compared to C/C++/Rust/Go. E.g. for a C program, a single millisecond itself is a long time. For web-apps you struggle to get everything in a 16ms window to not break your 60fps experience.
But the point is that while web apps are in fact much slower, they can be fast enough. And if you have a technology that is very platform independent and you can built good experiences with it, then you probably find some nice use-cases.
>The key benefit of electron is that you can easily build cross-platform apps which run on every notable platform.
I've been a bit confused about the draw of this feature. I understand that there are a lot of JavaScript developers out there, and things like Electron allow them to use their JavaScript knowledge to make applications on many platforms. But there are now a large number of GUI libraries (GUI being a typical obstacle for cross-platform support) that can target all these platforms (and sometimes more) as well. GTK+, Qt, and WxWidgets name a few. And they have bindings across many languages! Of course, to make something that's completely custom-looking using these libraries may be more of a hassle than an html/css document.
Maybe Electron's popularity _is_ primarily driven simply by the high numbers of JavaScript programmers out there.
I guess it's like you pointed out: if you can get it to be fast _enough_, it's acceptable. Kind of similar to interpreted vs compiled languages.
Practically all libraries you mentioned have heir quirks and don't have the native feel, even though they pretend to. Electron apps don't pretend anything, the GUI elements are different but consistent.
But apart from that, you're right: the main reason for Electron's popularity is the fact that increasingly more programmers know JS quite well whereas desktop libraries seem less and less relevant each year, which makes me very sad.
The problem with Qt, GTK, etc. is that you can't use them on websites[1]. Meanwhile you can build most applications as websites, which don't require any installation and are available everywhere and instantly.
I am a Linux desktop user myself, so I have some sympathy for Qt, GTK and software distribution via package managers. Nevertheless, as a developer I like the web better, as that is a platform which allows me to easily distribute my applications to anybody on any platform within seconds.
Performance on the other hand is a topic by itself. The problem I see with web applications here, is that it is much easier to create a bad performing program with web technology than with compiled languages and toolkits. But that is something you can learn and if you create some performance critical software, easy distribution might not be your top priority.
[1]: I mean I have seen GTK rendered on a html canvas some years ago, but as far as I know nobody actually uses that kind of tech.
For that matter, I remember seeing some Qt thing for targeting websites too. But I agree with your points. Lately I've had to write UIs that actually need decent performance (client-side custom rendering and data processing requirements), so my preferences are biased.
In terms of language support, I've seen bindings for the more popular ones on all major languages and even some more minor ones. There's probably better comparisons out there; this one doesn't have Electron at all (since Electron is more of an environment/VM than a GUI-only toolkit).
Often running in a VM bubble has it's own features/benefits though. For programmer benefits, I can't think of a better example than Smalltalk VMs. But I digress...
At first 16ms sounds little ridiculous. Given how we know the display, and our Hardware input devices ( Keyboard or Mouse ) already took away a few ms already.
But then when we say 16ms is a single frame in 60fps experience. All of a sudden this doesn't sound a lot. I mean I am expecting VR to be in 120 or 240fps range.
There are already monitors that can go as high as 144hz (and some are higher) and I've been eyeing some for a quite a while. Hearing about 16ms being the target just makes me disappointed.
(It may be the right target for 99.9% of their users currently and so a sound decision to make, but I can't help but think in the future they might struggle with the decision. Note: 99.99+% of people probably literally do not care, but I do.)
Anecdote: I love my 144hz monitor for gaming. I can tell when the underlying settings have changed it back to 60, and it annoys me greatly. Highly recommended.
I guess the question is, what are you willing to give up to hit 120 or 240 fps? Most games that I'm aware of won't probably won't hit 120 fps today even if run on the most powerful hardware at the lowest graphics settings. Even if you take games from a decade ago on today's best hardware, you probably won't see 240 fps.
That's a pretty big exaggeration. Taken from the first GPU review I looked at, a GTX 1070 Ti can run DOOM (the new one) at ultra settings at 170 FPS. [1] Sure that's a bit faster than an average gamer's card, and DOOM is better optimized than many games. But the most powerful hardware running a decade old game at low settings will easily get several hundred FPS. (It's hard to find benchmarks of this, though, so I settled for a recent game at Max quality).
The counterexample is games which were designed for fixed 30fps which fall apart at higher framerates, but those are generally limited to Bethesda games and Japanese console ports.
I know the Counter-Strike: Global Offence community always goes for extremely high FPS. I found this without much effort [1] where they discuss how to raise the fps cap from only 300. It's a game from 2012.
For more background on product development about Finda, there are notes on my personal website here: https://kevinlynagh.com/datatron/
I started this as a UI research project to try and replace OS X Finder with a keyboard-only UI. A strong inspiration was the Helm Emacs package.
My initial prototype was in ClojureScript/Electron, and I was exploring far more features like inline preview, and a command/argument (verb/noun?) builder system.
However, after showing my prototype to a few friends, they were all much more interested in the fast search and window switching capabilities, so I decided to cut scope, focus the project on those features, and get something out the door.
This is my first Rust project, and I've been thrilled with the language and that community in terms of great libraries, documentation, and their willingness to help beginners like myself.
p.s. Sorry I'm late to the party, I pushed this blog post online immediately before going to sleep for the night =P
Just wanted to say "hi" and that this is a great read! If you are interested, there is a Neon slack where some of us hang out. For example, you might be interested in neon-serde which could clean-up some of the argument parsing and match logic.
I think it’s cool that people are playing around with this sort of thing.
The truth is, though, I don’t understand why this architecture is attractive in this case. This is essentially a thin front-end UI on top of a fast cross-platform backend. That’s a great structure - but why not make the UI native for each platform?
Calling into a Rust backend from Swift, or from whatever UI framework you use on Linux or Windows, is going to be just as easy as with Neon. At the moment, you are including vast amounts of code and using a large amount of memory to display a very small amount of text on-screen. It seems very inefficient for such an otherwise elegant application!
Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X.
I don't think Electron a good match for this project, which while fast during use, probably has horrendous startup times and memory usage. But I can certainly understand the sentiment pushing developers into Electron and driving them to avoid multiple native applications like the plague. I have developed and deployed custom Eclipse environments that supported Windows and Linux, with a mix of Java and C/C++. It costed me years out of my life.
But a project like this specifically seems to have most of the secret sauce implemented in a cross-platform library. That seems to be to be a great application structure and candidate for native UI implementation. It increases the development effort from n+m to 3n+m, where n is hopefully much smaller than m.
> Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X.
No, it won't. Building any non-trivial UI in HTML takes orders of magnitude more effort and time than building it in a UI toolkit that was actually designed to build user interfaces in.
I can put together a full HTML/CSS/JS UI for a screen in hours where it will take me days to do it on Android or iOS alone, ignoring the fact that I'd have to make sure it's responsive on all those platforms anyway (because tablets), then still build it for windows, linux, mac, and sometimes a web version anyway.
You are the second person to say this, what are you doing that's faster?
I'm talking from start-to-finish creating the UI, wiring into business-logic, handling UI state, making it fully responsive, etc...
I've used WPF, QT, some old java swing stuff, and the Android studio layout editor, and none of them are a fraction as fast and capable as a well setup react web application (which to be fair, took a good chunk of time to setup).
Sure, because the browser will go out of its way to render something sensible out of any tag soup thrown at it, as opposed to throwing an exception like native frameworks do.
If you are including the wiring of the UI into the application in that time I'm impressed, however you still will need to do another 3 major platforms.
And you'll need to have a designer look them over or design them in the first place for each platform, and write documentation for each platform, and test each platform, etc...
In many cases I won't argue that a native app won't be better for the user in many ways, but you can't argue that it's faster to re-create, document, and test your UI 5 different times.
> but why not make the UI native for each platform?
As a developer I prefer web tech for UIs, because it's actually a nice toolkit to work with, and has great tooling.
I can easily debug and live edit the UI with DevTools. OTOH in Xcode's constraint-based layout I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses). On Windows I don't even know which of the many UI frameworks is the least deprecated this year.
> I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses)
I would say that accurately describes my experience with CSS. Any selector has the potential to mess up the entire page.
With NSLayoutConstraints, not only does it match my mental model of how layout ought to work, but I know that in a properly-factored layout, constraints can only mess up their local section.
Globals make debugging tough in any context, and I wouldn't blame the language simply for allowing their use.
> Any selector has the potential to mess up the entire page.
That's true, but the modern web stack has several solutions to this. If you don't mind "CSS-in-JS", I've been using the excellent styled-components [1] library for my company's React app. I believe Vuejs supports scoped styles out of the box [2]. And if you'd prefer to just write plain CSS, CSS modules [3] will mangle the classnames in your CSS files so you don't have to worry about collision.
No. Even in perfectly factored CSS, one bad selector still can mess up the whole page, no? That's why all those nifty tools (mentioned in a sibling comment) exist.
I can understand that, and certainly the web platform is much nicer than it used to be – especially when building for a constrained, known environment like Electron.
Don't discount the native platforms though, which are still very powerful. Constraint-based layout can be frustrating at first, but I've found it's not noticeably more awkward than CSS after a little experience.
Similarly, it's no worse figuring out how to build a native Windows GUI than it is figuring out what CSS or JS framework to use. Just a bit of research :)
The cost of UI development is substantial; as you say "whatever" framework it means that you would need to learn 1) what frameworks are available 2) what paradigms they use 3) what programming languages and tools you need to know to drive them.
As the development is mostly web driven nowadays, HTML/CSS/JavaScript is something that the most developers tend to already know and thus have crossed the first barriers of entry to this kind of development.
> HTML/CSS/JavaScript is something that the most developers tend to already know
If you know both HTML and a proper UI toolkit, you'll see how insane it is to use HTML for anything else than marking up text. It's like launching a space shuttle to go to the supermarket around the corner instead of just walking. The only thing HTML has got going for it is how easy it is to show 'Hello World' on screen. Anything more complicated than that and it becomes a total horror show, especially compared to how easy to use and simple regular UI toolkits are.
Which regular, simple UI toolkits do you recommend to a web developer who wants to learn desktop development? Do you also have a recommendation on which resources/approaches to use to learn those toolkits?
I have no doubt that native UI development for multiple platforms is tricker than a single cross-platform browser-based implementation. But I do think the level of those barriers to entry can be overstated. Building a simple MacOS GUI is not complex; likewise for Windows and say QT for Linux. It requires a little bit of thought and a little bit of research, and more time than a single
implementation. The output is also better by quite a few metrics, and my general feeling is that an application where most of the complexity is hidden away in a cross platform library with a very simple API is the best possible case for this approach.
I can agree with that from the perspective of a single front-end. If I were building multiple front-ends for different platforms, I’m less sure.
I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps. It turned out that native UI toolkits really are very well suited to building native UIs with minimal effort!
> I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps.
As a native developer I have the exact opposite view. Web development is insanely complicated compared to native. It's a complete jungle of flavour-of-the-day frameworks all designed to make web-development somewhat workable (and all of them failing in some ways.
If you're building a website, you have little choice, but if you're actually building a desktop app it's totally insane to use web based UI.
> I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though.
There’s an irony that people who will drop whatever they’re doing to learn this week’s hot crazy brain-bending quasi-DSL JavaScript framework think that learning Swift is too hard and don’t want to have to learn something new.
Frankly you have no clue about web development if you think they are learning every "this week’s hot crazy brain-bending quasi-DSL JavaScript framework"
It's a valid point, simply because browser UI kits are outdated, memory hogs, and have a ton of legacy cruft.
I've recently been using Windows Forms with C# again and am amazed at the ease of use, if only they had made styling easy this framework would have been a gold standard for years to come. It's even cross platform too thanks to Mono.
> would have been the gold standard for years to come
I've written a lot of webforms and do really like it for "quick and dirty" UI's, but it has a lot of limitations that make it a bad choice for non-trivial apps.
Off the top of my head:
-styling
-resizing (text reflow and re-layout of items is very hard to get right/working)
-screen scaling (non-integer, say 150%)
I also found it requires a ton of boilerplate code to programmatically change the UI.
That said, my favourite part is the first class support for events. Knowing this paradigm made my shift to Qt (which has something similar called signals) much easier.
Windows forms is based on decides old WinApi. There's some support for styling there, e.g. owner drawn items, custom painted controls, but using it correctly is tricky as hell.
WPF is based on Direct3D 9, and is easily stylable. I consider it is the gold standard. But it is Windows only. There are cross platform alternatives, xamarin, avalonia, but I don't have hands on experience with them.
I didn't, but I'm wondering if you maybe misunderstood it – that was specifically about implementing the app in what the author describes as a 'game-like' manner, using an SDL library from Rust.
In contrast, platform-native UI frameworks are absolutely optimised for things like this. There's definitely no difficulty in using hotkeys or windowing functions in Appkit, for example.
I noticed the atom team are trying something similar with an experiment called X-ray https://github.com/atom/xray
It will be nice if this becomes a thing, I think it’s more likely that electron apps become significantly more performant than that everyone starts rewriting their apps in QT, for better or worse.
I've been playing with Flutter recently and their approach may dominate UI toolkits in the future.
They took low level rendering API from Chrome (Skia) and build simple but fast layout engine around that. Already works pretty well on mobile and there are some experiments on desktops:
https://github.com/rxlabz/flutter_desktop_markdown_reader
Rust people could maybe do the same with Webrender from servo.
The downside of custom rendering engines is that they’re rarely as efficient as the standard platform affair. While that’s less impactful on desktop, it can be a killer for batteries on mobile devices and laptops.
That's not true. There's no magic sauce that the platform vector graphics library has: it's a userspace library like any other (well, except for GDI, but nobody wants to use that anymore). It's absolutely possible to improve upon it.
Generally platforms providers optimise graphics highly for their own platform. A generic cross platform library rarely invests similar effort for every platform it can run on. The usually applies more to mobile however - most desktops require even the platform providers implementation to be somewhat generic.
The other part of the inefficiency is more to do with what the cross platform engine is internally guaranteeing vs what the platform providers will guarantee. For example, let’s say skia here always runs at 60fps. Great, and a lovely user experience - but does it then respect low power mode in iOS or Android, or does it just continue at 60fps eating away through battery power because it’s geared to the common case of all platforms?
I’d love this to work, but years of the reality of using cross platform renders has made me quite skeptical of their ultimate benefit to the user. They’re great for developers though - but that’s the wrong way round for convenience usually, I think.
Standard platforms on desktops are decades old and therefore render stuff on CPU. Theoretically, a GPU-centric custom engine can be much more power efficient.
The only downside to Flutter is the immense amount of effort to bootstrap an approach like that. I think it made sense for Google since they have the resources and free engineers to throw at the problem, but for more resource-constrained project I'm not sure it's tenable.
Nevermind the fact that the ongoing maintenance burden is also a thing -- using iOS7 UI elements on iOS9 is probably a non-starter for a large part of the audience.
This looks promising, but Google has a tendency to abandon technologies, so who knows? I've been looking at something like Electron, but more lightweight. I'd like to build a UI around a custom C graphics engine (OpenGL/DirectX/Metal/Vulkan) for something like a level editor. Electron isn't suited well for that.
You can copy some of their solutions. I always did my game UI by manually setting positions and sizes, but it should be easy enough to implement their basic widgets - Padding, Column, Text, Align, etc.
"Google" is actually a key differentiator here, because I think Google is uniquely focused on both design (it's been a long road to get here, but at this point I think Google is second only to Apple in design focus.) and interopability. Apple would _never_ make a cross-platform UI framework. What does this mean? Google's vast resources in design, development, & testing, equaled by very few, are behind this initiative. There's no doubt that is a competitive advantage.
The more interesting question is "Why does Flutter exist?" Google is, after all, a business. What's the ROI? Here's my theory: Google is known to be developing a new operating system from scratch called Fuschia[1]. Many many OSes have died in the crib because there was no app ecosystem for them, and thus the cost of switching to the "new thing" was too high for users. How do you solve this problem? Maybe if you create a cross-platform app development framework that lets developers write for the two incumbents while also ensuring compatibility with your new OS...
I don't care about Google's design or operating systems. I don't want Google designed controls on my operating systems. Just like the Electron stuff doesn't look good on Mac or Windows (or GTK for that matter), likewise Google designed widgets won't look native on Mac, Windows or iOS. If your next thought is "what about the Cupertino widgets," what about them? They will never look or feel fully like the native stuff. So why should we settle for that either?
I'm saying it's the same, and has the same issues as other, less desired frameworks. I was wondering why Flutter gets a free pass on the same issues and why people are so excited about it, since similar frameworks exist for 20+ years.
Flutter is a lot like Electron, but faster. Also, arguably easier to use. They don't have to support all of the backward compability garbage that HTML/js has.
qt, gtk and Xamarin / Mono are also "like" Electron but faster and easier to use. Why is the Google fad somehow more important or impressive than those already proven technologies?
Popularity of Electron proves that they are not easier. Even Microsoft wrote VS Code in it.
I don't care much about Google but they did pretty good job with Flutter:
1. No special designer needed, you do everything in code. That means everyone can use their preferred editor.
2. Hot reload - you change something and it changes in the running app.
3. Headless testing - No need to own iOS/Android device to test iOS/Android UI.
4. Nice tooling - autocompletion, formatting, etc. Everything done via command line, with optional support for IDE.
5. Extensible - very easy to write your own widgets. There is nothing special about provided components.
6. Platform agnostic - "native look" of Qt/GTK is a lie, they still look off. To me it just triggers uncanny valley vibe. Not to mention that they implement native look from 5 years ago or more. And completely useless on mobiles. Flutter looks the same on every platform unless specified otherwise. Way less platform specific bugs.
Electron is popular because web "developers" can't be arsed to learn anything other than JS. It's as simple as that. They live in the lie they tell themselves that JS development is easy, when it really isn't, tooling is disastrous, IDE is nonexistent, apps look bad, etc. They are just happy they manage to run something "desktop".
All those things you mentioned are true of Xamarin.
qt uses actual native controls, so not sure what is a "lie" about it; if something is not behaving correctly, it's a bug, and you open an issue. GTK does look bad and out of place, I agree with that, bug so does Electron. If it's between GTK and Electron, I'll take a proper GTK application.
You should use Flutter for a bit before you strongly opine how it's no different than Xamarin or whatever.
Flutter is different. There's nothing even close to it when it comes to writing mobile apps.
Flutter takes the best ideas about UI toolkits, layouts and has the benefit of really good engineers (most are Chrome/WebKit veterans) working for a really long time to make a really good implementation of those ideas.
Hot reload of code is just one feature that is absolutely unique to Flutter, at least when comparing to alternatives viable today (I'm sure are smalltalk implementation that also allowed that but no-one is using them today).
It's still a beta product so skepticism is warranted but I can see the writing on the wall. 2 years from now it'll be crushing other technologies the way React/Vue is crushing in web space because Flutter is just So Much Better.
What is it about "hot reload" that is so appealing to people? Running an app takes less than a second on Xcode. And .NET had "modify, recompile and continue" in 2005 at the latest. I fail to see the revolution here.
Your nonchalant mention of "Xamarin or whatever" means to me you have little experience with that.
You say that Flutter takes the best ideas of UI toolkits, but then say it's mostly web engine developers. So which one is it? Let me guess, they are using Flex as layout? So hardly the "best ideas". Edit: Yes, flex [0]
On the other hand, I don't need to use it to predict how bad quality apps will turn out to be. Just like Electron and React Native apps are bad, so will Flutter apps be, for the simple facts no native controls are used. (React "Native" is not native at all.) Even the best implementation (which Electron and React Native do not have) would still mean bad apps simply because they are not using native widgets.
You seem to only care about developer experience—which I disagree as well. I only care about user experience. User experience is king and developer experience is complimentary.
And if you're working in a section that takes 10-15 seconds to get to and multiple steps? Each time you rebuild, without hot-reload you've killed your focus.
I did a project in Xamarin Forms. The toolkit kinda worked, but nothing great about it. Amount of bugs was amusing: bugs from Xamarin + bugs from iOS + bugs from Android. Certainly does not fill most of my points. Writing anything custom was pain in the ass, since you needed both Android and iOS knowledge to implement the renderers.
Sure it would be the best to go fully native and hire 3 iOS + 3 Android devs, but who will do this when they can have 95% of the same with 2 flutter devs?
The usual fallacy. What you can do with 2 cross platform developers + 1 iOS + 1 Android, you can achieve with 1 iOS expert, 1 Android expert and one who can do both iOS and Android well enough.
> but who will do this
Anyone who wants quality apps. So basically not most start ups, I guess.
> can have 95% of the same with 2 flutter devs
False. Just like it's false with Electron and React Native. At most you have 75%, and that's the most simplest apps. At least with React Native, you can somewhat easily integrate native components. It's ridiculously hard with Flutter. (For example, see how long it took to integrate with MapKit.)
> qt uses actual native controls, so not sure what is a "lie" about it;
actually, no, it fetches info from the native themes to get the colors, fonts, etc.. right, but all the controls are rendered by Qt. It does a pretty good job at it - enough that even microsoft uses it for some windows apps such as OneDrive (https://forum.qt.io/topic/87898/microsoft-onedrive-sync-uses...)
native_view is just a NSView which is where you have to render your stuff on macOS, whatever the toolkit used. But the actual widget implementation is custom: take for instance QComboBox.
I see a lot of HIToolbox calls, which is what AppKit uses internally to draw. So from that third to last link, it seems like a hybrid solution. Not optimal but still better than Electron or Flutter.
> I see a lot of HIToolbox calls, which is what AppKit uses internally to draw.
sure, but that's not the same as using a NSComboBox directly, and that's not using Apple's layout engine (based on cassowary, wasn't it) either. Not that I think that this is a bad solution : it allows software with a strong identity to have fairly custom UIs that are consistent across platforms.
If the app uses no Javascript UI frameworks, and completely maintains all UI/DOM state in Rust code, it might be possible to significantly reduce memory usage when compared to typical Javascript apps.
Keep in mind that "electron-quick-start" (basically an empty Electron app) uses 40 MiB on Linux, so anything with a slightly complex UI would probably not use less than 50 MiB, regardless of the "backend language".
You can't seriously justify introducing massive library into your code just to display some text, and use a few native calls. If it works for you, that's great, but if anybody needs an example of why the software you use is so terrible these days, even though we had huge leaps in technology, look no further.
If all this app does is display text, it would have been simpler to embed a rich terminal emulator widget and implement the backend as a Rust program with terminal UI
I wonder how this approach will combine/contrast with compiling rust to wasm directly -- I'm under the impression that the benefits would be similar.
I absolutely believe building electron apps is the future -- why would you struggle with the M*N effort of building different UIs when you can get comfortable with a paradigm that you already know that works relatively predictably across OSes and is constantly being improved (HTML+CSS).
Unfortunately, one of the big problems left to get tackled (I think?) is the lack of native system accessiblity features that are more advanced than what the web can/does offer.
So excited to see this idea getting attention -- I really want to work on a cross-platform app with neon + rust in the future, and see if we can finally get past the gripe of memory usage for electron apps so that people can stop bashing them.
Do they have complex widgets like grids and stuff? I have worked with wxWidgets for a while and for anything besides basic fields you had to put in a lot of work and code from scratch. I can definitely see the appeal of Electron and reusing web apps and frameworks.
Makes we wonder if Electron apps really have to suck up that much memory. Could the framework be tuned to use less?
I guess I meant grid as in data grid to show data from a database, not layout. With wxWidgets it got tedious once you needed sorting, filtering or paging.
On the web I have a lot of choice, also in .NET. Not so much in qt or wxwidgets. I have seen some very nice Java desktop apps recently so maybe that's a good choice now despite a not so good reputation.
What do you mean with you don't have much choice with Qt? Its view-model architecture lets you basically use any source of data you like in the backend.
I am talking about UI widgets like grids with sorting, grouping, filtering, resizable headers or diagrams, charts, gauges and other stuff. On the web and in .NET you have dozens of choices that look very good whereas on qt I haven't seen much third party support.
Qt has a built in table widget [1], which although it's very powerful, doesn't come with that many features out of the box. And neither does .NET (or HTML), because what you linked is a 3rd party component which costs a lot of money. Not sure where you could buy something like that for Qt though.
I think this is often the perception - and I understand why, because I shared it for a very long time - but I don’t think it’s true.
Building a simple UI for multiple platforms may be somewhat more time consuming than a single cross-platform Electron implementation. This will scale with the complexity of the UI.
This particular application has about the simplest UI imaginable. Consume some keystrokes, render some rows of text. Implementing this is any native UI platform will not be hard - but it will reduce the memory footprint, rendering time, and application bundle size.
Native UI frameworks are actually really good at rendering simple applications on their platforms. There’s usually plenty of documentation and good development tools. Building an application using one of them is definitely different from web tech - but I don’t think it qualifies as hard. And I reckon it would be useful for more of us to experience as many different platforms as possible - it’s a great way to learn!
The native platforms backed by real money also have lots of official documentation, real GUI builders, high quality debuggers built into their IDE’s and one cardinal way/library to do something. The importance of all this stuff in speeding up things can’t be overstated.
Experience? I would much rather have the freedom, and reliability of a native platform than to deal with HTML’s limitations, poor performance, and having to worry about the „optimal rendering path” that’s basically black magick you have little control over.
HTML breaks in ways you won’t predict. Some things you’ll have to hack together so hard you’ll want to take a shower afterward. And it’s only a matter of time untill that piles up enough to justify using native UI from the start.
How is that a “real repo” and mine aren’t? The article this thread is about is written in Rust for the majority of the app. I linked to three cross-platform UI bindings/libraries for Rust that could’ve fairly quickly provided the same UI that the Electron portion provided. I get it some prefer Electron and that’s ok, but to say that cross-platform coding is inherently difficult otherwise is a bit of a stretch to me.
No you're not. These are cross-platform. Save for a few OS-specific things (not UI related, which would have been a problem with electron ayway), it's just about compiling it on a new OS to get it working.
> 1) I want the option to port Finda to Windows and (I can’t believe I’m saying this) Linux, since beta testers asked if they could buy a version for their respective platforms.
Anyone else reading this: Linux support is required for any tech-related thing. Many times I have sold licenses into a single person using Linux who then has their company come back to buy 10s or 100s of licenses.
> Anyone else reading this: Linux support is required for any tech-related thing.
Which is why pretty much everywhere I've ever worked has run off a combination of Exchange, Office, Sharepoint, Windows file servers, and a plethora of legacy Windows-only crapware.
If you work with nothing but webdevs all day though, I could see how you'd get the impression that Linux support for GUI apps is something anyone cares about.
Just to show how well this works, the attached GIF on that site uses OS X Mavericks, now 5 years old.
I also like how they only considered one real alternative, which is "XCode" (incorrectly capitalized). What about Xamarin / Mono? What about qt? With those, they don't even need to upgrade their outdated OS. Instead, they chose the worst of all worlds, both development and user.
It is written in the article that the author had experiences with electron.
> they chose the worst of all worlds, both development and user.
to me this looks needlessly inflammatory, the whole point of the post is "hey, electron has a bad name for both lags and high memory and CPU usage, but with rust i was able to get its benefits without its common drawbacks". If you think this is so ridiculous i think some more explanations are needed.
I wonder if there is a use-case for a simplified lightweight edition of Electron that uses the system webviews instead of Chromium.
Obviously this would be much less capable, require cross platform testing, and limit node usage. But for a project like this that barely does anything fancy in the front-end, it would solve the size and memory issues.
I've often wondered this. You could write a set of generic webview based apps (say, Windows 10 and MacOS to start) and a small js library that would allow cross platform access to low level apis, even just a few at first like file dialogs. React native is sort of like this.
Author here. Sorry that it's giving you a hard time. Can you say what OS X version you're running or provide any other details so I can try and reproduce/fix?
(You can email me privately at finda@keminglabs.com)
I tested with a dozen folks before releasing and this issue never came up.
Haven't heard from OP, but another person emailed me and the issue is likely because Finda relies on AVX2 CPU instructions for fast search. These instructions were introduced in 2012, so it's likely the OP was running on older hardware.
I'll add CPU detection to a future version of Finda so that it can fallback to slower, non-vectorized instructions.
I though the whole reason people created Electron apps is because they can run on any platform. This one just runs on MacOS only so I can't even download it :/
Exactly same experience. Probably because author (he even mentions it in the post) has outdated OSX and there is probably some difference between versions there.
I think it's wild that the browser has become the UI layer in so many applications... CSS + HTML simply make things more consistent in a way that no other toolkit ever has. On the flip side, it's sad that every app now packages the entire jungle (so to speak).
I know that this is what Adobe Air was supposed to be, and part of me would love to see something akin to Chrome's autoupdate mechanisms for an Air-like platform around Electron's base that could be shared. That doesn't get around performance issues, but would at least mean some reduction.
I think it's a great option to have, but still concerning in some ways. I also think that React-Native will probably grow to be easier to create more native-like cross platform apps over time. Definitely interesting times.
Whenever I find myself wanting to build an app that is electron/chromium/webkit frontend + C++/C#/Rust/Go backend I can never justify it over building a web app + web api instead. If you want to run it locally there is a one line docker command to do it.
Since it's a web app, they could go to my hosted site if they can't install it locally. That wouldn't work for the OPs app but it would work for most. The point being there has to be a better way than frankensteining the browser.
It depends on what you consider "better". I'd much rather install an electron app than mount and run a docker container, and I say that as a developer who uses docker every single day.
OK. Dream time. I'd love to build a cross platform app / ui toolkit with support for pluggable backends. The first two would probably ncurses and electron if I were building it. (I'd do it rust for its excellent Web assembly story and perfeomance.)
I’ve been dabbling with Electron to build a data analysis tool app but have been slightly concerned about speed. I am glad to hear how quick it’s running for you and getting ideas on how I can make my app faster.
Interesting that nobody seems to talk about the software itself and maybe it's alternatives.
I for once welcome the concept of something like Finda and am looking for alternatives for me.
> Finda finds things — windows, browser tabs, code editor buffers, browser history, apps, files, etc.
Finda looks and acts like a normal launcher. The concept isn't new, but fast good launchers are rare. When we look at the Finda-Page (I didn't download the demo since I don't use Mac OS) we can conjecture how it works and there are a few things that bother me.
It seems to always run in the background and listen for inputs.
It's cross platform so it will probably have it's own file indexer.
This all seems to add up to a rather large memory consumption.
Anyway right now I'm still using the dmenu [1] launcher and am looking at many alternatives, most of which haven't been updated in some time.
First the ones that haven't been updated in some time
dmenu2 [2], interrobang [3], and lighthouse [4].
All nice launcher, but here comes my current favourite rofi [5]. Not only is it an active project, but it defines itself as window switcher and launcher (so what finda kinda does). Combined with it's extendable nature it seems to be a solid launcher. Bookmark functionality is for instance given with the buku [6] integration. But I'm still looking for the best solution. Here is the feature list I'm looking for: program launcher, simple calculator (through bc or python), file locator (maybe through locate), bookmark manager (firefox preferably). Other things like quick (online) search, clipboard management or the whole slew of other features provided Finda and panther and whatnot would just be extra. Does anyone of you have a nice lightweight solution?
Author here, and happy that you're interested in the software itself rather than the implementation =)
I'll probably write a detailed post about file indexing, since it's pretty interesting from a technical standpoint.
I looked into spotlight (via `mdfind`) but it was too slow and I wanted to port to Windows/Linux later, so your speculation is correct: Finda has its own file walking and indexing mechanism.
It walks a user-configurable set of directories, but not in the background --- it's actually done every time you open Finda, so you only pay the CPU cost when you are actually using the program.
The index is stored in memory, and size is proportional to the number of files/folders walked.
However, Finda does respect .gitignore files, so you can exclude things you don't want to show up in the search results (or consume memory).
Hey thx for the detailed answer. Thought that it might work like this.
How hard would it be to replace the electron frontend with something else? I was thinking about replacing it with some of my solutions I already use, but with your rust backend.
The other problem is that most electron apps are incredibly big. I do not want to download 150mb single purpose apps.
The memory hog is not the only it's also the battery drain most electron apps suffer from.
If you compare Finda to something like voidtool's Everything it's night and day.
> If you compare Finda to something like voidtool's Everything it's night and day.
On my Mac, Finda appears to launch and run instantly.
The voidtool's site doesn't specify which platform it's for, but it appears to be Windows-only. Two of the downloads are called “portable zip”, but they unzip into folders that contain exe files.
This is indeed a night-and-day difference, and helps illustrate the OP's point.
I don’t understand the size argument. Disk space is super cheap today. Facebook’s Android app is 350MB and not a lot of people really care, on Desktop, 150MB is nothing.
Plus it satisfies the “all libs/dependencies in one app”, which is exactly what macOS’s .app, Linux’s Snaps and AppImage, or more generally all Android/iPhone apps are doing.
I agree with the RAM/power things too, but these issues come from web pages in general, not Electron itself.
Disk space is cheap, but internet access might be limited by monthly data cap or just be slow (think 3G networks). And with every app update user must re-download the same electron runtime.
Also bigger apps takes longer to start and in this particular app case, low startup time should be critical.
A full electron app i am making handles about 10,000+ records in memory along with react. Never seen it go above 150 mb on any system. You must have misread the numbers.
Here on my systems (Ubuntu, Gentoo) electron-quick-start leads to ~90 MB more memory usage and it spawns 4 processes which use 110MB, 74MB, 74MB and 44MB of resident memory. So obviously quite some memory is shared between those and probably other processes on my system, but nevertheless the resulting memory consumption is far above 40 MB.
I used gnome-system-monitor to check memory usage, which doesn't include the memory used by the executable image itself, and which I believe is more than 60 MiB.
Theoretically this memory could be shared by all electron applications running in a single machine. In practice every Electron app bundles its own runtime.
I tested on Mac and my numbers were higher. Even if some memory is shared between parent and child processes, each still has its own isolated VM, a DOM tree and a memory heap. So a lot of that is not shared.
I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. It needs to provide common UI elements like buttons, textboxes, divs, grid layouts, etc, but judging by the popularity of electron - I don't think those necessarily need to use native elements.
Qt is close to this, but it feels heavyweight and in my opinion its biggest flaw is that it's difficult to link to an application and setup a development environment for. Tk is kind of like this, but way too limited. JavaFX is a really good example, and would be perfect if it wasn't Java only (same with WPF but it's C# only). Right now the closest attempt to something like this that I know of is https://github.com/andlabs/libui
I think libui could even be a starting point for such a library, but the library I'm thinking of would need some type of declarative UI support (i.e. html like, maybe even support for a subset of html), built in support for styling, and less of a focus on using native widgets. I really wish somebody would build something like this.