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.)
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.
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.
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.
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.
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.
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?
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.
See also: https://www.nngroup.com/articles/flat-design/
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.
so what happens when microsoft itself uses Qt for official windows apps? :p https://forum.qt.io/topic/87898/microsoft-onedrive-sync-uses...
I can’t really blame them.
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.
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.
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.
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.
Check out (my) https://github.com/mherrmann/fbs. It's for PyQt but I think does get around the obstacle you mention.
Sounds a whole lot like what you’re talking about https://github.com/zserge/webview
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:
- 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:
It's a lightweight HTML and CSS renderer for native desktop apps. Used heavily in the anti-virus industry. Not open-source, unfortunately.
There’s a typical window app, game ui, something that looks like unreal engines visual programming.
Seems like a flexible system
Haven’t actually tried to use it though. That’s where it will win or lose, IMO
Edit: and just got to end of the README. Bindings available for rust, python, go, lua, java and more. Gonna have to kick the tires on this one.
I thought the criticism was more about its memory usage, not that it wasn’t fast.
- 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.
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.
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.
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.
: 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.
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.
(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.)
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.
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
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!
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.
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.
Hours for a single screen ? Exactly what I'm talking about. The fact you think that's quick is worrying.
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).
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.
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 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.
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  library for my company's React app. I believe Vuejs supports scoped styles out of the box . And if you'd prefer to just write plain CSS, CSS modules  will mangle the classnames in your CSS files so you don't have to worry about collision.
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 :)
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.
I would argue the exact opposite is true for anything more complicated than 'hello world'
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!
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'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.
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:
-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.
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.
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.
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.
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.
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.
Theoretically this memory could be shared by all electron applications running in a single machine. In practice every Electron app bundles its own runtime.
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:
Rust people could maybe do the same with Webrender from servo.
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.
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.
Today they would probably invest their time in React-Native or something.
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. 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 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.
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.
Looks the same = looks bad on all platforms.
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.
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 
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.
You could live-reload Qt code for years (https://doc.qt.io/QtQmlLive/index.html)
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.)
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...)
On Mac, they use native widgets:
It is painted here:
This calls at some point QStyle::drawControl which ends up here on mac : https://github.com/qt/qt/blob/0a2f2382541424726168804be2c90b...
this ends up here in this big switch :
which leads us here, in the drawComboBox function where mostly everything is done by hand:
and also here: tadam, actually it just uses the "windows" (actually fairly generic and themeable) style for drawing :
See also this qt blog: http://blog.qt.io/blog/2017/02/06/native-look-feel/
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.
Interesting, but the major complaint about electron that usually pops in HN is about memory consumption.
Is it that avoided in this case?
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".
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.
I'm compiling Rust to WASM on another project, so I can address this question.
I haven't studied relative perf, so can't make any claims there.
But for this application your guess is correct: It's iterop.
It's easier to go with Rust via Neon rather than WASM because Finda needs to:
+ Walk the filesystem for file results
+ Call OS X CoreGraphics APIs to list windows
+ Run a websocket server to collect results from browsers and VSCode
All of this requires leaving the browser sandbox, and so can't be done in WASM.
Makes we wonder if Electron apps really have to suck up that much memory. Could the framework be tuned to use less?
Yes, they all have complex widgets like grids and stuff. Grids being layout managers, not widgets.
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.
It's super cheap when you have to get something done quickly. The functionality you get is insane.
I have looked around for qt but there wasn't much. And what I found didn't look very good.
Yes. What makes you think otherwise?
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!
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.
> And it’s only a matter of time untill that piles up enough to justify using native UI from the start.
That's a little hyperbolic and counter to my experience.
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.
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.
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.
The state of development in 2018 is ridiculous.
> 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.
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.
Doesn't work at all for me. Running finda shows the instruction screen. Try to use it by typing, and the window goes completely white.
I can use ctrl-\ to bring the white window up and down, but nothing else works.
I had to find the launchd process in Activity Monitor to kill it so I could uninstall.
I tested with a dozen folks before releasing and this issue never came up.
I'll add CPU detection to a future version of Finda so that it can fallback to slower, non-vectorized instructions.
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.
I try the same idea with Android/iOS. In iOS, all fly, but man... android is super-slow.
I can't believe it myself, so I downloaded several demos of html-based apps and the results hold.
I totally will kill for a webview-like control on android that I could reliable use and be almost 80% as fast as on iOS..
Now I implementing the UI on both, and seriously is harder than I expected... Never imagine the Apis were that bad...
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.
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  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 , interrobang , and lighthouse .
All nice launcher, but here comes my current favourite rofi . 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  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?
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).
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.