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.
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 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?
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 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.
https://github.com/vurtun/nuklear
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.
Sounds a whole lot like what you’re talking about https://github.com/zserge/webview
https://talk.remobjects.com/t/potential-way-to-do-almost-cro...
---- 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:
https://internals.rust-lang.org/t/thoughts-on-rust-guis/6894...
It's a lightweight HTML and CSS renderer for native desktop apps. Used heavily in the anti-virus industry. Not open-source, unfortunately.
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.
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.
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 :)
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.
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'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: -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.
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.
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.
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[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...
[1] https://9to5google.com/2018/01/23/what-is-google-fuchsia-os/
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.
https://github.com/rust-gnome/gtk
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'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.
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.
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.
https://f-droid.org/en/packages/org.indywidualni.fblite/
1.3 MiB
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.
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.
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 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.
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?
[1] https://github.com/stilvoid/dmenu
[2] https://github.com/muff1nman/dmenu2
[3] https://github.com/TrilbyWhite/interrobang
[4] https://github.com/emgram769/lighthouse
[5] https://github.com/DaveDavenport/rofi
[6] https://github.com/jarun/Buku/
- bl
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.
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
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.
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 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.
Thanks!
