Hacker News Reader

Comment by scrollaway | Hacker News Reader

I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit.

For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE, and I don't think I'd be as good in Typescript had I not been a day-1 VS Code user.

I think the main thing preventing it from "feeling" good to most users is the most common complaint on HN about how each individual app is its own version of Chrome. This sucks; it's heavy, it's laggy, and users feel it even instinctively.

OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this.

If it does, honestly, to hell with anything else. I'm sure over time the web world will gravitate towards a fairly common set of widgets that will, at one point or another be standardized. We'll reinvent UI frameworks under a different name, except this time they'll be running under the ultimate cross-platform framework.

View on HN

I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder.

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)

Good rationale from a maker, not a purist, and good luck with your projects!

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!

Thank you! That’s good feedback. It’s there because the demo implies that it’s the demo of the same app, while in reality it’s a similar app targeting a different user base (a superficially Reddit-like peer to peer network). That’s why I say I have two apps, Aether and Aether Pro. The demo on the Aether Pro website is actually just regular Aether P2P.

I’ll try to find a way of making it less of a showstopper though - might be a better way to tell this.

For me, and probably others, the main issue with Electron isn't the speed or even resource usage. It's that it ignores common UX/UI conventions you expect from a native app which still makes me prefer native macOS apps.

I agree with this. Unfortunately that’s a designer bottleneck rather than anything else. Think of it this way, if somebody ends up with a mess of an Electron app, he or she probably wouldn’t have fared any better in usability with a native app even if the UI would look superficially ‘in-spec’.

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.

I wouldn't necessarily say it's just the way it looks, it's also how things work that you get for "free" when you use the native UI toolkit.

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.

Just last week I added shortcuts to our MacOS and Windows Electron app in about 15 minutes. I didn't read any documentation and I'm not even a developer, just a designer. I can barely make a proper if loop in js and I can't tell the difference between a method and a function either.

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!

There’s a lot more to getting an app to feel native than just shortcuts, unfortunately. A native platform toolkit will do the right thing for your platform, sometimes even if you don’t know what the right thing is or that it exists.

I completely agree with this. As a blind screen reader user, Electron apps are 90% inaccessible to me and other screen reader users. Screen readers (on any platform) interact with the underlying libraries/ frameworks. Every operating system supports its own native toolkit. It's a shame that Java's SWT framework fell out of favor for cross-platform software. That is quite accessible. Unfortunately, blind screen reader users are overlooked when it comes to these types of underlying frameworks.

That would have been me 18 months ago. But since dropping macOS I've become indifferent to platform conventions. I will never become hostage to a single platform again. Which (admittedly by a very different route) puts me more in touch with ordinary users, who for the most part don't care or notice.

I think this peaked some time around 2015. Back then, I remember many developers getting up in arms about following Apple's guidelines to a T, or insisting that Android apps look like a hyperactive stack of colorful paper cutouts under a direct light.

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.

You are right but at the same time I am willing to bet you 5 years later someone else will make the opposite argument and be upvoted the same.

It's a pendulum.

Maybe in 5 years one or two of those BigCos will be humbled by an upstart, or the state, or the market, or a previously humbled BigCo (cough Microsoft). Then, by necessity, their design systems will become once again driven by the needs of actual users and developers. That's the underlying pendulum.

I'd bet on the next UI standard being a cross-platform library. Electron-like, but with much more efficient stack, and with binding to multiple languages.

I'd bet on "if you can't beat em', join em". Reactive component-based architectures a la React/Vue have won. The DOM has won for the view layer too. And with wasm, you get your bindings to multiple languages. See: Blazor (it's just the first, more are coming). As for desktop apps that could benefit from proper concurrency, lack of a browser sandbox, full system access, etc. - server side Blazor is quietly pioneering a weird new paradigm - essentially running a headless browser in a regular process with full privileges, and then only doing vdom diffing inside the browser.

> The DOM has won for the view layer too

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.

>cynical branding exercises that come at the cost of UX

Well put!

the push isn't (just) about homogeny of look, it is about consistency for users. When your UI design is backwards (or even inconsistently backwards, such as when a user is in he-IL locale) or you label your Delete button OK on platforms where the user doesn't expect that, it makes using the app frustrating, inefficient, and error-prone

Personally I'm fine with application specific UI schemes. It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation.

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.

> It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation.

They really don’t. Have you taken a look at the thriving ecosystem of native, powerful macOS apps that follow platform conventions?

Most apps that I know people use in MacOS are really not native-controls based - Ableton Live, Max/MSP, VDMX, Resolume, Mathematica, JetBrains IDEs, VSCode, Sublime Text...

I'm pretty sure the parent was talking about macOS exclusive apps. The ones I recognize there are all multi-platform, which have always had the problem of keeping their own conventions between platform or adopting the platforms--most chose to keep their app consistent platform-to-platform.

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.

There are a couple that are cross platform and still native, such as Microsoft Office and the Affinity suite.

Microsoft Office has gotten way better over the years. They used to design the UX around the idea of "Office Users", not "Mac Users"

This is very frustrating when supporting a mixed team of Mac and PC users on office. I would prefer it to be the same everywhere.

And that's the problem. I imagine those Mac users chose it because they like the OS' conventions. Photoshop seems to have gone the other way from using OS conventions to doing their own thing the same on each platform. iTunes, which didn't always follow macOS conventions, did port everything to Windows.

My mac's primary purpose is to run bash, firefox, intellij, and docker. they've all got their own UI, and I don't feel wanting for power.

That’s not the assertion I was refuting, which claimed that Apple’s platform conventions restricted the power of apps.

You might have a point there, if at any time in their sordid history Apple actually followed any of their own UX/UI conventions in their flagship apps.

http://hallofshame.gp.co.at/qtime.htm

That example was 20 years ago, and Apple specifically discarded the skeuomorphic focus which that resulted from around six years ago (partly in concert with retina displays).

Do you have a more modern example?

> has been proven kind of moot since most games have their own domain specific UI schemes and people love them anyway.

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.

I hear you. I forget the control schemes as well, whether they are keyboard or controller.

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.

To be honest, native MacOS UI doesn't even look good compared to the great styling you can get with HTML/CSS.

Native UI toolkits are not necessarily about looking beautiful for every app, they are about consistency, accessibility and letting the user expect how certain things work and can be found at. They have to fit to a lot of constrains that a single app doesn't have to.

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'm intrigued by this. How do you cope with the www?

I use web apps so often that Electron looks natural

Really, that's not an issue with Electron, I think. You can perfectly well make use of a common platform toolkit and still make a completely counter-intuitive UI - and people did that, a lot. In the end, the important things are things like that the cancel button is on the left and the button to confirm is on the right (depending on your platform), not whether it's grey or blue.

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.

I know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist.

Cool. With Electron your app will only work on Linux/Windows/MacOS. There are other cross-platform solutions.

What other PC OSs are there that actually gets used? BSDs?

What other PC OSs are there that actually gets used? BSDs?

Yes. Or Linux on non-x86 platforms.

Electron not supporting ARM or other non-x86 platforms is a big problem that I was not aware of. I wonder if that will change with Microsoft starting to make ARM laptops and Apple being rumored to switch to ARM sometime in the future.

The announcement this whole discussion links to talks about the new ARM support, so I am confused as to what you are talking about.

From https://electronjs.org/docs/tutorial/support:

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.

Oh hey, they finally added vestigial Arm support looks at site for Linux.

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.

If you're bothering to include Linux in your list of Desktop platforms at all you may as well include the BSDs.

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 doubt that the frameworks (e.g., JavaFX) for creating a GUI in Java work fine on the BSDs.

Portable GUI code is harder than portable code without a GUI.

> If you're bothering to include Linux in your list of Desktop platforms at all you may as well include the BSDs.

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.

You can quite easily bundle the Java runtime with your application. Many Java applications do this. As a bonus, it will still be smaller than the equivalent Electron application.

Except Java applets are a thing of the past while seamless browser/browser-based software is a convenient thing of the present (and probably future[0]) and prioritizing size more than availability and usability is fighting the last war harder than a stranded Imperial Japanese soldier.

0: http://wasm.continuation-labs.com/d3demo/

Java applets are not a thing of the past thanks WebAssembly.

Plus we are talking about regular Java here.

As a solo founder, I doubt there are any other platforms that make economic sense to support, especially if it pulls effort away from the real money makers. Depending on the market, Linux wouldn't even make sense to support for most companies and it's only supported because Electron supports it out of the box.

So really you only care about 2 operating systems, and you're willing to give up all the native integration opportunities on both of them for the minor convenience of only having to write one (bad, bloated, totally-out-of-place) GUI.

Developers in the 90s often supported 5 or more different platforms. How is it that modern development is so much worse?

that 'minor' convenience is a quite huge one given that he stated that the other apps wouldn't exist if not for electron.

that 'minor' convenience is a quite huge one given that he stated that the other apps wouldn't exist if not for electron.

That's an awfully bold, if unbelievable, claim given that cross-platform toolkits have existed for a long time.

I'm perfectly happy supporting 99.99% of desktop users out there using Linux/Windows/MacOS. Users of BSD, Haiku, Redox and TempleOS are sadly not numerous enough to support.

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.

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.

Alternatively, you could roll up your sleeves and add support for whatever obscure OS you want to Electron and then have an entire world of apps available to you.

Mediocre and working > not existing

Alternatively, you could roll up your sleeves and add support for whatever obscure OS you want to Electron and then have an entire world of apps available to you.

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.

shrug So maintain it as a third party set of patches. It's not unheard of. For instance, there's a set of Linux patches that improve font rendering. Just because upstream wouldn't accept it doesn't mean that it can't exist.

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 maintain it as a third party set of patches.

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?

> So I can run proprietary apps (because that's what these self-professed app devs are talking about mostly)? Not gonna happen.

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.

You seem to care an awful lot about an issue that doesn't seem to affect you. Why?

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.

> Because it does effect me. [..] VS Code? Definitely not my first choice, but its rust support is still better than IntelliJ

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.

So choose an Electron supported OS

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.

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.

> Why? My whole point is that Electron is encouraging developers to not support other platforms.

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.

If you care about it that much, whip up some patches and maintain them.

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).

>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.

Qt themselves offer Python support.

It’s clear that you aren’t their intended audience. Due to a choice you have made to not use a more common platform. Your responses sound like you’re upset; why? You made your choice. They made theirs. Accept the reality, accept the trade offs, or make changes.

Complaining about the decisions made by other people isn’t useful.

Due to a choice you have made to not use a more common platform.

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.

> Electron is a crass and dishonest attempt at redefining portable and cross-platform to include a very narrow selection of platforms.

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.

>The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow.

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.

That is true and as a user of Sublime myself, I agree. However, VSCode is still a JS app that has to do its computation on a single thread, on a largely interpreted language.

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.

I really hope this is the sort of thing products like VSCode will start turning to WASM for. Performance is their Achilles heel for the time being even though they’ve done a relatively good job considering.

That would be helpful. Go can compile to WASM natively, so if I could just compile it down to that, I wouldn't even have different Go binaries for different platforms.

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.

A couple of things here. WASM isn't necessarily more performant than vanilla JS. For the web, it'll open the door to the JS engine as a compile target, and that's great.... but it's still not super fast.

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).

true that. native module is still quite a lot faster in my experiencee

The Microsoft's React Native for Windows/macOS team keeps comparing how Electron sucks to React Native, so I am hoping that they eventually manage to pull Viscose into their direction.

JS doesn’t have to do computation on a single language. Web workers an option, and I believe Node has additional tools as well.

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).

MS has already proven that canvas is faster and better than HTML for text when they converted the terminal to canvas and it got an order of magnitude faster.

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.

My company does the same, except we farm out to a java process.

> I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder.

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.

How is Qt support for mobile platforms?

As someone who has worked a lot with both Qt and React at my current job, I feel that React is significantly easier for almost everyone. Qt’s complexity negates a lot of its benefits in most hands.

Maybe it is my age showing off, but React easier than Qt??!

Without it, you could do just a web app?

> But Electron has brought true cross-platform development to all platforms (Including Linux!).

Only if we restrict "all platforms" to mean Windows, macOS, and Linux.

Building and porting Electron appears to be a horrific experience [1], which limits its cross-platform utility. It's only recently that someone pulled the heroics of getting Electron 4 (!) into FreeBSD ports; I still can't run VS Code on OpenBSD.

Meanwhile I've yet to encounter an OS with an X11 display where I can't run a Qt app. So I certainly wouldn't hold Electron up as a paragon of cross-platform support.

[1] https://deftly.net/posts/2017-06-01-measuring-the-weight-of-...

> Only if we restrict "all platforms" to mean Windows, macOS, and Linux.

"It's cross-platform! It works on Windows 95 and Windows NT!"

Come on, guys. Don't downvote him. He was being funny. X) Along those lines, we can say anything made for ChristOS is definitely cross-platform. XD (There's a double pun in that one if you know Greek.)

I actually saw statements to that effect in popular computer media in the 90s. So I wasn't just being funny.

You might already know of this option, but if your interest in Electron is limited to running vscode on OpenBSD, there are many offerings, both proprietary and open-source, that offer "hosted" vscode where "hosted" means accessible over the net via an ordinary browser.

(One offering whose name escapes me has the restriction that it is impossible to develop a vscode extension using the offering.)

Electron is so heavy you could include a copy of Windows 95 with every application and use its GUI.

This is how ludicrous the state of modern computing is. Java accomplished the same thing with fewer limitations and vastly more efficiency.

Best case scenario of the continuing "evolution" of electron is the elimination of the OS entirely. Why do you need it? Just put drivers in Chrome and be done with it. It's already the rest of the damn OS to a lot of people (notably not people like me).

In a later version of Electron (for Windows 10), it could use the Windows supplied Chromium WebView and shrink the size by 80%+.

> Electron is so heavy

Does it matter? I think heaviness should be defined relatively to the computer resources. Currently VSCode memory usage is 75MB on my computer. It could be 10 times less, it wouldn't make any difference.

Which OS are you using for that kind of memory usage? I've tried it, and seen double that out-of-the-box.

50.6MB for me on a 2018 MacBook Pro running macOS Mojave.

Macbook Pro 2018, Catalina

> Does it matter?

Not really I guess, I mean who cares about the user's computing resources? Certainly not developers.

Java eats about a quarter-gig of disk space on my windows installation. That's a bit less than the base electron bundle. That is one installation for the computer, but that's due to dumb packaging (you _could_ just tell everyone to install chrome, just like you used to tell everyone to install java; we've forsaken that space for convenience.) The ui of java then was significantly more bounded in flexibility. So we've forsaken space savings of old java for subjectively-prettier ui.

> Best case scenario of the continuing "evolution" of electron is the elimination of the OS entirely. Why do you need it? Just put drivers in Chrome and be done with it.

Have you used a chromebook?

That sounds like Rodney Dangerfield describing Jimmy Carter in the SNL "The Pepsi Syndrome" sketch:

Dr. Casey: “It means, Mrs. Carter, your husband, President Carter, has become [camera zooms in on Dr. Casey] the amazing colossal president.”

Mrs. Carter: “Well, how big is he?”

Dr. Casey: “Well, Mrs. Carter, it’s difficult to comprehend just how big he is but to give you some idea, we’ve asked comedian Rodney Dangerfield to come along today to help explain it to you. Rodney?”

[Rodney Dangerfield enters]

Rodney: “How do you do, how are you?”

Denton: “Rodney, can you please tell us, how big is the president?”

Rodney: “Oh, he’s a big guy, I’ll tell you that, he’s a big guy. I tell you, he’s so big, I saw him sitting in the George Washington Bridge dangling his feet in the water! He’s a big guy!”

Mrs. Carter: “Oh my God! Jimmy! Oh God!”

Rodney: “Oh, he’s big, I’ll tell you that, boy. He’s so big that when two girls make love to him at the same time, they never meet each other! He’s a big guy, I’ll tell you!”

Mrs. Carter: “Oh no! Oh Jimmy! My Jimmy!”

Rodney: “I don’t want to upset you, lady, he’s big, you know what I mean? Why, he could have an affair with the Lincoln Tunnel! I mean, he’s really high! He’s big, I’ll tell you! He’s a big guy!”

Mrs. Carter: “No! No! No!”

Denton: “Rodney, thank you very much. You can go.”

Rodney: “It’s my pleasure. He’s way up there, lady! You know what I mean?”

—Saturday Night Live, Season 4: Episode 16, “The Pepsi Syndrome” skit, Apr. 7, 1979

https://snltranscripts.jt.org/78/78ppepsi.phtml

I'd rather see SwiftUI or something like it ported to other systems with a "driver" that translates it to each platform's 100% native UI.

It's already amazing in how it abstracts common elements for such distinct environments like desktop, phone, TV and watch while still exposing OS-specific features. Why not other operating systems?

Insert any framework in place of SwiftUI. You're describing Qt, essentially.

The approach has been tried, and succeeded to some degree. But the web is the only app where cross-platform is the default, and it's truly hard to avoid it. Even if the widgets all look different. Even if nothing looks native (people got used to it anyway).

And to be clear I want the status quo to improve in this regard, especially in terms of accessibility (nobody should have to reimplement eg their own dropdown especially if it breaks eg. keyboard shortcuts, mobile UIs and so on). But I can't see anything from today that isn't either a web technology, or web-compatible (and web-accessible, not the Qt webgl hack that's on the frontpage right now) making it in the long term.

> But the web is the only app where cross-platform is the default

That's just because it describes its own embedded rendering system.

> Insert any framework in place of SwiftUI. You're describing Qt, essentially.

SwiftUI's syntax feels closer to a markup language than code, though, so it might be more appealing to web frontend devs.

QT Quick also uses a markup language.

Not a good or reasonable one, though. This is no slight against Qt devs, and I think they're fixing it in Qt6, but it's just not good.

QML is basically javascript with some syntactic sugar. I loathe javascript as much as anyone but that's not dramatically different from Electron.

I didn't claim Electron was good, either.

>But the web is the only app where cross-platform is the default

No. Chrome is the only platform that is cross platform by default. But IE, eg, has definitely had behavior differences in the past.

On the other hand, Qt is cross language, but not necessarily cross platform (it excludes iPhone and Android, say)

> Qt is cross language, but not necessarily cross platform (it excludes iPhone and Android, say)

Qt supports Android and iPhone.

Chrome is not the only web browser out there.

>Insert any framework in place of SwiftUI. You're describing Qt, essentially.

Only Qt never had the funding or resources or will to get native UI right.

Their non-native widgets are always off, in a way that even Electron, is not (because it being web-based means it at least follows familiar conventions for all web users, where a mimicked native GUI enters the uncanny valley).

There are also custom native but not platform-native (meaning close to the metal, no web-based) GUIs like Adobes, Fruity Loops, and others, that look good on all platforms and users have no issues with them.

I don't. The reason is UI kits on different OSs are so different that allowing this stuff makes for haggard looking apps. Using the web at least brings consistency to the experience. There's no workaround I can think of, you either write one UI per OS (even with QT you still need to adjust for conventions, spacing etc...) or you make an OS agnostic UI with Web tech.

> (even with QT you still need to adjust for conventions, spacing etc...)

That is what I'm talking about: SwiftUI automatically uses the recommended conventions for spacing, padding, etc. which are different for macOS vs. iOS etc., and it also takes user environment settings into account, like font sizes and other accessibility options.

Unfortunately swift doesn't have a meaningful windows story, and giving up on 100s of millions of users is less than ideal for most "crossplatform" contexts. :/

Swift is open-source at least, and I expect/hope SwiftUI will be too once the "secret" Swift features it relies on, have matured.

So even if Apple doesn't want to port SwiftUI, maybe other people could.

I don't think it's possible to do it in a way that consistently looks good. I've been around my fair share of cross platform frameworks and worked at companies that built them commercially, they never work beyond apps that aren't supposed to look great.

Qt does that, too, but that is not nearly enough if you really want to make pixel- and interaction- perfect things. A "native" macos app is fundamentally different from a "native" windows app. Dock vs systray, different usage of menus, mouse and keyboard. Different widgets - Windows does not use baloon widgets and sheets. etc etc...

> A "native" macos app is fundamentally different from a "native" windows app.

The visual and interactive differences between a macOS app and a Windows app are actually less stark than the differences between a macOS app and a watchOS app (crown) or a tvOS app (remote), but so far, despite its early bugs and limitations, SwiftUI does a great job of outputting the native controls on all [of Apple's] platforms.

Things like NavigationViews and TabViews produce different beasts on macOS, iOS, iPadOS, and tvOS, from the same code.

See WWDC 2019: SwiftUI On All Devices: https://developer.apple.com/videos/play/wwdc2019/240/

It can do this only because Apple exercises such tight control over all platforms. When everything is developed under the same roof, it is significantly easier to make it, "Just work." On the other hand, making three, independently-developed platforms look the same is nearly impossible. On a windows or linux box, you cannot guarantee things like screen resolution, ppi, dimensions, specs, compatibility, and the innumerable other things that cause trouble.

There are almost no technical reasons, only political, for why we don't have a truly cross-platform, truly native UI framework by now.

The whole situation is bizarre and comical if you look at it from a distance:

Everybody ALREADY puts tremendous effort in making sure things look and work the same everywhere: Browsers!

Not just Apple, Google, Microsoft and Mozilla, but the thousands of third-party maintainers (like yes Electron) in this newly-created circle of Hel that is the JavaScript ecosystem.

And now we're trying to turn the browsers into operating systems!!

Everyone keeps trying to reinvent a wheel that doesn't travel very far to begin with (see all the missing features from web apps that native apps get, being discussed on this page.)

If only each OS would ship an abstraction layer that guaranteed "at least modern browser X" that one could ship into. I want to ship an electron app but I want it to be 100kb and start in 0.1s and take almost no memory because the libs are shared. I don't want each little chat app or music player to gobble up half a gig of ram and take 3 seconds to start.

I give it 15 minutes before decisions, well reasoned or otherwise, by the individual platforms cause incompatibility issues that make you wish you'd just shipped your own copy of Chrome in the first place. This is part of the reason Electron even exists.

I think OS makers explicitly don't want to do this. In the case of Apple, they prefer you to use all their tools and technologies. It allows them more management of the experience.

Using the word experience is why we're in this mess. These are tools we're talking about. Not an African safari.

Microsoft is working on an API that will use the chromium that's part of their new version of edge. It's already available for use (of course right now you have to have the edge beta downloaded): https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...

Is this anything other than just a webview?

Thank you!!! I have been waiting for that shoe to drop. Since the OLE interfaces to IE are hopelessly out of date by decades.

You just re-invented the PWA, basically. Only modern browsers support them (though you can't guarantee eveyrone has one), so you just package and ship a web site. Of course, browser tabs themselves can take a lot of memory; a fair number take 50 megs apiece, and some take 100, so don't bet on your site necessarily only taking a few kb.

Well I also need good native apis (files, hardware, OS integration, window management), and deployment scenarios like native apps.

But yes, like PWA but I want the app to run under the OS, not sandboxed in a browser.

Free Pascal & Lazarus has already solved this problem, but no one cares because Pascal is outdated & therefore we need to reinvent the wheel over & over but doing it worse for every iteration.

Kinda. Lazarus is great and all (though even Delphi 2 felt more coherent, which is a side effect of Lazarus not really being a single project nor the result of a single vision), but the only LCL backend where everything works as expected is the Win32 one with the Gtk2 one being just a bit behind. Other backends are of a much more "alpha" quality, especially the Cocoa backend (for many years the Carbon backend was what was developed since it was easier to interface from C - AFAIK the Cocoa backend really got focus when Free Pascal got its "Objective Pascal" compiler mode that extends their OBJFPC dialect with Objective-C compatible features and the ability to directly use Objective-C objects) and the overall Mac support is lacking in manpower compared to the others (some people prefer to use the Qt backend - which isn't as good as the Win32/Gtk2 - just so they get a bit better Mac support, but that adds a lot of extra unnecessary bloat since in addition to LCL's own overhead, you also get the Qt4Pas overhead and Qt's own overhead, not to mention you do not get "real" native widgets).

>> OSes and frameworks have tried to solve this a bazillion ways.

What is different today is that Windows 10 and other popular platforms adopted Flat UI. Users no longer expect apps to have “native look & feel” because Flat UI has no recognizable or desirable look & feel. This is a big mistake by Microsoft because there is no longer any reason for independent developers to write native Windows apps. This works to the benefit of Electron and also users of non-Windows platforms.

I don't think that is even a worry for microsoft. Its looking like MS is going to make blazor on electron and eventually blazor on native their cross platform UI.

Microsoft has made it pretty clear since about Windows 10 that they don't actually care about the Desktop anymore. It certainly isn't anywhere near their biggest money-maker.

Indeed, that is why Microsoft has created teams to support React Native for macOS and Windows, on Windows case it makes use of UWP, which new roadmap (WinUI 3.0) was announced at BUILD 2019, with more details to come up on Ignite.

Yeah, Microsoft bashing never grows old.

Yeah ok, fair point. Someone at Microsoft cares a bit about Windows, just not anybody working on the UX bits.

Given the market size of laptops, 2-1 hybrids and graphical workstations running Windows, the UI/UX toolings that are available, I fail to see what you mean.

I mean the experience of using Windows has dramatically declined in the past 5 years. Forced Windows updates was a terrible idea, updates break things much more often, the start menu has ads in it by default, start menu search does strange things, it's possible to break the start menu, if you unpin an application from the task bar while it has running instances and then re-pin it you'll sometimes end up with multiple icons, the new settings panels are slower and less capable than the old ones...

Which just goes to show you how ridiculous the demand for "native look and feel" is. Of course no non technical person has ever demanded such a thing. It's like caring about the tech stack. No one cares but developers.

Besides memory consumption, the killer feature for me would be true native text boxes. Skype on the Mac won't expand my abbreviations, use my dictionaries, etc. Drives me nuts.

Maybe that's Skype's fault, it wouldn't surprise me, but I think I've seen this behavior elsewhere. Skype is, thankfully, the only Electron app I have to interact frequently.

Skype is not an electron app though: https://microsoft.github.io/reactxp/blog/2017/04/27/building...

I cannot love Electron. It's almost always an inappropriate choice for a desktop application, yet I see more and more of what should be power-user desktop applications moving towards using it, and it is horrible.

My largest gripe with it, besides the others that are discussed ad nauseum already, is that it is impossible, seemingly, for Electron apps to spawn multiple windows without creating entire new instances. I have several Electron-based chat applications that are a trainwreck to use, compared to their predecessors, because there is no effective way to handle more than one chat at a time; they can't just pop out a small dedicated window for a chat conversation, they have to live inside their one window, and this results in a terrible tabbed UI where one is constantly flipping back and forth between conversation threads. Or the bevy of Electron text editors that you cannot tear a file tab off and put on another screen.

This isn't really true. Electron itself has a renderer process and a background process. It's completely possible to make multiple renderers with independent windows that can coordinate with IPC through the background process. We have an electron app that does this and has undockable tabs, it's not even very hard to implement if you're using something like Redux for a window level state store, you just pass it thru IPC to the new session.

the most important reason that leads to electron's adoption, I believe, is the flexibility and customizability of HTML UI compared to traditional widget-based ones.

This is a weak argument, unless people have just never used desktop widget libraries and are arguing against an imagined strawman. There is not a farthings real difference between the two.

Agreed. We need a cross-OS definition of "web views" and a standard way to say, "use my default browser for all web views, including Electron".

It seems like that's not really going to work for the developers of these apps due to browser variation and version skew? (If it were okay, why aren't they supporting web browsers already?) But maybe apps on the same version of Electron could share a runtime?

Web developers are already accustomed to supporting much more widely-varying browser versions, and web standards are expressly designed to be backwards-compatible basically forever. I don't think it would be a major problem.

Discord, to take an example, does support running in a browser. It's how I usually run it.

It also comes as an Electron app, because it wants more system privileges than browser tabs are ever allowed to get -- to tell people what game you're playing.

Really, given that the primary consumer of this API would be Electron and that it would take a huge coordination between OS and browser vendors to create a standard, it seems like it would be possible for Electron to just circumvent it and come up with their own way of sharing Chromiums between their own apps. When building you could specify whether you want your build to be fully portable, portable with the option of sharing, or fully reliant on a system-wide Chromium copy. On startup, an Electron app could check for an existing shared copy and automatically install its dependencies. The same could be done for Node.

this library seems promising: https://github.com/zserge/webview

Something unfortunate is that last I checked React didn't really have a good UI lib to give an "app" feel. So something like VSCode or what not would not really be feasible in the most popular libs.. Would be great if there were some UI libs on par with Qt and the like.

EDIT: I fail-skimmed your comment and missed the Qt mention! Glad there are more folks out there seeing the same.

> Electron has brought true cross-platform development to all platforms (Including Linux!).

Last I checked, electron did not work on OpenBSD.

Is the comparison with Qt relevant? My understanding is that Electron is for JavaScript what Qt is for C++. Is there not a better fit for C++ development in the web UI ecosystem?

> My understanding is that Electron is for JavaScript what Qt is for C++.

This is a weird comparison. Electron isn't really a UI framework, it's more of a customized web browser and JS runner, with some platform APIs to bridge the gap. But no, I don't know of anything serious that lets you write web UIs in C++. The closest you'll get are things like Google's Closure Compiler which compile Java to JS.

There's very likely something for C++, but nobody's seriously using that, probably because nobody actually wants this. "All of C++'s hare-brained syntax and slow iteration speed, with none of the performance benefits!" is not a good selling point.

not exactly the most performant but there is https://ultralig.ht/

Closure compiles JS to JS, you must be thinking fo GWT.

Right.

> Is the comparison with Qt relevant?

Absolutely, when considering cross-platform UI frameworks in general. In that sense, Qt competes not only with Electron, but also with toolkits like wxWidgets, GTK+, JavaFX, Flash, and some older ones like Java/Swing, Lazarus and Adobe/Macromedia Director.

> will gravitate towards a fairly common set of widgets that will

Is there anything like that? There is for mobile (Framework7 I like the most) but is there anything for desktop that allows me to create applications with electron in a more desktop like way? I am one of those people that doesn't really html/css. In WPF/QT/Winforms/Gtks/Xamarin/Avalonia/iOS/Android/Lazarus/Livecode I can create complex applications very fast (and a few of these are cross platform too); they don't look great (albeit consistent and not horrible), but something is working and working well in a very short time (hours). I have not found anything for Electron that works as fast as that, including bindings and logic etc.

I do a lot of HTML/css, but for web; simple things like getting a few decent looking panes with buttons and text etc that scales automatically still feels like a from scratch exercise and when using standard stuff like Bootstrap, everything looks and feels like web, not desktop. I have friends who created native looking Electron apps and it took forever to make it work well and look good (lot of quirks they had to deal with, but this is a while ago); with Qt or Avalonia (I use mostly C#) it would maybe (?) not look 'as good' (which is taste) but it would be done much faster.

There are things like [0] but then all look like Mac OS X. Are there any good ones cross platform or at least a little more 'neutral' than photon?

[0] http://photonkit.com/

If you are willing to code your own GUI widgets, it's also pretty easy to do cross-platform. You can opt for OpenGL or similar and a little glue for the various platforms. If you slowly grow a collection of just your favorite widtes, that's totally doable. Will grow to maybe 10-15K lines of C code. That's a lot of explicit code, but on the upside the code will be more maintainable compared to all the boilerplate the would be required to bend a super-general library to fit your requirements.

I've done a few OpenGL toy apps in the last months, and one commercial project that includes text widgets, editing, table views, buttons, scrollbars and so on. It also scales freely. It's not that hard, and the next time will be even easier.

>OSes and frameworks have tried to solve this a bazillion ways. Edge WebView, Android WebView, Qt WebView, QtWebkit, whatever the iexplore stuff was in XP, …. Electron might have the opportunity to actually solve this.

That list goes on and on. Don't forget xulrunner. Or heck, even Visix Galaxy! (Ask Jeff Barr about that one some time. ;) )

http://www.ambiencia.com/overviewgalaxytd.php

I am quite bullish on PySide2 (Qt Python framework). I don't hate Electron. It's just I am more Python guy rather than JavaScript guy.

PySide2 is free for commercial purpose (with some caveats: LGPL).

https://doc.qt.io/qtforpython/

Except it isn't all platforms - it doesn't include iOS and Android. But the web, especially an installable web app (PWA) is exactly all platforms. As well as solving the issue of a shared chromium engine, or engine of your choice.

Laziness always wins apparently.

I thought QT worked across all platforms?

Also, I think JVM UI frameworks still offer more than people believe. JavaFx and even the good old Swing work cross platform. Compared to Electron apps, they even hold in terms of performance and memory use.

Well, I think the market is waiting for Qt.

What I would very much appreciate is:

QT-free (so that everything in that package is clearly LGPL) with React-native built on top of QT-free widgets.

That would make my day (and a year...)

> QT-free (so that everything in that package is clearly LGPL)

The immense majority of Qt is LGPL ; only these modules are GPL / commercial : https://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons

> with React-native built on top of QT-free widgets.

https://blog.atulr.com/nodegui-intro/

though I still think that QtQuick (or even QtWidgets with https://www.kdab.com/declarative-widgets/) are much more readable and fast to market.

What is you opinion on flutter? esp performance wise?

A last attempt to try to rescue Dart from oblivion.

I mean only if you like working in web front-end land and I'd rather never use a computer again than do that.

glad to see someone else who thinks like this. the way people seem to react to electron apps is very close to "they killed my pappy!" kind of anger.

Reply on news.ycombinator.com