Since then, I think many of us have gotten tired of looking at overdesigned sameness that by now we all know will age quickly. Programmers no longer see the sense in chasing a perpetually changing visual standard for no reason other than "BigCo said so". Most importantly though, BigCos in question have fallen out of our good graces, and the "Design Systems" they keep pushing are now regarded as nothing but cynical branding exercises that come at the cost of UX.
It's a pendulum.
As a front-end dev, I'm not entirely sure I agree with that. The DOM has some annoying performance limitations, and I'd love to be able to use something better for rendering. I think what the DOM has shown, is that cross-platform and the ability to easily do custom look and feel are crucial.
Well put!
The original point - that people would get confused from non-platform UI schemes - has been proven kind of moot since most games have their own domain specific UI schemes and people love them anyway.
They really don’t. Have you taken a look at the thriving ecosystem of native, powerful macOS apps that follow platform conventions?
I also think "professional" apps are a special case (which is a totally subjective classification). Even Apple and Microsoft have done their own thing for professional apps since forever. If I'm going to use that app for 8hrs every day, I'm more accepting of learning something new. I'm still more likely going to pick up an app if it follows existing conventions...I already chose my OS because I've learned and like those conventions.
Do you have a more modern example?
I emphatically disagree. There are still jokes (from legitimate annoyance) that the main consoles have different conventions for buttons and button names. It's awkward to navigate menu system with a simple up, down, left, right, accept, cancel when accept/cancel move around system to system. At least on desktop computers Spacebar/Enter and Escape are mostly consistent.
As for in-game control schemes, it's generally coalesced around wasd + mouse and USE. Even with that there are jokes (stemming from legitimate annoyances) about putting down a game for a week because you're older, are a parent, and have other responsibilities, then having trouble picking it back up.
This is a major reason I'm incredibly selective about the games I play and one reason I avoid online play. Sure, I'm one data point, and it may not apply to a majority of the cashflow for gaming, but I see it expressed online quite often.
But the thing about those is that they are 'hidden' and require memoization. There is no on-game HUD that would show legend of all the available actions all the time. If you could have that, then people would be much more comfortable about even the hidden schemes.
There are game UI:s that are mostly mouse operated, and expose the user interaction grammar using the game specific, visual UI narrative. My kids seem fine navigating between those. A great example is Roblox, which has lot of "controller heavy" games where there are custom UI:s for building and configuring lots of things.
There are no guidelines that the authors defer to, but, they organically try to make the UI:s as understandable as possible. Most of the time they copy established conventions anyway, and when they don't either the UI is still understandable or no-one will play the game.
Edit: Also as an example, Aether comes with plenty of shortcuts, or even has proper tabbing and tab highlighting for low-vision users. Electron prevents none of these, in fact the platform it’s based on, the DOM, is one of the most accessible platforms ever made in terms of support. Whether people actually make use of it it is another matter.
Examples would be shortcuts, tabbing through form fields, how a file explorer works and other small things. The file explorer in VSCode for example doesn't really behave like a native one, you have to manually refresh, you can't easily drag and drop and everything just feels a bit off.
Electron is sooo simple. I mean, we've run into some pretty interesting issues like with hardware acceleration and difference in color and font rendering between platforms, but if a guy like me can code, sign and ship a fully functional application, anyone can.
Also, I can really recommend Vue and Quasar for anyone looking at building electron and mobile apps. Really fun!
And I'd even argue that, with the freedom Electron gives you, app developers have started to actually pay attention to their design, rather than just using the standard toolkit and considering it done - so Electron apps often have better UI. I'd take VSCode's UI over Geany's any time, for example.
Yes grey text on a white background can look great on a retina screen, but does it look good across the product range from the last 7 years and all devices, lighting conditions and for people with various disabilities?
I use web apps so often that Electron looks natural
I release a Qt app for mac / windows / linux whenever I want by tagging a git commit and letting it be built by CI services. There is a single code base with almost zero platform-specific code. I really don't think that the technology choice is what matters in this.
I doubt this is entirely true. VSCode is frequently cited as an example of a good, performant Electron application. Its performance is generally acceptable (I use it as my primary text editor), but it absolutely chugs sometimes. Sublime is light-years ahead in terms of performance.
I wonder why they haven't expanded on this with Rust and WASM taking events and returning a canvas buffer. This seems like the best of both worlds. They get the responsiveness and performance of native code for the hard bits while retaining the ease and flexibility of HTML for the rest of the UI.
If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary speed and real multi-thread capabilities.
It definitely can’t compete with true threads for work that needs true threads, but you probably don’t have much work that needs true threads (rather than just workers and channels).
Secondly, in the case of an application, WASM is of little use since (with node and almost any programming language) you have an FFI available. One could simply shell out computationally heavy things to C++ or whatever else. This is what many folks do with their Electron apps already (via node-ffi).
That said, some things I use (like SQLite, gRPC) will probably forever remain a C dependency, so I'm not sure if WASM would help with that.
I liked the site, it's clean and to the point. Just a small nitpick: right under the Demo download button, you say "(Demo does not have Pro features such as team management, access control and others)".
I wouldn't say that - that essentially gives the user a (subconscious) rationale on why she shouldn't download the demo. I would suggest to focus on the positives instead - what the Demo can do. If you can somehow remove limitations, even for 14 days - even better!
I’ll try to find a way of making it less of a showstopper though - might be a better way to tell this.
Cool. With Electron your app will only work on Linux/Windows/MacOS. There are other cross-platform solutions.
It's the same reason any app developer nowadays only supports iOS and Android and not say, KaiOS (honestly, hands up if you've even heard of KaiOS). Don't rag on software teams for making trade-offs based on the resources they have.
It's not just that app devs aren't making non Linux/x86 apps, the problems are that those devs now cannot make non Linux apps. Period. In spite of this lack of portability they're now crowing about how portable and awesome their "cross-platform" app is. All of this to provide the consistently mediocre Electron experience.
Mediocre and working > not existing
To what end? The Electron devs have explicitly stated they will reject patches adding support for other platforms. Node is just as bad (letting trivial patches that would fix compilation on FreeBSD just fester).
I've already looked at the folks trying to port Electron to FreeBSD and honestly the build system on its own is absolutely horrifying. Qt (even Gtk) is far superior in this regard.
If Qt works for you, use it. Electron works for many people. I don't like Electron apps very much either, but I definitely prefer working Electron apps on Linux than just not having that app available in the first place.
So I can run proprietary apps (because that's what these self-professed app devs are talking about mostly)? Not gonna happen.
Just because upstream wouldn't accept it doesn't mean that it can't exist.
No, it just means it's a lot of unnecessary work for a framework that already has an arduous build process. I haven't found that killer Electron app just yet so what that means in practical terms is that VS Code goes bye bye when my MacBook Pro finally dies and I move away from Apple (and likely to OpenBSD) on the desktop.
I definitely prefer working Electron apps on Linux than just not having that app available in the first place.
That's what's known as a false dichotomy. Even if Electron were the only choice, how many of these Electron apps (e.g. Slack, Discord, Signal) would be better off just being used directly from the browser?
Well then you don't want it that bad.
> I haven't found that killer Electron app just yet so what that means in practical terms is that VS Code goes bye bye when my MacBook Pro finally dies and I move away from Apple (and likely to OpenBSD) on the desktop.
You seem to care an awful lot about an issue that doesn't seem to affect you. Why?
> That's what's known as a false dichotomy. Even if Electron were the only choice, how many of these Electron apps (e.g. Slack, Discord, Signal) would be better off just being used directly from the browser?
I've been using Linux off and on for over a decade now. The single biggest thing that has made it possible for me to use it as my daily driver is that I can continue to get work done without resorting to kludgy workarounds like running everything in a browser. Most companies that I've worked for use Slack enough that not being able to Alt+Tab to it would be a dealbreaker. Even if the only feature that Electron brought was a standalone browser that you could alt+tab, it'd still be worth it. Of course, that's not the case -- allowing for better integration with the desktop is also excellent.
Because it does effect me. Electron is promoting a monoculture of apps that don't behave well (resource usage, accessibility, abysmal native integration) and they're not portable to boot. What that means in real terms is that more and more that quality native apps become less common and hacky Electron apps become more common. Unless you're using an unsupported configuration, then Electron just means that people are being encouraged to standardize on the lowest common denominator and ignore you.
VS Code? Definitely not my first choice, but its rust support is still better than IntelliJ (or nearly anything else for that matter). But that's network effects for you.
So choose an Electron supported OS or add OpenBSD support to Electron somehow. If VS Code is important enough to you, then that's a trade-off you have to make.
I don't think I'd agree that Electron is "hacky". I'd certainly say it has shortcomings, but what technology doesn't? Rust certainly does, but you tolerate it because you (presumably) enjoy/use the language for things you care about.
At the end of the day, most users aren't going to give a shit about what technology a thing is built with as long as it works moderately well. Solo developers being able to provide an application to 3 desktop platforms (one of which is historically underserved) with a single codebase is a powerful thing. The same argument applies to cross platform mobile technologies. Flutter, as an example, doesn't support WebOS, but it supports the vast majority of users, so it's gaining traction. Yeah, there are some tradeoffs, but I challenge you to find a technology where no such trade-off exists.
Since you mentioned Qt: Qt's main audience is C++ developers. I have no interest in writing C++. There are Qt bindings for other languages, but good luck finding one that's as well supported as Qt's C++ ecosystem. There are a couple of commercially supported Python options, but then you have packaging woes. Plus, you have to worry about licensing. Or I could use Electron, reuse a lot of the code that I've already written for my web app, sprinkle in some desktop integration, and I'm off to the races.
As an aside, the Rust language server (and most other language servers) works pretty well with Neovim. You can probably get at least the same experience with some work on your part. I assume the same can be said of Emacs, but I don't have the dexterity or number of fingers necessary to use it, so I don't know for sure.
The UniPress Emacs icon used to be a unicorn, because once you hold down all the modifier keys with your finger, you need a horn on your head to press the letter with.
Why? My whole point is that Electron is encouraging developers to not support other platforms. That's not helped by simply using something that the Electron devs have blessed. The absolute last thing I want is Electron to dictate which platforms I can and cannot use.
or add OpenBSD support to Electron somehow.
This too seems like a fools errand as the Electron devs have decided that anything beyond Windows, MacOS, and Linux will not ever have official support.
Since you mentioned Qt: Qt's main audience is C++ developers. I have no interest in writing C++.
Then don't. I'm currently working on a project that's using a rust backend and a Qt/QML front end. If you're more comfortable with JS then QML is an easy leap. The caveat being that you've got to drop down to C++ for some things. The biggest example I've seen is table data sources, but even that is due for vastly improved QML support in the next version of Qt.
Or I could use Electron, reuse a lot of the code that I've already written for my web app, sprinkle in some desktop integration, and I'm off to the races.
Right, and now we're back to "this sounds good to the devs" while the users suffer. In the mobile sphere where this has been common for a longer time, reskinned web sites work extraordinarily poorly. For example: Apple adding native app support to iOS, Facebook dropping their HTML5 based apps, and nearly any other app that's a lightly skinned site (BBC and NPR come to mind). It's not any better on the desktop side as evidenced by the poor accessibility and resource usage of Electron apps.
Low effort cross platform toolkits have never yielded particularly good results. And while I think Qt is still pretty damn clunky on OSX, the solution isn't to run towards a product that exacerbates the problems.
As an aside, the Rust language server (and most other language servers) works pretty well with Neovim. You can probably get at least the same experience with some work on your part. I assume the same can be said of Emacs, but I don't have the dexterity or number of fingers necessary to use it, so I don't know for sure.
Yeah, I've flirted with Emacs for a few decades now but never warmed up to it (and it really is the epitome of a non-native app). Vi (typically vim) I use for some things (even with rust dev), but I'm not about to replace a full blown IDE with it.
Because you expressed a need for vscode. If you need it, figure out how to use it. If you don't need it, it's not a problem, right?
> This too seems like a fools errand as the Electron devs have decided that anything beyond Windows, MacOS, and Linux will not ever have official support.
"official support" are the key words there. If you care about it that much, whip up some patches and maintain them. Or even better, find other OpenBSD users to help you build and maintain them. Just because the electron devs don't want to support it doesn't mean it can't happen.
> Then don't. I'm currently working on a project that's using a rust backend and a Qt/QML front end. If you're more comfortable with JS then QML is an easy leap. The caveat being that you've got to drop down to C++ for some things.
JS but C++ for some things is just as bad as C++ for everything. Qt isn't an option for me any more than Electron is an option for you.
> Right, and now we're back to "this sounds good to the devs" while the users suffer.
Users don't actually suffer that much. You appear to be looking at this through the lens of your own environment -- you might suffer because of Electron, but people don't give two shits what slack is built with as long as it works reliably.
> Low effort cross platform toolkits have never yielded particularly good results.
If your web app is good to begin with, bundling it in Electron doesn't make it worse. You seem to be okay with browser based apps, so I'm not understanding where that disconnect is.
> Vi (typically vim) I use for some things (even with rust dev), but I'm not about to replace a full blown IDE with it.
Whatever works. vim was my daily driver for a long time. Works just fine as an IDE. Neovim is better. YMMV.
Maintain patches that will never be accepted upstream? Thanks, but no thanks. And then what about proprietary apps? Electron is a scourge that's helping perpetuate mediocre user experience and an oligarchy.
Beyond that the Electron build system is a rats' nest. If there were some killer app out there that used Electron I'd probably consider it more seriously. But Electron is a bit like systemd: an exceedingly poor solution but just good enough so that most end users don't complain too loudly.
JS but C++ for some things is just as bad as C++ for everything. Qt isn't an option for me any more than Electron is an option for you.
No, it really isn't. Using JS (ick) for the majority of your app insulates you from most of the big scary C++ bits. There are other options besides Qt and Electron. Using Qt (or pretty much anything else) would also do the opposite of trying to entrench an oligarchy.
Users don't actually suffer that much.
As much as that sounds like a ringing endorsement of Electron, I'd say the steady stream of complaints about apps like Slack are evidence to the contrary.
If your web app is good to begin with, bundling it in Electron doesn't make it worse. You seem to be okay with browser based apps, so I'm not understanding where that disconnect is.
What's acceptable in a browser is not in a desktop app. This is the same reason there's anxiety over Apple's push to bring over the iOS toolkit to desktop macs: context is everything. Expectations are higher for native apps and simply slapping an Electron install on a web app doesn't comes closer to "why even bother with a desktop app" than "hey, desktop apps are a much better experience".
Beyond that a browser can share code that electron apps can't. I don't need or want N installations of Chrome/Chromium (with the resulting overhead and security implications).
Complaining about the decisions made by other people isn’t useful.
Actually I'm primarily using MacOS as a desktop these days. I've happily paid for a variety of apps (e.g. Omnigraffle, Monodraw, Lightroom).
Your responses sound like you’re upset; why? You made your choice.
Beyond the usability issues that constantly dismissed out of hand by developers, Electron is a crass and dishonest attempt at redefining portable and cross-platform to include a very narrow selection of platforms.
This actively increases the effort to get traction with a non-Electron supported platform and encourages bloated. Who's going to compete with Slack if they already offer a (shitty) desktop app?
Folks hold up VS Code (which I do use) as an example of a good Electron app. It's still slower than native IDEs like TextMate or Sublime and it's still not quite right in terms of native look and feel. Why do I use it? Network effects. The rust community seems to have (sadly) standardized on VS Code.
You don’t think the crass and dishonest part is a story that you’re telling yourself? To me, it’s an engineering trade off. There is no need to criticize what others have chosen, and afaict, no evidence to support this hyperbolic questioning of their intentions.
When development is your livelihood, you target the platforms that make money and only the platforms that make money. That pretty much means Windows and maybe Mac. Anything else is throwing money away.
Sure. As a developer I would've used Qt (or Gtk) because even on the platforms that Electron provides, both provide a much higher quality user experience. You may not care about Linux on non-x86 or QNX or BSDs now, but you've ruled out ever caring enough to consider them.
As a user I loathe Electron apps. They're slow, don't respect native mannerisms (e.g. VS Code for ages didn't put titles on windows you minimized), and horrifically bloated. I try not to use free Electron apps (Discord and Slack get used in a browser), and I would never pay for one. So there's that.
The fact that they eventually put it there tells me that it wasn't a fault of Electron in the first place, but fault of the designers/devs. Electron allows you to do all those nice things you love if you want to, so I don't see how it is Electron's and not designers'/devs' fault.
That's not something a native MacOS application dev would ever have to think about. If Electron requires extra work to make your app behave like a normal app that's absolutely a fault with Electron and means that Electron apps will often present poor the user with a experience.
Developers in the 90s often supported 5 or more different platforms. How is it that modern development is so much worse?
That's an awfully bold, if unbelievable, claim given that cross-platform toolkits have existed for a long time.
Besides, Java works fine on BSDs. Why is it that when modern developers reinvent the wheel they so often manage to do it worse than the last time?
I guess, but the amount of people I know that use BSDs are even fewer than the amount that use Linux. Given that Linux is a hard enough sell to support for most apps I doubt that BSD support would be offered even if the framework supports it.
> Besides, Java works fine on BSDs. Why is it that when modern developers reinvent the wheel they so often manage to do it worse than the last time?
Speak for yourself, I would MUCH rather use an Electron app than a Java app. No need to make sure you have a proper JVM installed AND the apps don't look hideous like 99% of the Java apps I've ever used do.
Plus we are talking about regular Java here.
Portable GUI code is harder than portable code without a GUI.
Yes. Or Linux on non-x86 platforms.
Linux The prebuilt ia32 (i686) and x64 (amd64) binaries of Electron are built on Ubuntu 12.04, the armv7l binary is built against ARM v7 with hard-float ABI and NEON for Debian Wheezy.
Running Electron apps on Windows for ARM devices is possible by using the ia32 binary.
lol
Portability is not Electron's strong suit despite all the marketing hype to the contrary.
I know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist. It allows more people to try building more thing and that is a net positive.
The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow. I use it largely as a shell talking to a Go binary that ships within the app package, which makes it only tasked with UI. If you’re having issues with speed, it’s a good approach.
A real world example of this approach is the thing I work on at https://aether.app. (An async collaboration tool for engineers)