> the desktop/UI sucks, its awful in almost every way, you are essentially targeting X11 which was developed in the 70’s and it shows. It works and it brings a couple of quirky features to the table which are quite nice, but, in essence, if you love Linux, just forget targeting GUI desktop stuff, you need a graphics screen, a browser (for a real UI) and a terminal window – that’s it… there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff…
When would you even want to target X11/Wayland directly? Just use a toolkit and ignore the underlying stuff. For 90% of the application it does not matter.
> I find it difficult to see why this is going to change any time soon, the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases.
I always encounter the exact opposite. I've never found any web application with a good UI or any web application that outperformed a native one.
> Could you imagine a future where desktop applications were built like this, and in every sense of the word, “portable between operating systems” with the experience being identical on all platforms…
This sounds more like a really crappy future, if anything looks everywhere the same. Applications must integrate with the "host"-OS.
The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application.
The lock-in argument is just a very weak one. At some point you depend on something. Oh, your HTML only renders fine in Chromium or you use Chromium only JS APIs - you are locked-in to Chromium now.
>The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application.
Another reason is that it can just run in browser without installing anything and "just click and it starts working" is HUGE feature, especially if you're in corpo where every fucking app needs management/helpdesk approval to be installed
And so we're damned to this miserable existence of using webapps
This is where the rubber meets the road. Show me a native application ecosystem that can go from some blue underline text to fully functional interactive tool with one click and 1s with no prior contact and minimal risk of cross contamination and I'll show you an ecosystem that can win over web technologies. This is the bar that users have chosen. Accept and embrace it or be doomed to be overshadowed by something that meets the bar better.
> I always encounter the exact opposite. I've never found any web application with a good UI or any web application that outperformed a native one.
As an illustrative example, try to find a conversation in microsoft teams (electron app) that's more than a week old by scrolling through the chat history.
We're in a situation where scrolling up a list cannot be implemented without breaking the UI.
I think the difference is about frameworks. Typically desktop application frameworks (Windows Forms, GTK, QT, etc) follow an imperative approach, where you design your UI (maybe with a graphical designer) and attach callbacks to events, than then update the UI elements directly.
Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.
Web frameworks do, but the web platform, i.e. browsers don't. The basic abstraction of browsers is still the DOM, which follows the same basic idea of desktop UI toolkits: A tree of elements which you can modify imperatively, combined with event handlers. Only, it's far less sophisticated than the data models of UI toolkits and still optimized for the web's original use case, which were text documents.
A lot of the bloat and complexity of web frameworks comes from the issue that they basically have to implement a modern, functional UI toolkit on top of an ancient, imperative one.
Typically desktop application frameworks (Windows Forms, GTK, QT, etc) follow an imperative approach, where you design your UI (maybe with a graphical designer) and attach callbacks to events, than then update the UI elements directly
Unbelievably so, DOM also follows that. It’s apples to oranges comparison, because you could use React, Vue and other wrappers with Gtk, Qt and other runtimes, because it’s the same exact model as DOM, literally.
DOM only lacks collections/datasources, because it originated from a non-programmatic format which required every collection element to be fully described from scratch. This nuance caused around 50% of clusterfuck that web experienced for last 20 years. The other 50% was an inability (or reluctance) to support custom reflow hooks.
> the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically
Hum... Yeah. Except when the view is not actually pure, or when the framework can't decide, and decides to handle everything like if it isn't pure. Or when the state depends on the view. Or when some of the view depends on data from other part of it. Or when there is server data to synchronize...
But yeah, when you smooth out the movement, UI is evolving towards something nice. It's just annoying when people claim it's there already. It's not, there are plenty of problems.
I'd like to request a specific example. Functional can be really tricky to debug if not done well, so I'm skeptical that functional is a "magic fix". For the vast majority of office CRUD [1], the way Visual Basic (classic) did things was KISS and intuitive: you filled in the event snippet and didn't have to worry about the deeper guts of the GUI system. One should only have to fiddle with guts for special needs.
[1] Ignoring web-scale and "enterprise". I don't think it's possible to optimize a stack for smaller/middle end and larger end at the same time. One end has to take a hit.
> Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.
Exactly! The React pattern is incredibly intuitive, to the point where even google implemented something similar with JetPack Compose for native android apps. The only thing I dislike about Compose is the actual state management and a few quirks, but in general, I'd love to see more native UI solutions to adopt this.
VS Code is definitely the best performing Electron app I've ever used, but as someone who daily drives Sublime Text, it's clear how much better the native app written in C++ (Sublime) performs.
VS Code for me is the exception that proves the rule.
Its great and in most ways feels like a native app, but this is a very different experience than every other Electron app I use which all tend to leak significant amounts of memory over time (VS Code does this too but to a lesser degree), lock up in weird ways (task still running in task manager but any attempt to invoke a new UI window results in nothing happening until I go and manually kill all the zombie tasks running in the bg), etc.
It's much closer to Sublime Text (or maybe Notepad++ if you slapped a plugin-browser on it) than to a "real" IDE. It's not snappier or lighter-weight than Sublime.
By offering a subset of their capabilities, with key features implemented in a multi-process architecture, using plenty of C++ and Rust written modules.
Additionally the terminal has to use WebGL to achieve usable performance.
Although I agree, VS Code also uses excessive amount of RAM. More than any IDE I've used in the past. Still, I use it because it's the best free option.
> The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application.
HTML, CSS, and JavaScript are the lowest common denominator of all modern desktops.
It's just another toolset in a long series that started with teletype control codes, and went on to curses, Motif, Java's AWT, and so on...
To develop windows desktop app you have to pay MS tax. To develop Apple desktop or iOS app you have to pay Apple tax. To develop Android app you pay Google tax. You could develop Linux desktop app but you are not going to make people pay for it because people will expect that it will be free - because Linux….
You make web app that runs on only free GUI standards that in reality exist and you are free and don’t have to pay anyone anything. Your business is not tied to App Store or whims of a corporation.
> To develop windows desktop app you have to pay MS tax.
No, making windows desktop apps is free. Microsoft even has a free IDE, with a caveat that it's only usable by independent developers, or small businesses.
One of the problems is ALL of the toolkits suck. Just try creating a Qt5 application in Python, it's a royal pain in the ass compared to HTML+CSS, especially if you want to get things aligned in a certain way, e.g. having an widget always be the window height minus a certain fixed number of points, or 33% of the width minus 20 points, or something of that sort.
Native widgets are also just design-wise ages behind web widgets. Rounded corners and a slight blurred drop shadow? Forget it.
> if you want to get things aligned in a certain way
I want things to align as the native GUI does. I don't want apps that break my assumptions about what the UI should be and how buttons should present and where they should be.
Then, if the app is running on a different platform, it's reasonable for the users to expect it to adhere to their own UI conventions.
This is why a lot of toolkits will restrict the way you shape your UI elements - they are the layer that imposes consistency.
Have done some Qt5 development, can confirm. Qt is nowhere as expressive and flexible as the web stack. Not to mention the ecosystem, license etc.
Most people trashing JavaScript, Electron or web stack have never done cross-platform desktop application development and they will never understand how much worse other stack can be.
XAML toolkits on Windows have the same issue -- styling stuff is an esoteric nightmare compared to HTML/CSS. And HTML/CSS is hardly the easiest way to do stuff and yet it's still better than what most desktop toolkits give us.
"I always encounter the exact opposite. I've never found any web application with a good UI or any web application that outperformed a native one."
Consumers disagree. Almost every application is running chromium now and they couldn't be happier that it just works. It's great on Linux too.
"The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application"
You will have to write an electron application before commenting. Native UI's cannot be universal UI's, it breaks user experience, causes more bugs and looks terrible. I want my system menu to have a system UI. I do not want my user applications to look like the system.
Times are already changed, native is dead, long live the chromium desktop.
> Consumers disagree. Almost every application is running chromium now and they couldn't be happier that it just works. It's great on Linux too.
consumers don't make that choice. developers choose electron because it is the only cross-platform target where almost all the cross-platform fiddly bits are handled for you. there are lots of cross-platform approaches where the fiddly bits are not handled out of the box, and those are all little more than background noise compared to electron.
consumers neither know nor care how the app they use is implemented. they care only about which devices the app is available on.
now to be clear, electron fucking sucks as a user of applications. it is dog slow and awful on RAM, and the billions of devices running electron apps definitely contribute to global warming far more than native apps would, but developers think that the One True Language is JavaScript and that the One True Platform is the browser, and well, cults are immune to logic.
As a former desktop developer, the reason is obvious to me. You have to be insane to deliberately choose a career as a specific platform desktop developer nowadays.
Native desktop apps are:
1. much harder to develop
2. they are way more limiting in terms how things should be done
3. are implemented completely different on each platform.
It will take years to become proficient app developer on a single platform.
And compare that to Electron:
- you instantly have access to a huge, very dynamic community with tons of documentation.
- web standards are battle tested and improve every year
- your knowledge does not invalidate when developing for different platform (or when your UI framework just gets randomly abandoned: I'm looking at you Microsoft)
- a lot of pain points solved much better for web that for standard UI libraries
- you can apply your knowledge to web front-end development as well
Enough said. Of course. Everybody with half a brain understands that. I switched from Swift to TypeScript because of that for over a year now. There are things about Swift I love, and things about TypeScript/JavaScript I don't, but I can invest into bending TypeScript/JavaScript to my needs, and I can use it everywhere. EVERYWHERE. Also, I freaking love VSCode. Took a while, at first I didn't see it, but after coding TypeScript with it for a year, and now having developed my first extension for VSCode, I must say, this software is a gem. And so much simpler and cleaner than bloated monsters like IntelliJ.
Balderdash! Tools like Delphi/Lazarus, Visual Basic, Clarion, PowerBuilder made it snap. Sure, they may not be "enterprise" or for writing word processors, but for everyday CRUD they are far simpler than typical web stacks. I lived it and did it.
Everyone thinks tools that don't scale (team size or performance) should be dumped, but doing things well at the smaller end is a good thing. One size rarely fits all well.
> are implemented completely different on each platform.
Lazarus can do Windows, Mac, and Linux. But I'd really like to see a state-ful GUI markup standard so apps could send text (HTTP) gui commands/XML instead of tie them to binary libraries.
> they are way more limiting in terms how things should be done
"Should be"? Biz wants practical over time-drain-idealistic. Too much should-be is a YAGNI violation.
> web standards are battle tested and improve every year
Any commonly used standard has that benefit. And web standards are a poor fit for GUI/desktop/CRUD. You'd have to break backward compatibility to solve that because DOM is inherently flawed for that need.
SDL doesn't really give you a GUI like having a flour doesn't give you a cake. A great place to build off of but by the time you make a GUI out of it you're back to the above list. Realistically you'd probably be better off just starting with a full cross platform GUI framework like Qt but that doesn't make things necessarily easier it just means you can focus on making your app work instead of making a GUI framework for your app so it can work.
You can, but the nice widgets don't materialize out of thin air, nor will they gain the accessibility support that a browser or an operating system provides.
Teams, an electron app, uses 600+ MB of RAM.
Slack, another electron app, uses 250+ MB of RAM.
Outlook (not electron) 180 MB of RAM. (Still a pig)
PowerPoint (not electron) 70 MB.
Excel (not electron) 25 MB.
Gnu Emacs: 3 MB.
Adobe Photoshop: 50 +/- MB.
A simple windows SDK program (all C) 1.4 MB.
A tiny windows SDK program, all C: 0.5 MB of RAM
This is just RAM usage. For CPU load and overall performance the native apps win. Emacs startup time blows away VS code.
The question is valid. Why do we create modern desktop apps using HTML/CSS/JS?
I have a pretty old desktop (so due for an upgrade) and VSCode starts up fast enough that I don't think about it. I'm sure Emacs starts up faster but would I even notice?
Note that while electron is pretty bad in that regard, it’s just that way because the entire chromium runtime ships with it. A leaner alternative could exist
Apps built 30 years ago use less RAM because they had less RAM available: 16MB (1993) vs 16GB (2023). Back then, PowerPoint & other apps were considered to be the bloated apps.
Worth considering: how often do you actually use those old apps?
Still Teams and Slack are roughly doing what IRC does. Just using infinitely more resources.
Modern tech stack makes it cheaper to produce software, in a world where consumer don't give a shit and happily buy new hardware to run the worse software.
> the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases
This definitely needs evidence to back it up since my personal experience (and apparently from reading the comments, others as well) is the opposite.
Just be honest: the primary reason by far for the preference for GUIs using web tech over native is economics. One code base, multiple platforms. Native requires nontrivial per-target specialized code, which is expensive to develop and maintain. Web tech has given us the closest I can see to what Java promised but failed to adequately deliver: write once, run everywhere.
I would guess there’s a secondary reason: the tech world has an excess of web tech developers running around, and they tend to use what they know - for better or worse.
> I would guess there’s a secondary reason: the tech world has an excess of web tech developers running around, and they tend to use what they know - for better or worse.
It's more about how users are affected by cost/performance tradeoffs.
It costs less to make a web app than to make a native one on most platforms. The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms.
For users, it turns into "will you take 20% worse performance for 500% lower costs?"
Most users will take that deal any day of the week.
The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms.
I can never figure out where this idea comes from. Do javascript programmers not know about GUI libraries like Qt, FLTK, Juce, or that there are a huge number of cross platform libraries for C++ ?
For users, it turns into "will you take 20% worse performance for 500% lower costs?"
I think you mean running at 1/20th - 1/200th the speed of a native program and 10%-15% more time spent compiling and testing for each alternate platform. My experience is that it is mostly correcting errors that come from a different compiler. Almost every bit of C++ stays the same.
You fixated on what I said was the secondary reason, and repeated in a rephrased way what I said was the primary reason - economics/cost.
Given that users rarely get to make the choice, I’m not sure we have evidence saying people actually are happy with the sacrifice. I do know people complain a lot about battery life, laggy apps, and unpredictable behavior that often can be traced down to the technologies used to implement them. The problem is, your average user doesn’t actually know that’s the case, and doesn’t even realize that alternatives are even an option. People like me and the audience on HN are the outliers : most people have no clue what’s going on under their bank app, corporate app, ticket app, etc…
If application A costs $300 user/year and application B $60 user/year, then a 5% performance loss from using application B could easily cost a company $1200 employee/year.
I think the clue is in the article, he worked on some badly designed legacy app....which he blames on the language / tech stack. I see this a lot across many tech stacks, people create some monster, but critical, application and then blame their woes on the tech stack :)
Because Web Standards are Portable and Accessible.
You can recreate the accessible GUI widget tree universe in ASM or WASM, but it probably won't be as accessible as standard HTML form elements unless you spend more time than you have for that component on it.
For example, video game devs tend to do this: their very own text widget (and hopefully a ui scaling factor) with a backgroundColor attribute - instead of CSS's background-color - and then it doesn't support tabindex or screen readers or high contrast mode or font scaling.
It's a widget tree with events either way, but Web Standards are Portable and Accessible (with a comparative performance cost that's probably with it)
> Because Web Standards are Portable and Accessible.
A good http-friendly GUI standard would be also (as I describe nearby). But do note that businesses still use mostly desktops for everyday CRUD and don't want to pay a large "mobile tax" if given a choice. YAGNI has been ignored, as the standards over-focused on social media and e-commerce at the expense of typical CRUD. CRUD ain't sexy but necessary and common.
It's not easy to do both desktop and mobile UI's well and inexpensively in one shot. I believe there are either inherent trade-offs between them, or that the grand unification UI framework has yet to be invented. (At least one that doesn't require UI rocket science.)
Mobile-first development says develop the mobile app first and teh desktop version can get special features later; one responsive layout for Phone, Tablet, and desktop
Phosh (GTK) and KDE Plasma Mobile are alternatives to iOS and Android (which do have a terminal, bash, git, and a way to install CPython (w/ MambaForge ARM64 packages) and IPython)
>the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases
This guy needs to come up with a list of those well written UIs, because every single one I know is noticeably worse than native apps. I work with a Ryzen 9 5950X (16 cores)/64GB RAM, and the slack application (which I only use because of work) lags for common UI operations like switching channels. This is an application that consists in...displaying some lines of text with small icon images, plus the occasional youtube thumbnail. A 27$ billion company can't apparently make an electron app that displays text performant.
I use two bank apps in my phone. Both use web UIs underneath. Both are incredibly slow. I have also been unable to complete some operation in both of them at some point because I hit UI bugs and wasn't able to continue - something moved and I wasn't able to move or tap into whatever allowed me to continue. Given that apps are the only way I interact with banks these days, I'm seriously considering searching for a bank that does have a native app. I would love to be the client of a company that cares more about customers than about having more than one codebase.
Web browsers aren't even good at doing web applications. And unfortunately, web makers seem to have (IMO) lost interest in addressing the core problems of browsers. Instead they focus in wasm (because reinventing Java is somehow revolutionary), adding even more HTML5 popups, and not wondering why web pages bother users with weekly newsletters JS popups (that's what RSS was invented for, but apparently we should forget about it).
Why do we create modern Desktop GUIs using web technologies? Apart from the benefit of a single codebase, it's largely because widget based UIs aren't as good at designing complex layouts as web browsers are. That's the strong point of browsers (also, people decided at some point that having an unified style for all UIs that you use is boring).
A lot of people keep treating web browsers as some kind of cool, new technology. These people need to wake up. Web browsers are actually a bloated, horrible dinosaur that sucks in too many ways and we only use because there is nothing better (someone described it once as the MS-DOS of our days). And browser makers are fighting hard to bloat it even more to cover corner cases that only a minority cares about, while having normal, fast UIs remains a privilege that is only affordable by Silicon Valley companies. I really hope at some point we can stop using HTML/CSS/Javascript not just for desktop apps, but also for "remote" web apps.
What this guy needs to do is gain some perspective, travel back in time and notice how responsive native Windows 98 / Windows XP style GUIs were (when the system wasn't crashing), and then compare snappiness of a full fledged video editor, or word processor, or photoshop-style app of the time, with the typical slugginess of the average note taking or text chat app of nowadays.
But new people get born every day, and they won't get to know what was possible in terms of low latencies compared to web-based UIs (not saying this particular author is very young, I have no idea, but clearly somehow they are not considering the full picture to realize how bad modern UIs are)
I can't quite tell what point you're trying to make.
Because fully-fledged apps on Win98/XP were horribly slow compared to today. Loading Photoshop took a couple minutes, while today it takes a few seconds. Just regular user interface dialogs in Word sometimes took noticeable time to display. The main factor of course was spinning hard drive speeds, and swapping memory or loading code pages from disk.
While note taking and chat apps today are pretty instantaneous. The UX latency of software running on my M1 MacBook is faster than any other computer I've had over the past 30 years.
Sometimes when people talk about how XP was fast, I can only imagine they're running it in a VM on modern hardware. Because sure, in that situation it's blazing.
One point that came with the web stack is the entire "We won't optimize for anything, we just want to release quickly. Disk space is cheap, unused RAM is wasted RAM, every PC has at least 8 cores" (Maybe a bit hyperbolic, but still somewhat right imo) And this is something that has to be reverted. Sure I don't expect every application to just use C/C++/Rust with carefully hand-optimized algorithms like back then when the C compilers were not that good at optimizing, but at least I would expect applications to be aware of weak hardware
Perhaps they could even start to realise that using their application isn't the entire purpose of your life and you might also want to run other stuff as well.
Have you ever even tried any of the alternatives? I've scoured the landscape: Gio, egui, Iced, Xilem, imgui, Bevy UI, Qt, makerpad, all of them. Some interesting ideas and promising implementation but literally nothing even comes close to the productivity of a good js stack. Need cross-platform, embed video/youtube, embed (google)maps, custom design language, accessibility, you name it js is the only option here. I'd love to have something else but option just isn't there.
Agree on the topic of performance. Try joining the OpenAI discord channel and you'll see Discord slowly die and become unresponsive. Or VS Code being unable to read a 100 MB file. Or Teams slowly lagging out of existence when you open a large OneDrive folder inside it.
Just about any Electron app I know of can't do large tasks of any kind. The web platform is not built for this kind of work.
> The web platform is not built for this kind of work.
It requires clever tricks we learned in the 80's.
You can't keep the whole state of the application in a puny 64K of memory. With luck, you can keep about 30K of it, provided the app is small enough. What you need to do is to just load what you need to display, and get rid of the rest as it fills up the memory.
Most of the time an application built using web technologies is slow, it's not because the web's UI layer (HTML/CSS) is intrinsically slow.
A desktop app written in Tauri that punts most of the heavy data processing to Rust with a UI layer written in well-optimized React or Solid.js is really plenty fast. In practice what we get with most Electron apps is not especially well written React with frequent coarse grained re-renders, inefficient data processing, frequent allocations causing GC pressure, and excessive JSON RPC. The problems here aren't HTML/CSS + JS for basic event handling, it's everything else about how the software is developed.
I don't think HTML/CSS are all that good at making fancy layouts and designs. I find it quite common to have to fight my browser to get it to display things the way I want. CSS in particular in particular keeps massively growing because people come up with so much stuff that CSS can't really do.
What makes the browser a great platform to develop complex designs is the development experience. Browsers have by far the best dev tools of any platform and most modern frameworks come with instant hot reload.
It doesn't hurt that web apps are build with the same tech as websites either. Lot's of synergies.
> >the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases
> This guy needs to come up with a list of those well written UIs, because every single one I know is noticeably worse than native apps.
I don't know the OP's context, but I have to agree with you. In no reality that I've been in has this been true.
VSCode (Electron) is faster than most native desktop IDEs.
Easy enough to disprove those that say browser based apps are inherently slow. Modern JS is significantly more optimized and faster than most other loosely typed runtimes, e.g python.
WebGPU will just close the gap further.
Anyway you can write highly optimized native code and deploy to browser via WASM anyway. No reason at all to deal with OS quirks. WASM compilation will get better and better over time
And yet every few days I look at my running processes to see what's chewing up all the memory and CPU and it's either VSCode or Slack. Kill them all and restart with all the same windows open and everything goes back to fine. I don't consider this good performance. (Note: I have never experienced this with IntelliJ)
I have to wonder if I'm missing something or not understanding something. I keep seeing "WebGPU will fix it!" as a response to criticism of using HTML5 technology, but to me, using 3D rendering technology to make UI elements more responsive feels a bit like using a rocket launcher to take out a fly?
Fine, but VSCode is not an IDE. Compare VSCode with a (native) text editor. Or VSCode plus all the required plugins to match the (maybe unneeded) functionality of a regular IDE.
Indeed a terrible font choice, while the writing could also do with a second pass.
A comment on Wayland stood out, namely that it's
> barley supported
I'm still unclear whether that's a typo, or a snide remark :)
On TFA's TL;DR on the "why", though, I'd mostly agree: we have HTML/CSS/JS as desktop UI, because having a single to track is better than having to support at least three (Win, Mac, X11) GUI frameworks. It's the least bad option, even if that means that the underlying OS just becomes a facilitator for Electron.
What depresses me is that Electron is essentially the new Emacs, and JS the new Lisp.
That Wayland remark is very weird.It probably comes from an echo chamber or someone who hasn't actually tried it/done some proper research. Or maybe they only use a DE that barely supports it? (which? XFCE?)
There was a sudden explosion of client platforms in the mid-2000's and the existing solutions for cross-platform UI were expensive and slow-to-modernize (QT), poorly suited to applications (game engines), or outright murdered (Flash).
But HTML/CSS/JS SPA's were becoming a mature application platform in browsers during that same time, and brought with it a huge generation of new developers that learned on those technologies first. When demand swung back to desktop apps, they brought their tech stack with them.
You can make arguments for whatever technical merits you want, but they're all just differences seen in hindsight. It was mostly just a de facto win.
Readit News
When would you even want to target X11/Wayland directly? Just use a toolkit and ignore the underlying stuff. For 90% of the application it does not matter.
> I find it difficult to see why this is going to change any time soon, the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases.
I always encounter the exact opposite. I've never found any web application with a good UI or any web application that outperformed a native one.
> Could you imagine a future where desktop applications were built like this, and in every sense of the word, “portable between operating systems” with the experience being identical on all platforms…
This sounds more like a really crappy future, if anything looks everywhere the same. Applications must integrate with the "host"-OS.
The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application.
The lock-in argument is just a very weak one. At some point you depend on something. Oh, your HTML only renders fine in Chromium or you use Chromium only JS APIs - you are locked-in to Chromium now.
Another reason is that it can just run in browser without installing anything and "just click and it starts working" is HUGE feature, especially if you're in corpo where every fucking app needs management/helpdesk approval to be installed
And so we're damned to this miserable existence of using webapps
As an illustrative example, try to find a conversation in microsoft teams (electron app) that's more than a week old by scrolling through the chat history.
We're in a situation where scrolling up a list cannot be implemented without breaking the UI.
Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.
A lot of the bloat and complexity of web frameworks comes from the issue that they basically have to implement a modern, functional UI toolkit on top of an ancient, imperative one.
Unbelievably so, DOM also follows that. It’s apples to oranges comparison, because you could use React, Vue and other wrappers with Gtk, Qt and other runtimes, because it’s the same exact model as DOM, literally.
DOM only lacks collections/datasources, because it originated from a non-programmatic format which required every collection element to be fully described from scratch. This nuance caused around 50% of clusterfuck that web experienced for last 20 years. The other 50% was an inability (or reluctance) to support custom reflow hooks.
Hum... Yeah. Except when the view is not actually pure, or when the framework can't decide, and decides to handle everything like if it isn't pure. Or when the state depends on the view. Or when some of the view depends on data from other part of it. Or when there is server data to synchronize...
But yeah, when you smooth out the movement, UI is evolving towards something nice. It's just annoying when people claim it's there already. It's not, there are plenty of problems.
Anyway, desktop frameworks are moving too.
[1] Ignoring web-scale and "enterprise". I don't think it's possible to optimize a stack for smaller/middle end and larger end at the same time. One end has to take a hit.
Exactly! The React pattern is incredibly intuitive, to the point where even google implemented something similar with JetPack Compose for native android apps. The only thing I dislike about Compose is the actual state management and a few quirks, but in general, I'd love to see more native UI solutions to adopt this.
or is it that there are less bootcamps teaching OS native app UI development as there are JS front end library usage?
I would love to see the equivalent of the MDN but for AppKit, but alas
Deleted Comment
VS Code seems to outperform all the other IDEs I've used in the past
Its great and in most ways feels like a native app, but this is a very different experience than every other Electron app I use which all tend to leak significant amounts of memory over time (VS Code does this too but to a lesser degree), lock up in weird ways (task still running in task manager but any attempt to invoke a new UI window results in nothing happening until I go and manually kill all the zombie tasks running in the bg), etc.
Additionally the terminal has to use WebGL to achieve usable performance.
HTML, CSS, and JavaScript are the lowest common denominator of all modern desktops.
It's just another toolset in a long series that started with teletype control codes, and went on to curses, Motif, Java's AWT, and so on...
To develop windows desktop app you have to pay MS tax. To develop Apple desktop or iOS app you have to pay Apple tax. To develop Android app you pay Google tax. You could develop Linux desktop app but you are not going to make people pay for it because people will expect that it will be free - because Linux….
You make web app that runs on only free GUI standards that in reality exist and you are free and don’t have to pay anyone anything. Your business is not tied to App Store or whims of a corporation.
No, making windows desktop apps is free. Microsoft even has a free IDE, with a caveat that it's only usable by independent developers, or small businesses.
Deleted Comment
Native widgets are also just design-wise ages behind web widgets. Rounded corners and a slight blurred drop shadow? Forget it.
I want things to align as the native GUI does. I don't want apps that break my assumptions about what the UI should be and how buttons should present and where they should be.
Then, if the app is running on a different platform, it's reasonable for the users to expect it to adhere to their own UI conventions.
This is why a lot of toolkits will restrict the way you shape your UI elements - they are the layer that imposes consistency.
Most people trashing JavaScript, Electron or web stack have never done cross-platform desktop application development and they will never understand how much worse other stack can be.
Consumers disagree. Almost every application is running chromium now and they couldn't be happier that it just works. It's great on Linux too.
"The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application"
You will have to write an electron application before commenting. Native UI's cannot be universal UI's, it breaks user experience, causes more bugs and looks terrible. I want my system menu to have a system UI. I do not want my user applications to look like the system.
Times are already changed, native is dead, long live the chromium desktop.
consumers don't make that choice. developers choose electron because it is the only cross-platform target where almost all the cross-platform fiddly bits are handled for you. there are lots of cross-platform approaches where the fiddly bits are not handled out of the box, and those are all little more than background noise compared to electron.
consumers neither know nor care how the app they use is implemented. they care only about which devices the app is available on.
now to be clear, electron fucking sucks as a user of applications. it is dog slow and awful on RAM, and the billions of devices running electron apps definitely contribute to global warming far more than native apps would, but developers think that the One True Language is JavaScript and that the One True Platform is the browser, and well, cults are immune to logic.
Native desktop apps are:
1. much harder to develop
2. they are way more limiting in terms how things should be done
3. are implemented completely different on each platform.
It will take years to become proficient app developer on a single platform.
And compare that to Electron:
- you instantly have access to a huge, very dynamic community with tons of documentation.
- web standards are battle tested and improve every year
- your knowledge does not invalidate when developing for different platform (or when your UI framework just gets randomly abandoned: I'm looking at you Microsoft)
- a lot of pain points solved much better for web that for standard UI libraries
- you can apply your knowledge to web front-end development as well
Balderdash! Tools like Delphi/Lazarus, Visual Basic, Clarion, PowerBuilder made it snap. Sure, they may not be "enterprise" or for writing word processors, but for everyday CRUD they are far simpler than typical web stacks. I lived it and did it.
Everyone thinks tools that don't scale (team size or performance) should be dumped, but doing things well at the smaller end is a good thing. One size rarely fits all well.
> are implemented completely different on each platform.
Lazarus can do Windows, Mac, and Linux. But I'd really like to see a state-ful GUI markup standard so apps could send text (HTTP) gui commands/XML instead of tie them to binary libraries.
> they are way more limiting in terms how things should be done
"Should be"? Biz wants practical over time-drain-idealistic. Too much should-be is a YAGNI violation.
> web standards are battle tested and improve every year
Any commonly used standard has that benefit. And web standards are a poor fit for GUI/desktop/CRUD. You'd have to break backward compatibility to solve that because DOM is inherently flawed for that need.
I'm tempted to question the intelligence of Microsoft managers when I look at their desktop GUI strategy over the last 20 years
Teams, an electron app, uses 600+ MB of RAM. Slack, another electron app, uses 250+ MB of RAM. Outlook (not electron) 180 MB of RAM. (Still a pig) PowerPoint (not electron) 70 MB. Excel (not electron) 25 MB. Gnu Emacs: 3 MB. Adobe Photoshop: 50 +/- MB. A simple windows SDK program (all C) 1.4 MB. A tiny windows SDK program, all C: 0.5 MB of RAM
This is just RAM usage. For CPU load and overall performance the native apps win. Emacs startup time blows away VS code.
The question is valid. Why do we create modern desktop apps using HTML/CSS/JS?
Electron apps are only good if you sell hardware.
I have a pretty old desktop (so due for an upgrade) and VSCode starts up fast enough that I don't think about it. I'm sure Emacs starts up faster but would I even notice?
Nah. Spacemacs take 5-10 secs to load on my PC, vs a fraction of a second for VS Code.
It's faster on Linux, but I run Windows out of necessity.
Deleted Comment
Worth considering: how often do you actually use those old apps?
Modern tech stack makes it cheaper to produce software, in a world where consumer don't give a shit and happily buy new hardware to run the worse software.
This definitely needs evidence to back it up since my personal experience (and apparently from reading the comments, others as well) is the opposite.
Just be honest: the primary reason by far for the preference for GUIs using web tech over native is economics. One code base, multiple platforms. Native requires nontrivial per-target specialized code, which is expensive to develop and maintain. Web tech has given us the closest I can see to what Java promised but failed to adequately deliver: write once, run everywhere.
I would guess there’s a secondary reason: the tech world has an excess of web tech developers running around, and they tend to use what they know - for better or worse.
It's more about how users are affected by cost/performance tradeoffs.
It costs less to make a web app than to make a native one on most platforms. The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms.
For users, it turns into "will you take 20% worse performance for 500% lower costs?"
Most users will take that deal any day of the week.
I can never figure out where this idea comes from. Do javascript programmers not know about GUI libraries like Qt, FLTK, Juce, or that there are a huge number of cross platform libraries for C++ ?
For users, it turns into "will you take 20% worse performance for 500% lower costs?"
I think you mean running at 1/20th - 1/200th the speed of a native program and 10%-15% more time spent compiling and testing for each alternate platform. My experience is that it is mostly correcting errors that come from a different compiler. Almost every bit of C++ stays the same.
Given that users rarely get to make the choice, I’m not sure we have evidence saying people actually are happy with the sacrifice. I do know people complain a lot about battery life, laggy apps, and unpredictable behavior that often can be traced down to the technologies used to implement them. The problem is, your average user doesn’t actually know that’s the case, and doesn’t even realize that alternatives are even an option. People like me and the audience on HN are the outliers : most people have no clue what’s going on under their bank app, corporate app, ticket app, etc…
Though I may be misunderstanding your point.
You can recreate the accessible GUI widget tree universe in ASM or WASM, but it probably won't be as accessible as standard HTML form elements unless you spend more time than you have for that component on it.
For example, video game devs tend to do this: their very own text widget (and hopefully a ui scaling factor) with a backgroundColor attribute - instead of CSS's background-color - and then it doesn't support tabindex or screen readers or high contrast mode or font scaling.
It's a widget tree with events either way, but Web Standards are Portable and Accessible (with a comparative performance cost that's probably with it)
A good http-friendly GUI standard would be also (as I describe nearby). But do note that businesses still use mostly desktops for everyday CRUD and don't want to pay a large "mobile tax" if given a choice. YAGNI has been ignored, as the standards over-focused on social media and e-commerce at the expense of typical CRUD. CRUD ain't sexy but necessary and common.
It's not easy to do both desktop and mobile UI's well and inexpensively in one shot. I believe there are either inherent trade-offs between them, or that the grand unification UI framework has yet to be invented. (At least one that doesn't require UI rocket science.)
/? flutter python ... TIL about flet: https://github.com/flet-dev/flet https://flet.dev/docs/guides/python/getting-started
Mobile-first development says develop the mobile app first and teh desktop version can get special features later; one responsive layout for Phone, Tablet, and desktop
Phosh (GTK) and KDE Plasma Mobile are alternatives to iOS and Android (which do have a terminal, bash, git, and a way to install CPython (w/ MambaForge ARM64 packages) and IPython)
Web standards is only real implementation of GUI that is not proprietary.
Making a web app you don’t have to pay MS/Apple/Google tax.
QT is also proprietary and you have to pay them quite a lot.
This guy needs to come up with a list of those well written UIs, because every single one I know is noticeably worse than native apps. I work with a Ryzen 9 5950X (16 cores)/64GB RAM, and the slack application (which I only use because of work) lags for common UI operations like switching channels. This is an application that consists in...displaying some lines of text with small icon images, plus the occasional youtube thumbnail. A 27$ billion company can't apparently make an electron app that displays text performant.
I use two bank apps in my phone. Both use web UIs underneath. Both are incredibly slow. I have also been unable to complete some operation in both of them at some point because I hit UI bugs and wasn't able to continue - something moved and I wasn't able to move or tap into whatever allowed me to continue. Given that apps are the only way I interact with banks these days, I'm seriously considering searching for a bank that does have a native app. I would love to be the client of a company that cares more about customers than about having more than one codebase.
Web browsers aren't even good at doing web applications. And unfortunately, web makers seem to have (IMO) lost interest in addressing the core problems of browsers. Instead they focus in wasm (because reinventing Java is somehow revolutionary), adding even more HTML5 popups, and not wondering why web pages bother users with weekly newsletters JS popups (that's what RSS was invented for, but apparently we should forget about it).
Why do we create modern Desktop GUIs using web technologies? Apart from the benefit of a single codebase, it's largely because widget based UIs aren't as good at designing complex layouts as web browsers are. That's the strong point of browsers (also, people decided at some point that having an unified style for all UIs that you use is boring).
A lot of people keep treating web browsers as some kind of cool, new technology. These people need to wake up. Web browsers are actually a bloated, horrible dinosaur that sucks in too many ways and we only use because there is nothing better (someone described it once as the MS-DOS of our days). And browser makers are fighting hard to bloat it even more to cover corner cases that only a minority cares about, while having normal, fast UIs remains a privilege that is only affordable by Silicon Valley companies. I really hope at some point we can stop using HTML/CSS/Javascript not just for desktop apps, but also for "remote" web apps.
But new people get born every day, and they won't get to know what was possible in terms of low latencies compared to web-based UIs (not saying this particular author is very young, I have no idea, but clearly somehow they are not considering the full picture to realize how bad modern UIs are)
Because fully-fledged apps on Win98/XP were horribly slow compared to today. Loading Photoshop took a couple minutes, while today it takes a few seconds. Just regular user interface dialogs in Word sometimes took noticeable time to display. The main factor of course was spinning hard drive speeds, and swapping memory or loading code pages from disk.
While note taking and chat apps today are pretty instantaneous. The UX latency of software running on my M1 MacBook is faster than any other computer I've had over the past 30 years.
Sometimes when people talk about how XP was fast, I can only imagine they're running it in a VM on modern hardware. Because sure, in that situation it's blazing.
Apparently not. You'd think the author would clearly recall the scenario you described.
Just about any Electron app I know of can't do large tasks of any kind. The web platform is not built for this kind of work.
It requires clever tricks we learned in the 80's.
You can't keep the whole state of the application in a puny 64K of memory. With luck, you can keep about 30K of it, provided the app is small enough. What you need to do is to just load what you need to display, and get rid of the rest as it fills up the memory.
And beware of JavaScript arrays - they are a lie.
A desktop app written in Tauri that punts most of the heavy data processing to Rust with a UI layer written in well-optimized React or Solid.js is really plenty fast. In practice what we get with most Electron apps is not especially well written React with frequent coarse grained re-renders, inefficient data processing, frequent allocations causing GC pressure, and excessive JSON RPC. The problems here aren't HTML/CSS + JS for basic event handling, it's everything else about how the software is developed.
> This guy needs to come up with a list of those well written UIs, because every single one I know is noticeably worse than native apps.
I don't know the OP's context, but I have to agree with you. In no reality that I've been in has this been true.
Could it be he's confusing electron with native?
Easy enough to disprove those that say browser based apps are inherently slow. Modern JS is significantly more optimized and faster than most other loosely typed runtimes, e.g python.
WebGPU will just close the gap further.
Anyway you can write highly optimized native code and deploy to browser via WASM anyway. No reason at all to deal with OS quirks. WASM compilation will get better and better over time
Hardly reducing any gap.
Unrelated, I sure am glad I can turn off CSS in my browser because that font was terrible on the eyes.
A comment on Wayland stood out, namely that it's
> barley supported
I'm still unclear whether that's a typo, or a snide remark :)
On TFA's TL;DR on the "why", though, I'd mostly agree: we have HTML/CSS/JS as desktop UI, because having a single to track is better than having to support at least three (Win, Mac, X11) GUI frameworks. It's the least bad option, even if that means that the underlying OS just becomes a facilitator for Electron.
What depresses me is that Electron is essentially the new Emacs, and JS the new Lisp.
There was a sudden explosion of client platforms in the mid-2000's and the existing solutions for cross-platform UI were expensive and slow-to-modernize (QT), poorly suited to applications (game engines), or outright murdered (Flash).
But HTML/CSS/JS SPA's were becoming a mature application platform in browsers during that same time, and brought with it a huge generation of new developers that learned on those technologies first. When demand swung back to desktop apps, they brought their tech stack with them.
You can make arguments for whatever technical merits you want, but they're all just differences seen in hindsight. It was mostly just a de facto win.