Hacker News Reader

Comment by yoz-y | Hacker News Reader

The problem I see with Electron (and probably one of the reasons HN hates it) is that it leverages the advances in chip making to work as well as an app from 20 years ago, but is multi platform.

It is a huge productivity boost for programmers at the expense of making computers slow. On my work computer I am used to run many apps, and with each Electron app added I feel it slowing down. (latest one to switch was Skype for me). What is the point of having such powerful computers when they feel like slugs crawling through a bog?

View on HN

> It is a huge productivity boost for programmers at the expense of making computers slow.

It's a productivity boost for web developers, who don't have to learn a new language, and for companies that can hire cheap web developers instead of more expensive desktop developers. It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.

Users benefit from it too since the alternative to Electron often is not .NET or Qt but no app at all, especially on Linux.

As far as I'm concerned, I'd rather have no app at all (and use an alternative) than have an Electron app suck users away from the potential native alternative.

So don't use it and use the web version. A potential native app is of no interest to me compared to an actual full featured Electron app.

If the Electron app exists, there's a lot less incentive to write the native one.

If the Electron app exists, often the alternative is no app at all.

See Slack. If Slack were still some plucky startup, I can understand it using Electron. But it's been around for a while now, and a more performant native application doesn't seem to be coming anytime soon.

Luckily Slack has the IRC and XMPP bridges. can't imagine any other protocols with a wealth of highly performant clients to choose from.

Unlucky for me, my admins refuse to enable the bridges and also won't grant me an API key for use with the weechat slack plugin.

I hate Slack so much. Slow and miserable and unconfigurable and just crashes at least once a month.

Sadly, Slack also happily breaks the protocols in their bridges, e.g. producing invalid IRC usernames. So even though our Slack has the bridge enabled, I can't login to it since it wants me to put a dot in my nick.

Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated. The truth is, even for huge companies like Microsoft, the cost of doing a Linux-specific app is not worth it given the small user base, but with Electron they get this for free so they do it.

This is even more true for resource-limited open source projects, as cross-platform gui-based ones are difficult to get right, but Electron makes that easier.

Now I've heard it all - a company with a seven hundred billion dollar market cap can't afford it. Come on. They can absolutely afford to do native Windows / MacOS / Linux cross platform. They're lazy/don't want to.

> Now I've heard it all - a company with a seven hundred billion dollar market cap can't afford it. Come on. They can absolutely afford to do native Windows / MacOS / Linux cross platform. They're lazy/don't want to.

That’s a straw man argument. The parent said that Linux development might not be worth the cost. They didn’t say anything about the ability to pay.

So we, linux users, actively promoting alternatives for Skype, to increase cost of ignoring us.

«Team, M$ killed Skype for linux, I cannot use it anymore, let switch to something else, like Slack.»

They can do it but if it's not profitable, they won't. It's not being lazy, it's being smart in the capitalist sense.

I'm fine with that, just call it like it is. This is what Microsoft truly thinks of developing a 1st class open-source solution - not worth their time because it's not profitable enough. So they'll give you a second class solution with the assumption you'd rather have that then nothing.

They can afford it. They can also afford to put a man on the moon, but it isn't necessarily financially reasonable for them to do so. Think of Microsoft as a collection of teams, each team can't afford to spend "Microsoft" money on its project unless its strategically important. The fact that we don't have native app probably indicates that Microsoft thinks Skype is past its peak of popularity. Thinking of many competing products I understand why.

Skype for a long time only had an outdated application on Linux. Now that MS converted it to Electron, it's available and regularly updated.

And now Mac users get the same terrible Electron app. The problem is that companies are not just making Electron apps for Linux users. They are replacing native well-integrated Mac and Windows applications by Electron apps (Skype) or do not consider writing native apps (Slack).

So, we had nicely integrated applications with Automator workflows, consistent shortcuts, consistent look and consistent feel. And we are replacing them by things that do not fit into the platform at all. No thanks.

Skype used to have a small, snappy and useful app for Linux. Now that MS converted it to Electron, I no longer use it. Qt makes multiplatform apps trivial. Even I, as a hobbyist free software developer, can provide binaries for Linux, Windows and Mac.

A lot of people, myself included, actually preferred the Linux version of Skype.

But to be honest, I'd rather have no GUI app on Mac/Linux at all than have it basically be a requirement to waste resources on Slack or whatever other crap and to have developer energy tied up in an editor as shitty as Atom.

I'm working on a native client for Slack, Skype, Twitter etc.

It's only 90 KB (!)

https://eul.im

Is it 90kb installer or complete app? Also what are using to build the interface?

It's the complete app. Cocoa on macos, WinAPI on Windows, GTK on Linux.

Is this the one that uses OpenGL or something to render everything (ie nonnative text controls etc)?

Not any more. Now it uses native controls.

Oh nice, I need to check this out then!

How you do this? Probably some of us could guess, but maybe will help people that only know electron :)

Cocoa on macOS, WinAPI on Windows, GTK on Linux.

Nice joke. Repository is empty. Source archives are empty. Binary release for Linux: 404.

the dev is using github as a bug tracker, not as a place to host code. if thats’s a problem for you feel free not to download it

The dev released source archive for Linux to compile code by yourself. Empty source archive.

This is not true. Nothing has been released for Linux yet.

This is true. Nothing has been released for Linux yet.

In some alternate reality, reasonable resource usage is considered a feature.

Meanwhile, in our universe, it's somehow considered reasonable to expend nearly six gigawatts (= 51 TWh per year) on a number-guessing game that will totally revolutionize global finance some day.

Resource usage in this reality will only become reasonable when there will be a noticeable penalty involved in unreasonable usage, but I guess it boils down to what you define as reasonable: If a noticeable penalty is measured by the end user then - sorry, enough users just don't care, which enables this technology to continue to gain popularity. If there was a law that companies need to pay a percentage of the energy their applications use then you'd quickly see everybody moving not only to native apps, but to the most efficient native apps.

In the meantime, the invisible hand is doing it's thing. Time will tell what it's thing will look like.

I think a brief look at the wiki page for 'Anthropocene' tells us exactly what the invisible hand is up to.

I would rather run something in wine or run nothing at all than have to run an electron app. It's that bad.

How bad is it to run Electron apps on Linux?

Slack uses ~ 2 GB of Ram and ~ 10% CPU when idle. I used it for a short while but now I'm just leaving a Slack tab open in my browser. Its exactly the same functionality-wise.

Basically I'm fine with Electron apps but I have yet to find one that I need and can't be replaced by a browser tab.

Comments like this make me wonder what's going on exactly. Surely your browser tab should now be using ~2GB of Ram and ~10% CPU, since it's the browser, HTML and JS part of Electron that's causing all that?

To be honest though, since my VS Code instance is sitting at ~500 MB (all processes together) and 0%, I'd wager it's not actually Electron itself that's at fault. It probably is incredibly inefficient compared to pure native code, and probably makes it easy to write inefficient code, but still, that's quite heavy usage you're referring to.

My guess is that a lot of memory in the browser is shared.

Another commentor in this thread wrote that VS Code is incredible efficient for a Electron app.

That could certainly account for some of the memory usage. I'm still confused about why there would be a 10% cpu usage on one, and not on the browser version (especially if they are equivalent, or even share underlying code).

VS Code certainly is efficient for an Electron app, and I'm sure it's really hard to achieve that level of efficiency. To be honest though, I use it side by side with Visual Studio itself, and on many metrics, it eats its big brother for breakfast (e.g. [1])... and that is a native app. One can argue that it's apples and oranges, and that the two are not equivalent, but we have an interesting counterpoint. While I'm sure performance is heavily weighted in favour of native, it seems like it's certainly surmountable.

[1] https://twitter.com/id_aa_carmack/status/695013979807047680?...

My theory on Slack's ridiculous CPU use is animated graphics. If some of those are on the screen the CPU use is at least 10%.

My theory is that their code is shit. It shouldn't be surprising given that their Chief Architect wrote a Medium post (Oct 2016) in which he cited concurrency as one of the primary benefits of PHP, and advocated for "curl'ing to localhost" to achieve parallelism.

On my laptop running Slack Linux 3.0.5 with 3 workspaces & several dozen channels, it idles at 0% CPU and ~550MB RAM (see screenshot [1]).

[1] https://i.imgur.com/juQbGW7.png

Haven't been using it since ~ 2 years. My data might be out of date.

Comparing it to similar native app like pidgin it is still about 10 times more.

With 10 times the features, it’s not at all unreasonable.

That's also roughly what I see on Windows for my Electron app [0]. 0% idle CPU and about 200MB of RAM. That's large but acceptable compared with other non-Electron apps running, like Sublime Text (170MB) or Thunderbird (320 MB).

[0] https://imgur.com/tMhEwtp.png

You have some choice native apps - Sublime is Python, which is rather horrible with memory usage and Thunderbird essentially embeds a browser just like Electron apps.

Compare VSCode or Atom with Emacs or Gvim for something more native.

To pick some apps off my desktop right now:

- Emacs with a pile of extensions, 22 MB

- SpeedCrunch, 13 MB

- SumatraPDF, 19 MB

- MS Word, 101 MB

In my list of applications that are always active, Firefox and ConEmu are also over 500MB too. The exception is Total Commander (amazingly, still compatible with Windows 3.1), which is only 20MB but it's more the exception than the rule.

Uhh sublime is written in C++ with it's own custom UI the toolkit iirc. It only uses python for scripting.

Well, I'm a Linux user and I strongly disagree. Looks like opinions are indeed like a certain posterior orifice.

If it's a .NET app on Linux, you just run Wine, and you're all set.

This is the weird elitist argument again. I've done my share of native UI development, and it's total pain compared to HTML/CSS/JS. The tools are crap, the compile cycles too long, the languages to restrictive, the APIs too ad-hoc, the layout engines too crappy, the technology support (eg. multimedia) lagging too many years etc etc.

The native libraries had decades to fix this mess, yet they're still by and large the same as decades ago. Will not miss them.

> It's not a productivity boost for someone who knows (or is willing to learn) .NET or Qt.

You do not understand what a productivity boost is if you think learning a totally new language and framework is a better choice than using the tools already available.

But also if your logic were correct, we'd all still be writing C.

.net or qt don't offer all of the beautiful ui experiences available for the web. The latest and greatest in ui tech is now on the web in the form of JS/React/css.

Yes they do, with XAML and Qt Quick respectively. On the desktop, I'd rather have the normal menu + toolbars layout though.

Yep, I totally get this.

There's a world in which Electron (or rather, "web views as apps") don't exist and Slack is native. Though perhaps it wouldn't have ever happened.

I feel like _many_ of the big apps simply wouldn't have existed in the old model. Native app development has become extremely niche, and each OS has its own quirks. And on the other side of the fence, stuff like Salesforce exist in the browser pretty well.

It's hard to get the causal arrows right on this. But I bet if React Native-style solutions can work well, people would be willing to put in the effort to use it. But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.

> But so long as the web stack is easier for developers, that'll be where the MVPs get made IMO.

Is it really easier for developers, or do people learn web development first, so it's easier to use the same skills on the desktop than learn new ones?

If find it hard to believe React etc. are easier than .Net, for instance.

Reactive UI is easier to reason about I'd say. One thing I'd like to see is a native reactive UI framework that would be thought as such from the ground up. So far react on web is a whole bunch of hacks and react native also wraps classic UI elements.

UI debugging tools in the web are amazing. I can inspect the entire DOM, add code to test some new concepts, edit layout and get instant results.

To my knowledge, almost no native UI libraries have good support for CSS-style selectors. Being able to write out selection rules like "odd elements in this kind of list of elements" is extremely useful.

This is going to sound silly, but almost no native UI toolkit has a good "screenshots" section on its website. Meanwhile you go over to Bootstrap and you see stuff you actually recognize. This is important! It proves that you can actually make nice looking things.

Stuff like interface designers shipped by MSFT are pretty great though.

CSS is so crappy that I wouldn't be able to get anything done without the devtools. On the other hand with most native GUI libraries I've never had a problem to get the layout I wanted.

UI tools for the web are amazaingly horrible. I can’t imagine anyone who thinks the chrome debugger is better than debugging .net in visual studios, while, if you want, XAML has most of the things that CSS has (but I do mostly canvas on both platforms).

Programming for the web makes me feel like I’m back in the 90s, no even Java/Swing was easier. I get making the sacrifice if it means I can run in the browser, but not otherwise.

I didn't do that much Swing, but the feedback loop for UI design in the web definitely felt a lot easier.

I have fond memories of debugging C# with Msft tools, but I also suffered a decent amount on the debugging cycle in C/C++. Being able to just patch in some new code without going through a whole compile/set up the environment again is very useful.

I can understand thinking that the foundation of the web is bad, therefore web development is bad. But I would take the chrome debugger experience over C/PHP/Java debugging experience most days of the week.

(That being said, I could simply be unaware of some debugging tools in that space that make things nicer)

Java supported hot code replacement since 2000 or so, they actually had/have a fairly decent implementation (better than .net). But since they didn’t have a declarative DOM representation, it would be hard pressed to use it to add or remove elements. JavaFX fixed that, but that effort failed completely.

Doing UI in C/C++ sucks, but that was also true in the 90s.

Chrome is a horrible debugger from a UI design perspective. Debugging through VSCode is better, but I still miss simple things like auto toString displays. Surely the tools could get much better, that they haven’t is depressing.

Every time I have to frig around with debugging a new-fangled JS SPA UI, it makes me want to hurt whoever is responsible for bringing the industry to this state. It was easier in VB6. It's miles easier to but something decent together, that actually works, in .net WinForms.

imo React and Css rocks hard, I don't like .NET because Visual Studio, and I love js, css, html because Visual Code. Also metatags are what user interface design should have been since always, and there is nothing better for that than html and react. Yes sure, you have wpf and uwp (both using xaml), but they are no near as good.

I don't think it is a matter of being easier for developers. The common case simply is that something starts as a web app to get to a wider range of users, then they leverage Electron for more specialized features and/or convenience made possible due to more control and freedom on the desktop app.

I fear the long term problem is that "programmers" gets further and further mentally removed from the hardware that their code will ultimately run on.

There was already the problem of them using massively more powerful hardware than their customers, in particular in the consumer segment, but now more and more they seem to not even understand what a "computer" by the looks of it.

With "cloud services" they do not need to think about the servers sitting in racks doing the computing.

And with Electron, this kind of mental distance is making its way onto the desktop.

Pretty sure your fear is the same that assembler programmers had when C programmers appear.

Pretty sure you don’t know what you’re talking about. Assembler programmers in the 50’s didn’t “fear” anything, much less C, which wasn’t even a spark in DMR’s eye, they just didn’t believe that a high-level language would be as efficient. Fortran with its 57 (?) optimization passes during compilation proved everyone wrong. But there was never “fear”. There is fear today though, and it’s very justified.

No, there is not fear in the industry. It is just people that refuse to learn js/html/css ecosystem that get outraged when see a electron app. Will you seriously think that a company like Skype didnt think and weight every option before doing their electron app? Sure enough they are not as efficient as native apps, and sure enough there are a lot of apps that thinks everyone have an i7 and 16 gb of ram, but the same problems had Java 20 years ago, pretty much with the same promises than Electron (Write Once, Run Anywhere), and it did pretty good.

Java's run as desktop/web application platform, is nowhere good. It thrived on server, where WORA had limited appeal.

> It is just people that refuse to learn js/html/css ecosystem that get outraged when see a electron app.

I was once really into frontend web dev, and learned JS/HTML/CSS. Then I realized it mostly sucked, and went to school for EE. Now I get more upset than anyone I know about Electron apps.

It only takes one counter example.

"It is just people that refuse to learn js/html/css ecosystem"

Can't I just as easily say that the JS/HTML/CSS people are the ones refusing to learn a new ecosystem?

As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux.

I also don't notice my machine slowing down with Electron apps.

> As a Linux user, it's a huge productivity boost because I wouldn't be able to use 90% of the app I us since they wouldn't be available on Linux.

That's not true. There are native cross-platform GUI toolkits, such as Qt. There's just as much reason for a Qt app to run on Linux as an Electron app.

I think the guy you're replying to's point is that Qt versions of the apps he uses don't exist - the Electron ones do.

The alternative to many Electron apps isn't a native app in another framework, it would simply be no app (on linux).

Usually the alternative to many electron apps is the web version which lacks 5% of the features but is 10 times more efficient.

Native and Electron apps have two advantages over web though. Fist one is, that they do have access to the file system. This makes a whole range of applications (like Git Kraken) possible. The other is that an application has an icon in the taskbar/dock. When somebody pings me on slack I know where to go to read it. When somebody calls me in hangouts, I have to go fishing for the tab or window with the site open.

Not true.

One example of a service that probably _could_ have a web version is Spotify, but they only offer their service via their Electron app.

Apps I care about are VSCode, Atom, Spotify, Slack.

Spotify actually does have a web player.

Yup.

Is there not one engineer on this whole planet with the skill and motivation to make a cross-platform typescript+GUI thing that is efficient from the ground up? I'm often baffled by the seemingly obvious gaps that exist in this profession.

Noob question. What makes electron apps slow? The electron framework or the web apps that it wraps?

Electron apps are basically a Chrome window with a webpage loaded. This means that, for example, they use HTML to display the UI. HTML/CSS is complex and very dynamic, this makes it resource intensive to parse and load. Then, the whole application is written in JavaScript which is a language that is "far from the metal" (although this is getting better due to a massive investment of web browser developers).

There is also a more hidden problem, which is that Electron app developers often come from a web background, which is a field with little concern for proper resource management and performance. If a webpage has a memory leak, just refresh it. If it takes too much memory, some other inactive tabs will get killed and be refreshed. VS Code is a good example of an Electron application made by people who are concerned by performance. However, developing a performant application using Electron seems to be harder than actually doing it in another language/framework.

Well, you have a choice, so I don't understand the hate.

Okay, maybe you have to use Slack or Discord at work.

Life and engineering are about trade-offs. That people use Electron apps despite the downsides just shows that these apps are delivering value to the world. Value that might not have existed had Electron not made it that much easier for people to get into desktop software.

The complaining on HN reminds me of how my users get mad at me for not spending more of my free time developing the forum software. Like I'm trying to spite them. As if I just need to pull some knobs and levels.

What's happening is that software is getting more and more accessible to people. Beginners are making games in Unity and iOS. Cultural channels into tech like Twitch and cryptocurrencies have been opening up. I watch my cousins' children open up the browser's console to delete annoying DOM nodes.

What I suspect is that more and more people are getting into tech, so there are more and more people for you to disagree with about trade-offs.

You can criticize something even if it does not directly affect you though. For example, I can live with Slack & Skype eating half of my ram but I really wish I would not have to.

I really like Git Kraken, in theory, but if I imagine it as a native app it would be so much better.

I see the appeal of Electron, and to be fair we also use it at work. However our application is destined to be running on a dedicated hardware which runs it and nothing else.

Ultimately I'd like to see products like Slack starting with an Electron app and when the means permit it migrate to a native application. Not the other way around.

If you consider that the browser is where most Electron app users actually begin using the app, you can only expect Electron to be replaced by some native app that runs the same code as the browser. This is the killer feature of Electron.

Having a web app + native app means a huge leap in cost.

Having no web app + native app means a huge loss in user reach.

The only viable replacement would be something like Electron but with a stripped down browser fit to purpose instead of the huge surface-area of Chrome.

The replacement is react native. Same web developer friendly environment with practically native performance. And yes, it’s available for desktop as well as mobile.

Just curious can you give a link to desktop app made with React Native or an example / tutorial for this?

I see a few attempts -

https://github.com/Microsoft/react-native-windows

and http://reactdesktop.js.org/

The Windows one is from Microsoft, but is single platform. Nothing officially supported by react devs as far as I can tell.

I see. Thanks.

>Life and engineering are about trade-offs.

Electron is not a sensible trade off. It is not necessary to accept that level of inefficiency to get that productivity boost. It only has happened that way because our industry has been so web focused for so many years, that very little brain power has gone into cross platform desktop apps for a long time.

And we end up with a ridiculous Frankenstein solution that is fractally wrong. But it is "Easy" because 90% of programmers are used to HTML,CSS,Javascript and so they can suddenly make 'desktop' apps now.

And no, we don't have a choice when almost every desktop application being made now is being made in electron. Its just awful, and you should quit dismissing the people telling you how much they hate the situation, its real.

And of course those of us that hate it should be aiming to help fix the situation, but of course it is difficult, since anything you propose that is not HTML/CSS/Javascript seems alien to so many modern programmers that they reject it out of hand.

Claiming that everyone is worse off because electron apps consume more resources then they would had they been written in a "native" language is only true if the only value you get from an app is low resource consumption.

(I use native in quotation marks because we can probably not even agree on what that is.)

This attitude seems to be common here but everyone hating on electron seems to ignore any positive aspects of it and only focuses on the fact that it is slower and/or more resource intensive then had it been written in <native-language-of-choice>.

You can dislike Electron on a technical or principal level, that's fair, but until there is an alternative that would be considered better by most things will simply not change.

Until then, repeating the negatives over and over again only serves to de-value the efforts of those actually producing and shipping code and the only possible outcome is another "tabs vs spaces" holy war.

As an industry forum for engineers and people developing products, this is a great place to share positive and negative opinions about technology and how it impacts product quality. That’s good conversation.

Generic reactions to negativity, saying there are two sides to every coin, do not really contribute to the discussion, IMO, so I disagree.

> It only has happened that way because our industry has been so web focused for so many years, that very little brain power has gone into cross platform desktop apps for a long time.

While there is an ongoing trend to move towards web apps, I think you are mixing up the causality here a little bit. The main reason why developers are increasingly choosing to move towards web technologies for UI is the sheer pain of doing any kind of cross-platform development on the desktop.

Most of the nice desktop development frameworks (like the ones in C# or Swift) are not cross platform. Meanwhile, we have a decent cross-platform UI framework in Qt, but this requires dealing with C++, which doesn’t even have a good package manager behind it. You could also use GTK+, wxWidgets, FLTK, but these don’t provide a good look and feel and non-Linux OSes.

Basically if you want to easy-to-use cross-platform desktop UI development, your choices boil down to Electron, and maybe pyQt.

Desktop developers have years to make this a better situation by perhaps promoting cross-platform UI standards or building better tooling, but nothing good has really gained much traction, so more developers are justifiably moving to Electron for now.

The reason the causality sounds backwards is the GP is talking about secondary effects of what you are talking about — the other half of a vicious cycle.

We are already a decade into neglecting native app technologies in favor of web app technologies, because web apps were much easier to write and deliver than cross-platform native apps (and largely still are). It’s to the point where even big companies with lots of resources are hiring web programmers and web designers to build their UIs.

It’s interesting to me that mobile changes the trade-offs. The quality gulf between web and native apps is greater. The web sucks more on mobile, and expectations for native apps (animations, touch, etc) are higher. Mobile OSes also make it much easier for users to install and manage native apps than it is on desktop (because of the app store, no custom installers, no users locked out of installing apps by their employers as far as I know). I’m excited about React Native for addressing the cross-platform part.

We’ve learned since Java that even if you don’t have “write once, run anywhere,” you can still have “learn once, write anywhere,” a la React. Also, we expect apps to come with their own systems of UI widgets these days, not necessarily “native look and feel.” It really changes the game.

Java FX is a decent solution as well. It's just not cool.

>You could also use GTK+, wxWidgets, FLTK, but these don’t provide a good look and feel and non-Linux OSes.

Wx is using native widgets on every platform.

It's a sensible trade off when you're a single person needing to deliver a web, Windows, and MacOS application.

turbo pascal ide and compiler are 600KB

at one point I don't care about multilayer super cute guis

btw turbo pascal had shadowed windows in TUI

The sick thing it's a smaller download to write your app in Turbo Pascal and distribute a virtual machine running DOS than an electron app.

And don’t forget Free Pascal and Lazarus. I opened it up the other day on a whim and made a hello world app.

Everything about the thing felt 1990s... in the best way. The IDE was clearly designed not for initial discovery by a novice, but for someone who they ultimately expect to become proficient and thus able to capitalize on the expert-friendly UI.

The reasulting binary felt like the 1990s too: A single small executable with instant load times :-)

If you want to make Electron obsolete, make a cross platform UI toolkit that mixes UI and document-style content as good as HTML/CSS does.

End user expectations are for complex layouts, flexible typography, rich media embedding, animated interactions, and so on. I've yet to see a QT app come close to what e.g. Slack has managed to shoehorn in.

It'd be great if we could get desktop level robustness out of it too, instead of being limited to scrolling three or four screens up before it has to start paging out content.

Web UI is bad in many ways, but many desktop adherents seem willfully oblivious about why there is such a desire for this. The only native OS that has evolved to compete is MacOS, with its multi touch driven interactions genuinely making most web stuff feel like the janky lowest common denominator that it is.

What you want is all available in Qt via QtQuick, where you can use QML to define you interface declaratively (in a better way than html+css) and JS for logic with the option of dropping down to C++ or another language with bindings.

If you think that, you don't understand the nature of what is being done with HTML nowadays. It's not about declarative markup, it's about efficient updating of a UI whose shape is completely decoupled from the shape of the state it is representing.

I'm a professional web developer, I'd like to think I know what I'm doing. And I believe you contradicted yourself, leveraging a Virtual DOM to update the DOM (which has an imperative API) from the changes that exist in two sets of data —both products of (an ideally) pure transformation from high-level data— is very much declarative programming.

Meanwhile QML provides you with the same kind of programming paradigm except that you do not have a DOM, you have the QtQuick Scene Graph which calculates how to render your new state in the most efficient way; and, worth mentioning, in a much more efficient way than a standard browser stack would be able to under regular circumstances.

Reply on news.ycombinator.com