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?)
I get the feeling that we're all just touching different ends of the elephant (https://en.wikipedia.org/wiki/Blind_men_and_an_elephant). If you want to use applications that involve keyboard/mouse sharing, for example, the wayland stuff is very beta/experimental if it's there at all. It's not just DEs.
Thanks for the metaphor, I had forgotten about it. I'm of course biased myself, having started to use sway as my main "DE" in 2018. Sway is quite mature nowadays, though it still has a few bugs.
> keyboard/mouse sharing
I'm curious by what you mean with this?
Adding a second set of mouse/keyboards with their independent focus is for me simply a matter of running a few commands:
swaymsg -t get_inputs # lists input, allows you to identify which inputs you want to add to another seat
swaymsg seat my-new-seat attach my:second:mouse:identifier
swaymsg seat my-new-seat attach my:second:keyboard:identifier
swaymsg seat my-new-seat xcursor_theme Breeze_Snow
Of course, this can be added to the configuration file to make the settings persistent.
With this, a second cursor appears for the second mouse, with a different cursor theme, and a different focus, tied with the second keyboard. I can type into a terminal, and have another person next to me type a comment in the Firefox window next to it.
I'm not sure if that's what you mean by it, but it feels better and easier to configure than what we had with X.
There are a few bugs where apps don't handle multiple seats that well, and Xwayland applications are a bit left out (especially with cursor themes IIRC).
- Mid to late 1970's - people discovered they could build microcomputers, cheaper and less capable than the minis or mainframes of the day.
- Visicalc showed that micros could be a good business tool without all the expense of huge shared mini or mainframe systems.
- In 1981, IBM made a micro, so people started taking it seriously. Microsoft made a really good business decision to license not sell MS-DOS to IBM. It was the cheapest OS so the one most people picked.
- Rest of the 80s: Clone manufacturers made the hardware cheaper and cheaper. Clones also ensured Microsoft's OS worked as most software depended on it. This was the beginning of the downfall of IBM. Microsoft continued to acquire/produce business software for MS-DOS.
- PCs gained capability over the years. Microsoft introduced Windows 3.x, and people really liked it despite it's numerous flaws. With various GUI programs starting to become common and easy to do on the hardware, business interest of this platform flourished and it with Microsoft and Adobe products became the default.
- 90's: Microsoft started using OEM agreements and other business tactics to ensure OSes other than Windows were difficult to purchase. The Internet craze started and the PC was its primary thing that brought that to consumers in the 90's. After Intel came out with the Pentium, the Wintel marriage was solidified and thus began the downfall of CPUs in PCs other than x86.
- Microsoft continued to ride this domination wave until Javascript provided a way to deliver a desktop like experience without having to go througH Microsoft at all. 9/11 slowed things down everywhere. Microsoft let IE6 rot while it was working on Vista, giving Mozilla (backed by Google) a chance to sneak in a way to deliver a non-Microsoft experience on whatever platform was running the browser.
- 2007 - the iPhone - that began the shift from PCs to mobile for everyone. Because people wanted the Internet in the 90's, and email, and chat, and all it's good stuff, but they didn't really care about Windows. Windows was just what worked at the time. Apple adopted the walled garden model - meaning the browser was still the only way to deliver an experience outside of permission or control of another company. Why wasn't Microsoft in this position? It thought it was (and it looked lke it was)... it thought it could sit on its ass, collect OS license money and boss around both OEMs and cellular carriers like PC OEMs. What Apple did in the 00's with iPod->video iPod->iPhone iteration and timing is either super shrewd or super lucky.
- 2014 - cloud services - everyone finally saw what Google was doing and copied it, which was just a copy of the pre-micro mainframe way of doing things, but with prettier terminals that are virtualized and can do graphics and audio now. Unfortunately businesses don't want to give up Excel.
It also helped that web developers can be hired for a lot cheaper than native application programmers. Fast, lightweight code is hard to write and therefore expensive. Much easier and cheaper to just add a slightly outdated copy of Chrome to your application and program the entire thing in Javascript.
Yeah… I earn literally 5x working on a web stack with some Python than I did 4 years ago writing C# windows apps. Anecdotal but I’m pretty sure it’s normal to see big increases when you move over.
I can write as much of a project in a day using JS as a C++ dev could write in a week or more. My code will have fewer defects and more critically, will be 100% free of the worst kinds of defects that C++ enables.
Sure, my code will be 2-10x slower than the C++ stuff, but modern companies move really fast. A given user-facing project often gets thrown out every 4-5 years for yet another iteration. I will have been in maintenance mode and adding little features for 2-3 years. The C++ devs would barely be done with the MVP before it would be time to start over.
This means my total value to the company is higher than the C++ dev (even though they're a talented and amazing developer)
This is all before mentioning the supply and demand issue. Look at stackoverflow's surveys.
2013 5.1%
2015 6.0%
2017 8.5% (11.9% of the 72.6% that identified as doing web development)
2020 37.1% (peak)
2022 25.9% (current)
That's a 5-7x increase in demand since React was first released in 2013 (despite all the framework wars of prior years, the number of dedicated frontend devs was relatively small).
Everyone wants senior devs, but the number of devs with just 10 years of full-time experience is going to be 5% or less (despite the rhetoric, it takes more than 5 years to learn the frontend and that's only if we disregard the seriously niche things like WebGL). Instead, we see lots of "senior" JS devs that don't even know JS let alone the DOM. In contrast, you can easily find C++ devs with 15-20 years of experience (in fact, they may be easier to find than a C++ dev with only a handful of years of experience because people aren't learning C++ and C++ eats it's young).
The combination of productivity and lack off seniors drives up the salaries of middle and top end frontend talent.
Well, I agree it will have fewer memory bugs. But fewer issues altogether… you're just bragging now.
Your application will have awful keyboard navigation, will not support normal well established shortcuts, will contain vulnerable js that you will never bother to replace…
>Your application will have awful keyboard navigation, will not support normal well established shortcuts, will contain vulnerable js that you will never bother to replace…
...what?
These are all things that any developer - C++, JS based or otherwise - needs to implement and/or be mindful of. This has nothing to do with the language/runtime/platform and everything to do with the team implementing it and their level of attention to the platforms themselves.
Hell I cannot tell you the number of QT-based applications I've opened on macOS that violate established shortcuts. This isn't an Electron-only problem. ;P
You rag on them for "bragging" but your entire comment is basically one big attempt at kicking down on another development platform.
Put a JS dev and a C++ dev of equal experience against each other and the JS dev will have fewer bugs. At the most basic, the JS dev would have all the same logic bugs as the C++ dev, but subtracting the memory bugs from the JS bug count would itself be enough to prove my point.
There are many other reasons though. JS has only two number types (double and BigInt). As such, we can also essentially get rid of overflow errors that C++ does nothing to prevent. JS has an event loop baked into the core, so another class of C++ bugs go away. That same event loop bakes in its own thread pool to safely manage IO eliminating another class of bugs. Web workers (system processes) limit data sharing to slower, but more safe methods and eliminate yet another class of bugs. I'd note that these are some of the biggest possible sources of the hardest to find bugs and eliminates essentially all of the security nightmares found in C++ code.
Adding to this, JS code is more dense which tends to correlate with lower bug counts (until you reach super-high density like APL at which point you get maintenance issues). JS first-class functions with automatic closures adds a very powerful tool that is all-pervasive in real-world JS code, but isn't even present in C++ code (yes, closures exist, but in an extremely limited and manual way). Since ES2015, JS has powerful features like destructuring that make all the little data manipulations (so common in UI code) much easier and less prone to subtle bugs. If bugs do happen, JS makes it much easier to continue gracefully without everything crashing to the ground.
None of this should be surprising. C++ is an amazing language in its low-level area of expertise where all the features that can create more bugs are necessary and lead to amazing performance.
It also shouldn't be surprising that a very high-level language tailor-made for UI would be better at creating and maintaining a UI with fewer bugs.
As to keyboard navigation, that is entirely up to the devs to implement (whether C++ or JS). That said, web standards take A11y very seriously. Electron has `globalShortcut` and easy handling of shortcuts is baked right into the system if devs care to use it.
> Put a JS dev and a C++ dev of equal experience against each other and the JS dev will have fewer bugs. At the most basic, the JS dev would have all the same logic bugs as the C++ dev, but subtracting the memory bugs from the JS bug count would itself be enough to prove my point.
On the other hand the C++ developer can use boost and Qt libraries to have a wide range of well tested, well implemented components that implement a wide range of things, without having to sift in npm for hundreds of low quality abandoned modules.
So IN TOTAL, your point is far from proven.
> As to keyboard navigation, that is entirely up to the devs to implement
No. Toolkits for example implement decent tabbing. The qt designer offers a GUI to decide the tab order. And assigning shortcuts is even easier.
If you go and use kdelibs you get support to completely customize every single shortcut from the control panel, or from your own application.
Oh by the way with Qt you also get support to find in which directory to save settings, data, and so on. Which is not so trivial because all the defaults can be overridden by specific env vars.
You can either use C++ and a toolkit that does all this stuff, or JS and reimplement everything every time.
Now you're arguing that reimplementing every time is faster. It's an opinion but I don't think it's as obvious as you think it is.
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.
Great writeup, thanks to the author for sharing his deep experience in such a readable way. My career has also spanned different eras of UI tech, from win16/32, through server-generated HTML, Objective C and Swift/UI on mobile, and now I'm a full-time react and react native neckbeard.
And I ran to the react stack about 7-8 years ago from native iOS development. It made everything so much easier. On the way out the Cocoa door, I was pelted with comments about Performance, which was viewed as lacking in JS, a true second class citizen on a smartphone.
And they were right. If your app needed it.
Which it generally didn't - until it did. When the app I was writing started dealing with larger and larger amounts of data, a larger and larger number of views to visualize that data, large images being panned and zoomed ... I wanted the bare metal, I wanted the multithreading. I wanted the memory control.
That said, if you aren't going to push things that far graphics wise, and most apps don't, js/css/html is, to me, a far more joyful way to go.
Author didn't even touch on compile-time benefits, but they are spectacular when you go from Xcode, to React, then put the afterburners on with Fast Refresh, which is, truly, instant.
there's a magic with fast refresh which is that the code doesn't need to be rebundled and redeployed after a change. this would correspond to the linking and execution phase in c++. makes for an amazing experience when you are doing interactive development, orders of magnitude better in terms of responsiveness to the code you're writing.
I see the advantages of bundled websites masquerading as desktop application in regards to platform support.
But, is it really worth to have applications that take up 1 GB just for editing text or just for chatting? If it was only one such application, then it might have even been fine. But the plethora of chat applications and all of them heavy-weight Electron implementations really is a waste of memory. I need that saved memory to compile in parallel.
The same goes for Visual Studio Code. For me, it is visibly lagging when moving the cursor, scrolling, or editing, especially when it is large amount of syntax-highlighted text. Good old native text editors are still so much more responsive and less resource-intensive.
>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.
It's more about responsiveness when clicking buttons, opening menus, navigaing folders, etc. Most actions were ~sub-10ms even on crappy computers, which provided a nice "hardware" feeling which I don't really get from websites or electron apps.
> Because fully-fledged apps on Win98/XP were horribly slow compared to today.
Not really my experience - it's obvious the GUI is doing a lot of work to take what Windows XP would require and redraw it the way Windows 11 thinks it should. They don't feel faster, but now they have animated transitions and transparencies, while the CPU does 10x more work (which becomes more or less the same amount of time for a CPU with 1/10 of its clock).
This is one reason why a lot of Unix graphics applications feel so responsive on modern Linux boxes - they are doing the same amount of time they did 20 or 30 years ago while the computer is 10x as fast.
> This is one reason why a lot of Unix graphics applications feel so responsive on modern Linux boxes - they are doing the same amount of time they did 20 or 30 years ago while the computer is 10x as fast.
Yep. Hardware wise, we're in the wonderful position where Lisp and Smalltalk systems, once regarded as too slow to be useful on commodity hardware, are open and ready for action before you can even blink.
It's about proportionality to me. Sure the UI was slow because of the HDD speeds, swap, etc, but it wasn't slower proportionally to how much faster those things have gotten now. My first Windows 98 PC was probably hundreds of times slower than what I have now, but the modern experience hasn't gotten hundreds of times better.
There was a brief magical period when SSDs first became widely available that they seemed to have a huge impact because most software was still written for a HDD-based PC.
> I can't quite tell what point you're trying to make.
Easy. Use a high-framerate camera to measure the time it takes for an IRC client to change between channels. Thanks to being written in technologies decently close to the bare metal, every application in the Windows XP era was in the same ballpark of response times, when you disregard disk access times. We're only talking here about raw latency between a click and a graphical response.
Now compare it to the time it takes to switch channels in Slack, which is the 27$ billion company mentioned in the parent comment.
Spoiler: you won't even need the camera for the latter, because the web stack is so horribly inefficient that the GUI reaction is perfectly noticeable and I'd even say closer to a whole second.
"but apps do more thing nowadays" is a fair point but it gets cancelled with the fact that memory, cpu and disks have improved immensely since the older systems that are being compared here.
Every time a product owner decides to make a web UI, god kills a kitten. But with a lot of delay, so maybe we can still save it between keystrokes.
The point is precisely that mIRC was already fast in old machines; meanwhile, a big reason for Slack not being fast, snappy and using barely any RAM is that it's been written with web technologies, which have eaten out any potential benefit of modern increased performance.
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.
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
A lot of folks using Sublime today were temporary VSCode converts who returned to Sublime after dealing with its performance issues (myself included). I realized after some time that most VSCode extensions can be replaced with CLI utilities that are often more powerful, less resource intensive, and less buggy.
Im able to write Rust with full and fast type hinting/intellisense, auto importing, code formatting. This is one of the highest complexity languages from a rules based perspective.
I work in Monorepos and trying project(s) wide refactors take way more time sometimes hanging. This is Python vs PyCharm (but also involving JS). I’ve not had issues with Rust but my works rust/C is far smaller LOC so haven’t stressed it enough yet. Saying that I still prefer CLion as it has more features and is just as quick (M1 Max 64GB).
The post is about UI being in native for performance reasons, yet most of the processing/heavy logic of an IDE already is, or in a separate thread, even if the UI is in Electron.
At which point you're just discussing the performance gap between Canvas rendering and native graphics, which to a large extent disappears with WebGPU.
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 use IntelliJ at work and it’s significantly slower than VSCode.
Who knows about memory, but I use modern hardware so not really a concern. Id rather software optimize for responsiveness than minimizing memory use. Computers are only getting cheaper over time, aggressively deflating in real terms
I can see how being more memory constrained might flip the priorities
> I use IntelliJ at work and it’s significantly slower than VSCode.
I hear this a lot, and I don't think it's outright false, but it's a bit like saying a supertanker is slower than a tug.
The capabilities are just so far apart that it's not a good comparison, IMO.
I'm an IntelliJ fan (and customer) so I'll state that for bias, but the sheer volume of things IntelliJ _CAN_ do compared to VSCode I think is just mind boggling. It might be slower, but I think to compare that aspect while not looking at why is not quite useful.
> Who knows about memory, but I use modern hardware so not really a concern.
I don't know what your definition of "modern hardware" is, but if a 32GB machine isn't enough to edit text files and run a glorified IRC without occasionally having to restart everything to reclaim memory, then yes, it really is a concern.
Re: the IntelliJ comparison: to me, IntelliJ feels qualitatively slower on average than VSCode, but VSCode routinely just stops doing anything at all and I have to restart it.
I wonder if the difference is that we're not editing simple text files. Once you're effectively running a compiler on the fly to provide proper tooling then this memory usage isn't the big problem comparatively.
That definitely doesn't explain the difference for me, since in my current position I hardly write any code but I use VSCode constantly for editing plain text and I still see it go resource-nuts once a week. I assume that it has something to do with the fact that opening vscode to edit a single file results in a dozen processes with varying "-type=" arguments. I currently see --type=gpu-process, --type=renderer (x2), --type=zygote (x2), --type=ptyHost, --type=searchService, --type=watcherService, --type=extensionHost, --type=utility, and two processes without a --type argument. Eventually one or more of these processes will go nuts and start chewing CPU endlessly, it'll all go unresponsive, and I'll notice that my memory usage is pegged, then I'll restart the whole lot and everything will be better.
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?
You can write UIs in native targeting code (C++, Rust etc) and deploy to browser via WASM with WebGPU targeted render logic and get effectively the same render performance as a native built application, but without having to deal with cross-platform issues. If you really want to eek out that marginal extra performance vs writing directly in JS.
The truth is that the perception gap between web apps and native apps only shrinks over time, so that perceived performance matters less and less
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.
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.
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.
It seems to have too many glitches or edge-cases when working with other HTML widgets. After years of experience perhaps one learns to work around such, but it seems overly complicated for smaller-shop apps. "Enterprise" can afford to hire a dedicated CSS expert, mom-and-pop can't. We need KISS GUI's, not 4D-chess layout rocket science. With minor tweaks for screen-size adjusting, I believe WYSIWYG GUI makers that actually work right can come back in style.
> >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.
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.
My biggest complaint about HTML/CSS/JavaScript apps on the desktop is that typically UI components written for the browser do not implement all of the keyboard commands for selecting/deselecting multiple individual items (or contigous sections) from lists/tables or trees - with or without checkboxes/ticks/toggles.
If that would/could be standardized, I would never again complain about a desktop-scale data manipulation app shoved into an HTML/CSS/JavaScript host container.
Yes, I agree. And it seems that the author of this blog post agrees with that also, because he wrote: "If I could wave a magic wand, I would create an open working group, with the influence of the W3C behind me, to create a mandatory web standard for browsers that defines both a subset (to simplify and create an appropriate desktop security model) and an extension of CSS/HTML that is specifically optimized for marking up and implementing desktop applications, and have that all built into modern browsers as standard."
Amen! Business CRUD & desktops have been ignored over sexier domains such as social media and e-commerce. But it's still important. Ignore the plumbing of the world, and you get a pool of shit on your floors.
Make CRUD/GUI Great Again! Mice & Desktops Live!
Do we need a mass petition to get the ball rolling? I'll sign, several times even ;-)
Unless I missed something, the article neglects to point out that this is only a specific subset of desktop apps. Companies who build desktop GUI apps for products people are willing to pay for don't necessarily use any of the systems mentioned.
> 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 issue is exactly this. More and more people are coming into the development space using HTML/CSS/JavaScript and the information on the other technologies is harder to grasp and get a hold of.
Oh another issue I found was that there are way more people being condescending about native desktop development, than there are people who teach native desktop development
You mean those books that have not been updated for years, with tons of deprecated APIs, using bad practice or confusing examples, and as a beginner you don't have anyone to talk to about the material?
You may want to go to a public library and see what books they actually have. Those are not good stuff. I have actually looked at those, have you?
At least on Youtube you have a comment section where people discuss the material. Or if you are willing to pay some money, udemy provides some decent discussions and Q/A. And there are even better options out there.
Old books about Windows or Mac programming have all sorts of information that has apparently been mostly lost.
Two books I remember, perhaps not the best, but definitely with information that transcends specific technical details, are Bruce Tognazzini's Tog on Interface (or Tog on Software Design), and Charles Petzold's Programming Windows 95. The original "Inside Macintosh" series also comes to mind.
When I was learning AppKit, I just went to something something apple developer portal and read the relevant guides. Things may have changed since 2010, but back then these were beautiful compared to MDN (imo, iirc).
Just googled “AppKit development guides”. Yes, they changed to a reference format, what a shame.
>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
The feature parity of the web app and the electron app is often noticeable.
Microsoft products are a big one. oneNote web lacks a ton of features, teams Linux is very unstable and will outright not show the message history, jumping days or weeks at a time. I needed to make a powerpoint once and it just wouldn't save, the page would repeatedly reload and lose all the changes.
Why would you criticize a platform because corporations misuse that platform?
MS intentionally cripples its web offerings because native ones can collect way more data. The web and its featureset are not responsible for issues like "unstable Teams on Linux" and "a page repeatedly reloading and losing all the changes"
The only issue I have with teams for linux is it doesn't wake from suspend properly. So if I suspend I kill it and restart the app. Give that a try and see if it resolves your issues with message updates.
That isn't just Teams on Linux; that's also Teams on Windows (the native app, not thought he browser, even).
It is the most astoundingly buggy software I've ever used. I've experienced what you mentioned and more. Once, the GUI elements somehow failed to load, and buttons and menus appeared as text strings, like `sidebar_contact_expander`, and it was this eldritch horror of long string spam everywhere. In a native application. On Windows. Written by Microsoft.
Sorry. I have to cathartically vent about it whenever given the opportunity.
I concur! The MS-Teams UI designers must have been on an illicit substance. Or else they let a bunch of PHB's (MBA's) do a big Design By Committee. If it were not for bundling deals, nobody would touch Teams with a 10 foot laptop. And obvious features are missing. Somebody deserves a big public firing.
Our most popular Teams sub-site is "How To Work Around Teams Oddities". I don't even know if they are "bugs" because I don't know what the fudge MS intended.
Compared to gains in computing power? yes, it is entirely miserable.
I could press a button that I looked at in native app 20 years ago. Current day apps can't even get stable layout displayed 99% of the time. The "see the link, click the link, whoops something else got moved under my cursor in that 200ms interval" is soooo common if you try to use anything web quickly.
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.
You missed more: web developers are plentiful and your one app runs on every system imaginable.
Some web haters counter with the idea that if we had a common runtime / sandbox, native could target any OS as well. They miss that the browser is literally just that.
It probably could have been fixed, but HTML browsers kept a step ahead in progress. Java applets lost the improvement pace race, but the applet concept has merit because it was designed for GUI's, unlike HTML.
If applets had better up-front security, better version management and auto-updates (like current browsers do), and better download-modularity such that one didn't have to download the entire app to open one screen, for example. Oracle buying it didn't help, as they have a reputation for suing everything that moves.
> Some web haters counter with the idea that if we had a common runtime / sandbox, native could target any OS as well.
But if you had a common VM, runtime library, and sandbox that was feature-competitive with browsers, you’d basically just have reinvented the browser platform, but without the ecosystem of existing code and developers.
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.
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.
Could you just, stop styling shit and let your application look like the rest of the damned computer does?
FFS, in 1995 styling was something the user did to applications, now it is a way for developers to mangle the fucking GUI so they can look 'unique' and 'on brand'.
The rest of the computer looks like shit. The Gnome 43 file browser, for example, is an abomination of microscopic buttons. Try hunting down the "new folder" button, it's hidden under a "..." menu that isn't the hamburger menu and isn't another dropdown menu.
Macs and Windows aren't much better. I haven't used Word in ages, had to use it for something yesterday at work, and when I hit "Save As" it did seemingly nothing, after some fumbling I realized clicking "Save As" added a very unrecognizable "Save As" icon to the fucking titlebar. I have no idea whose horrible idea it was to put some buttons in the title bar and some buttons in the toolbar instead of all the buttons in one place.
Looking like notepad is not what you or whatever high-on-their-own-farts developers want. Looking consistent with all the other software on my computer is what I, and many others, want.
Sadly there are too many people like you in our industry so it will continue to suck.
What does it even mean to look like all the other software on a computer? None of my software looks anything like any of the other software. A white background application with a menu bar and some dialogs would look more out of place.
None of that even applies to software used to remote control a robot and mostly used by children who's primary other computer is a mobile phone or tablet.
That's part of the problem, eye-candy sells, but carries a complexity tax with it. Oracle Forms was butt-ugly, but got the every-day CRUD/GUI job done good-enough and was quick to develop with. Oracle Forms dev's ran circles around our web devs in terms of productivity. I looked into why, and Oracle Forms just required less code and less keystrokes to make apps and apps changes. (Oracle ruined OF when they rewrote the GUI client/browser into Java from C. Otherwise, OF would still be common. I don't like Oracle the company, but OF was magical productivity.) KISS style = KISS stack.
> 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.
If you lay out something and resize the window to be smaller, your GUI will just get cropped, and there will be buttons offscreen. That's not a good experience.
Also when you have, say, a chatroom where you have a huge box of scrolling content and then an entry area, you typically want the entry area to be constant height and the scrolling content to fill the remaining space, whereas there are other applications where you might want a percentage-based split. The native GUI doesn't know you want this. You have to somehow tell it that. CSS makes it super easy. Other toolkits make it very annoying to specify logic like this.
All native GUI toolkits from the last three decades allow you to reflow elements in the way you describe. Both CSS and native toolkits make it simple to express how elements move and stretch in response to window resizing.
Where CSS falls down is anything user-resizable. For example, a split view that collapses instead of cropping a text label. The CSS "resize" property is awful.
But most cross-platform native apps I've seen don't feel like "native GUI" at all. Blender doesn't. Godot doesn't. Krita doesn't. Maybe it's an OSS thing?
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.
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.
WPF and its markup language, XAML was added to Visual Studio in the 2008 edition. (But of course "there is only XUL" was way ahead-er when compared to either.)
XAML is generally static. A GUI markup browser/client should be interactive in my opinion. XUL had awkward command structures and syntax in my opinion. I didn't see the rhyme and reason for their odd choices.
> 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.
Then you get this hierarchy, compare to the old one, insert/remove/update controls and that’s it. Even issues like jumping focus on non-keyed elements will be the same.
Frameworks like React don’t do as much as you think they do wrt the paradigm itself. Most of work goes into pleasing performance quirks of both js and dom.
> 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.
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.
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.
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.
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.
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.
Yes, web app programming sucks. But a web framework UI that communicates with a native backend has a lot of advantages when compared with the actual alternatives I could use instead. The web has gotten orders of magnitude more investment in tools, and it shows.
key features implemented in a multi-process architecture, using plenty of C++ and Rust written modules
Which is exactly the point—the UI is written in HTML/CSS, not the native platform language, and the high-performance modules are written in C++ and Rust, also not the native platform language.
This point feels as though the author intends it to function as a 'defeater' -- C++ and Rust are used, therefore VSCode is a bad example (as a neighbor post says, an 'exception that proves the rule'.)
I invite you to consider that the converse may be true: if you can keep things performant by RIIR or even C++, it makes a great case that desktop apps should resemble web apps, with a native backend talking to a JS/CSS/HTML frontend. It does not function as a cautionary tale, but as a compelling proof-of-concept.
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.
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.
> 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...
> 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.
It feels exactly like an electron app. Garish theme that does not respect system preferences, a memory hog, lack of integration with system services, and a general feeling of being build for some product manager rather them users.
"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.
If electron is dog slow on your PC, upgrade. You're not the target platform. Runs fine on any device of the last 5 years with more than 4gb of ram. I suspect it runs just fine on your computer.
Computer power usage is not even on a blip on the chart of power usage globally. A cult would infer the usage is small. On the contrary chromium is in almost everything nowadays, even medical equipment.
The most robust graphics rendering engine is of course going to be used everywhere for graphics.
Be careful with this reasoning: even if one Electron app might run fine, what about like 10 different ones at the same time? The overhead will compound worse than native apps.
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.
I worked with a junior dev who was developing his own 2D/3D data visualization framework. He used XML and ended up reinventing HTML for the most part.
HTML and CSS are sane approaches to the problem of highly flexible GUI being generated and/or delivered over the network. That said, their implementations could be vastly improved (CSS has come a long way, but HTML needs HTMX/Livewire baked in).
>> there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff…
We need to push for Wayland. With MS Windows adding in advertising, and OSX being a locked-in expensive choice, Linux desktop needs to gain ground now.
> 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.
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…
I know TONS of people (including high paid people) who refuse to pay $3 for a good app and instead opt for the free knockoff with tons of jank and nonstop ads.
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.
The only time I've seen cross-platform webtech save meaningful amounts of time and money is when corporate weenies insist that the program look identical on every platform, rather than letting you use a native look for most of it.
Styling every single input to look identical on every platform does indeed waste a lot of time—but that's not native's fault, it's the "everything must be On Brand at the expense of all other concerns" people's fault.
Meanwhile I very much doubt the customer gives even a subconsious shit that your "app"'s radio buttons look identical to the (also custom) ones on your website. They probably do give a shit that they look unfamiliar compared with natives apps, so take a little more mental energy to process, and they probably do give a shit if your theming introduces any jankiness that wouldn't otherwise be there (and it very often does).
But, yes, that level of making everything look and behave identically everywhere is far easier to achieve with webtech. But you could... just not, instead.
Qt development with C++ is slow. Development with QML means JS anyway (good luck finding JS devs with Qt experience) and still having to hire C++ devs too for non trivial apps.
Now you're changing your story. Before you said someone would have to "write versions of that app in several different languages/platforms."
Qt development with C++ is slow.
What are you basing that on?
Development with QML means JS anyway
That's actually only for parameters of the QML UI, which is a tiny part of working program. Actually the GUI that can be done through any library is a very tiny part of most programs. Declaring widgets and laying them out is not difficult or time consuming, there isn't much logic there.
good luck finding JS devs with Qt experience
Any competent C++ programmer can just start using javascript after a day or two of tutorials. There is no need to hire "a JS dev", you just hire a good programmer. Javascript is not that hard. Modern C++ is not even that hard, but as a language javascript is even easier.
Anyone who calls themselves "a JS dev" is probably not that experienced to begin with. Learning languages is trivial to someone with experience.
Have you ever made a GUI program with modern C++ and FLTK ? It's incredibly easy and the results are lightning quick while starting at 100KB.
Have you ever tried to make c++ dev to code JavaScript?
It is not like you can drop by and say “Joe tomorrow you also write JS”.
Same for JS devs as it is not that they could not do c++. It is that now you require more so you have to pay them more. If you don’t - they will go to work in company where they do only JS.
Have you ever tried to make c++ dev to code JavaScript?
Yeah, it's not something anyone considers an issue.
It is not like you can drop by and say “Joe tomorrow you also write JS”.
I've never even met a C++ programmer that didn't know javascript. Every one knew multiple scripting languages and javascript isn't that different. Where are you getting this idea that individual languages are difficult?
Same for JS devs as it is not that they could not do c++. It is that now you require more so you have to pay them more. If you don’t - they will go to work in company where they do only JS.
This view that knowing more than one language means anything is usually not held by professional programmers. My experience is that this is only an idea held by people who have just learned their first language and feel overwhelmed by learning anything else.
If you know C, it doesn't mean you are any good at Haskell, Prolog, Forth, Smalltalk, Lisp, or any other major paradigms. All of those introduce fundamental concepts that the C programmer simply does not know (I recommend learning all of these to expand your horizons as a programmer, but you meet very few devs that know or understand anything outside their narrow proceedural/OOP window).
JS is a completely different paradigm from C++ mixing in functional programming with dynamic objects in a way that C++ simply cannot do things.
If a C++ dev wanted to learn Python, they'd pick up and read some books on the subject. Same if they wanted to learn PHP, Java, Perl, C#, or whatever. But when it comes to JS, they just try to wing it.
Their stuff kinda works, but they don't even realize that they are fighting the language every step of the way. As a result, they complain that JS is slow and the design sucks when the reality is that they don't understand, but have too much hubris to actually go back to school for a little while.
I spent much of the early part of my JS career fixing the code written by these kinds of C++ devs. While they wrote amazing C++ code, the JS they wrote was a mess. I could rewrite their code in a fraction of the LOC while making it more readable and faster too.
JS is a completely different paradigm from C++ mixing in functional programming with dynamic objects in a way that C++ simply cannot do things.
Where do these ideas come from? Every modern language has elements that were originally considered "functional". Good programmers will do well with any language.
What are 'dynamic objects' and what is the way that 'C++ simple cannot do thing'?
You make these claims without backing anything up.
If a C++ dev wanted to learn Python, they'd pick up and read some books on the subject. Same if they wanted to learn PHP, Java, Perl, C#, or whatever. But when it comes to JS, they just try to wing it.
Where are getting this from? Most programmers learn javascript before C++ because it's so easy to try things out in a web browser.
Their stuff kinda works, but they don't even realize that they are fighting the language every step of the way. As a result, they complain that JS is slow and the design sucks when the reality is that they don't understand, but have too much hubris to actually go back to school for a little while.
Who are you talking about? Is this describing a single person you met?
these kinds of C++ devs. While they wrote amazing C++ code, the JS they wrote was a mess
I have news for you, their C++ was probably terrible too.
Even labeling someone as a "C++ dev" or "javascript dev" is a giant red flag of inexperience.
> What are 'dynamic objects' and what is the way that 'C++ simple cannot do thing'?
This is the foremost proof that knowing C++ doesn't mean you know anything about JS.
JS objects are dynamic with the ability to add/remove class properties and methods or to dynamically change what class/object it inherits from all as the program executes. C++ classes are static and determined at compile time.
> Most programmers learn javascript before C++ because it's so easy to try things out in a web browser.
Most C++ programmers started programming C++ long before JS became popular. Most people who "know JS" don't actually know the language to any meaningful degree. I'm not talking about subtle things like the difference between `-0 === 0` and `Object.is(-0, 0)` or why you might use `x === x`. I mean that most can't tell me what a closure is, why you'd want to use one, or even how to use it in something like a factory. For the record, this question isn't even JS-specific, but applies to Ruby, Python, Lua, PHP, the ML family, Rust (actually just a ML with C-like syntax), Erlang, most lisps, etc.
> Where do these ideas come from? Every modern language has elements that were originally considered "functional".
JS is multi-paradigm offering imperative, OOP, and functional approaches, but because its functions inherited heavily from Scheme (I really wish Eich could have implemented scheme), it gets a lot of really nice properties.
Consider the following code (leaning heavily into the point-free side for sake of illustration)
let prop = key => obj => obj[key]
let map = fn => arr => arr.map(fn)
let filter = fn => arr => arr.filter(fn)
let reduce = fn => arr => arr.reduce(fn)
let sum = (acc, x) => acc + x
let pipe = (...fns) => val => fns.reduce((acc, fn) => fn(acc), val)
let data = [
{
fname: "John",
lname: "Doe",
age: 41,
sex: 'M',
children: [
{fname: "Fred", lname: "Doe", age: 11},
{fname: "Jill", lname: "Doe", age: 8},
{fname: "Elliot", lname: "Doe", age: 3},
]
}
]
let printSumOfChildenAgeOfMiddleAgedFathers = pipe(
filter(x => x.sex === 'M' && x.age > 40), //get all males over 40
map( //for each male
pipe(
prop('children'), //get their children and age
map(prop('age')),
reduce(sum), //add ages together for father
)
),
reduce(sum), //add ages for all fathers
)
Sure, it is pointless code off the top of my head to illustrate my point (though with some changes it could be actual code I've seen). If you'd like to counter, write this functional-style code in C++ without changing to imperative code. It'll be 10x as long and an unreadable mess.
> Even labeling someone as a "C++ dev" or "javascript dev" is a giant red flag of inexperience.
I consider language design as a bit of a hobby and I've spent time with a LOT of very different languages. Even so, I only consider myself proficient in a handful of them. Even setting aside the impossible task of learning all those standard libraries completely (even most experienced Java or C# devs don't actually know the entire standard library of those behemoths), just learning the warts and weird edge cases of almost any language you can name takes at least a couple years and with large and/or convoluted languages (eg, C++ or JS) it can take many years.
JS objects are dynamic with the ability to add/remove class properties and methods or to dynamically change what class/object it inherits from all as the program executes.
You realize they're just hash maps / dictionaries right?
Most C++ programmers started programming C++ long before JS became popular.
Do you think most C++ programmers today started 30 years ago in the early 90s?
You realize you can write everything you wrote pretty directly in C++, python, lua or a lot of other modern languages out there right? I get the impression that you don't know much about modern C++ and just base what you are saying off things you have heard from other javascript programmers trying to avoid learning other languages.
> You realize they're just hash maps / dictionaries right?
That's only a conceptual idea. In reality, the JIT uses real arrays and dynamically generated structs.
You can't actually implement them directly as conceptually described anyway. You have to have a has of boxed pointers and when you get around to adding functions with types, things get really weird. The class implementation is actually much more simple in many ways (not to mention being much faster).
> You realize you can write everything you wrote pretty directly in C++
I know you can't write curried functions "pretty directly" in C++ (Python and Lua are the languages I was discussing directly and both are far better for UI work than C++). Give it a try and post the results. I'd be very impressed if it took even just twice as many lines of typical C++ code.
I don't even know what point you're trying to make anymore. You originally said you think C++ takes five times as long as javascript and that most C++ programmers learned it before javascript existed.
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.
The issue is UI jank and occasional UI slowness. If there’s any serious work, it’s probably implemented natively or with WASM, so computational performance isn’t terrible.
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 :)
The browser is a seriously capable desktop app. Think e.g. about dynamic manipulation of SVG with d3 or 3D stuff with three.js or any of the other countless other goodies that are now available via the HTML/CSS/JS set.
If one could somehow abstract and standardize GUI elements it could unleash a lot of creativity around browser-based desktop apps. Native app development frameworks would benefit too, they could re-implement some aspects of those GUI elements natively (outside browsers). Developers would have less friction to switch from browser to native and back.
I think the web is culturally incapable of standardizing GUI elements. The nature of web development is to rebuild from scratch. Standard buttons and menus look so vanilla, let's instead style a div with an onClick handler, let's use a hover selector with a scroll animation. The set of UI interactions collapses to its ground state: click, tap, basic text entry.
Has any new UI paradigm emerged on the web in the last 25 years? Maybe the hamburger button? Honest question, I struggle to think of any. The richest web apps are still aping desktop apps.
I wouldnt defend web culture in this respect. Some people also argue that html is really about documents and not a good basis for a gui anyways.
But I think technically it is possible to overload whatever is available and have very decent, easy to build apps and have a productive, cross platform option. Its not going to make those pushing gui limits sweat, but that is not its point.
In any case its not going to happen as the experience with standard development and adoption is quite painful
> I think technically it is possible to overload whatever is available [in existing web standards] and have very decent, easy to build [GUI] apps
"Technically", perhaps. "Easy", no! It appears the DOM is inherently too flawed to serve GUI's well, and fixing it would likely break backward compatibility. Forcing DOM to do GUI's is possible, but turns even women bald.
Originally browsers actually used native button widgets for buttons. That was back when the software world made some kind of sense though and adware industries didn't run everything.
then your desktop apps written this way are pretty much 100% cross-platform too
Speaking from a FreeBSD user's perspective: No, actually they are not. No electron binary runs on FreeBSD because Electron is based on chrome, and some of the linux sandbox syscalls needed for chrome are not emulated. So when things move from a real native Linux app to Electron, they become unusable for me.
Not to mention that Electron is bloated compared to a native app..
Uhm, I was running VSCode on FreeBSD[1]. It took a while to make it happen, but it did happen. It still sucks though and porting those apps to FreeBSD isn't easy. However, I recognize that anyone, myself included, who runs FreeBSD on desktop/laptop is ready for such struggles. We're a tiny minority within a minority.
I'm madder about google not allowing DartVM to be ported to FreeBSD because they "want to keep repo free of platform-specific code" while have code dedicated to Fuchsia, Chrome OS and Android-specific code in there.
It's not running a Linux version of Chrome. FreeBSD version of just isn't sandboxed. In fact, I don't think there is a single modern browser on FreeBSD that is sandboxed, even though Capsicum been around for more than a decade.
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.)
Well, there should be. It's a big gap in our current standards. DOM is missing roughly 15 common GUI idioms, and its text positioning reliability is broken and likely can't be fixed without tossing backward compatibility. More on these gaps:
https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
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)
There few requirements (in my mind) for proven GUI toolkit (at least on Windows) apart from UX points:
- Support multiple windows
- Support docking, and dock-in-dock
- Deal gracefully with Remote Desktop services
If you start with UI toolkit not dealing with any of the above points, you are limited in what you can do. Maybe you don't need the first two, that's fine, this is where electron is. But if you have to do a content creation application (Maya, 3DSMax, Blender, Unreal Editor, etc.) - you need to support multiple windows and docking windows in other windows - preserve layouts, etc.
And then Remote Desktop, because you may need someone to assist and log in to the machine, or work remotely (especially today), and if RDP does not work (sorry, but there are some pure OpenGL toolkits), then it's a loss.
OS X is a dream to develop for. It really is amazing.
Windows, is honestly, not terrible. I don't know anything about C# or Winforms or whatever modern Windows GUI apps are created in, I used Win32 API and MFC. They may have been a little kludgey, but they got the job done. Lots of documentation and code out there, like 20 times as much for the Mac.
Now, Linux... I've tried. Haven't gotten far. Both Qt and GTK.
Anyway, it's obvious why everything is written in Electron and friends. People are familiar with it. Everyone's a web developer. It's cross-platform. It's a big deal to learn another environment. Why wouldn't you want to be able to run on Windows, web (phones/tablets), Linux...?
I've built GUI applications for Windows in the primary frameworks Microsoft provides (WinForm, WPF, MAUI, UWP). It is not terrible, but also not great. I have high hopes for MAUI, but honestly, it seems very PoC-ish compared to everything else Microsoft have provided.
Tried X11 directly on Linux before I decided that it was just too difficult. Switched to QT, and there were a million bugs and quirks that forced me back to just Windows GUI development.
JavaScript/HTML GUI frameworks along with embedded browsers have been the key to cross platform compatibility without all the fuss. But it seem to also have become the death of good real-time and responsive UIs.
Perhaps it's poorly worded, but we do need better business/CRUD/GUI standards for HTTP-based apps: a state-ful GUI markup standard. Attempts to get DOM & JS to do desktop-friendly GUI's well keep failing after 25+ years of trying, with clunky results & long learning curves.
XAML is static, and XUL had verbose and awkward syntax & commands. I think QtQuick is also static. QML is perhaps a closer example (but not XML), but many Qt-related tools are proprietary or have dodgy licenses.
What happened is naturally growth. There are more developers today then ever before, corresponding to the rise in the global population. As there are more and more developers, there is an associated rise in the number of people wanting to get into making desktop GUI applications. Most people don't know desktop frameworks like QT and Swing, so new people coming into the application development space are going to make applications in what they know: HTML/CSS/JavaScript.
Yet even as this happens and HTML/CSS/JavaScript rises that doesn't mean that there is a decline in the making of desktop applications. I think that desktop applications made with native technologies are being built as much as ever, its just that the industry as a whole has grown to accommodate the vast influx of new HTML/CSS/JavaScript developers. For example, my favorite applications are build in Swing (IntelliJ and related projects) or in QT.
> Just for completeness I should mention Linux, it is the best computing platform to happen to the world and should be admired in every way – except one! the desktop/UI sucks, its awful in almost every way
I say that KDE is awesome. So that is just your opinion, and not everyone agrees.
> Developing desktop apps in 2022 is essentially an HTML/CSS/JavaScript endeavour
That does not follow.
> 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.
That is not my experience. Visual Studio Code doesn't seem to run as smoothly as I would like. Meanwhile every C++/QT application I have run works perfectly. Where are you getting this from?
WSJT-X is a cross-platform QT app. It is multi-threaded, processes audio in close to real time, talks to devices over serial interfaces, interoperates with other apps over UDP and TCP connections. It starts fast, and has a pretty small memory footprint (around 80 MB) and was literally written (largely) by amateurs.
OTOH, it is not a beautiful, lovely app. The UI does look like 1999. But it works fabulously.
> That is not my experience. Visual Studio Code doesn't seem to run as smoothly as I would like. Meanwhile every C++/QT application I have run works perfectly. Where are you getting this from?
I’m in a bit of a unique position where I work on both a Qt app using Qt Creator and a React app using VS Code. Qt Creator has crashed on me numerous times, has slower initial loads, regularly has weird visual bugs, and is overall much less enjoyable to use.
I develop on a modern windows computer. Maybe Qt Creator performance wins against VS Code on Linux? In my experience, VS Code does not perform as well on Linux as it does on Windows or OSX.
I've recently tried QT creator and it was hard to get working at first, but once I did it didn't have any problems or visual bugs for me. Overall it seems to be working pretty great, but rather or not you have issues depends upon your install, what version you are using, what operating system your are using, etc. So who knows.
But I think that QT creator should have a faster initial load then Visual Studio Code, because the later has to open up an entire browser render-er to work. QT creator opens instantly on my system, but visual studio code lags for a second. The weird visual bugs might indicate something else wrong with your system which is messing up the program. A picture might help us to find what the bug is so we can fix it if there is a serious problem with QT creator.
As for the less enjoyable to use thing, there isn't much I can do about that. Visual studio code is probably more fun to use, and React isn't too bad either. Using React can be a joyful experience indeed. But enjoyment issues aside, I think that a good C++/QT based application should have a performance advantage over one made with HTML/CSS/JavaScript and Electron. Visual studio code can be more enjoyable but still perform slightly less well, because it doesn't have to make a difference to the end user that it does things a couple milliseconds slower.
Sigh. We'll be stuck with JS, HTML and CSS until the end of time. Just the other day I had to debug a problem in a webapp where come JS code concatenated a string with a (null) value and "servernamenull" was the result. Ugh.
280 comments
[ 3.3 ms ] story [ 266 ms ] threadUnrelated, 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.
> keyboard/mouse sharing
I'm curious by what you mean with this?
Adding a second set of mouse/keyboards with their independent focus is for me simply a matter of running a few commands:
Of course, this can be added to the configuration file to make the settings persistent. With this, a second cursor appears for the second mouse, with a different cursor theme, and a different focus, tied with the second keyboard. I can type into a terminal, and have another person next to me type a comment in the Firefox window next to it.I'm not sure if that's what you mean by it, but it feels better and easier to configure than what we had with X. There are a few bugs where apps don't handle multiple seats that well, and Xwayland applications are a bit left out (especially with cursor themes IIRC).
- Mid to late 1970's - people discovered they could build microcomputers, cheaper and less capable than the minis or mainframes of the day.
- Visicalc showed that micros could be a good business tool without all the expense of huge shared mini or mainframe systems.
- In 1981, IBM made a micro, so people started taking it seriously. Microsoft made a really good business decision to license not sell MS-DOS to IBM. It was the cheapest OS so the one most people picked.
- Rest of the 80s: Clone manufacturers made the hardware cheaper and cheaper. Clones also ensured Microsoft's OS worked as most software depended on it. This was the beginning of the downfall of IBM. Microsoft continued to acquire/produce business software for MS-DOS.
- PCs gained capability over the years. Microsoft introduced Windows 3.x, and people really liked it despite it's numerous flaws. With various GUI programs starting to become common and easy to do on the hardware, business interest of this platform flourished and it with Microsoft and Adobe products became the default.
- 90's: Microsoft started using OEM agreements and other business tactics to ensure OSes other than Windows were difficult to purchase. The Internet craze started and the PC was its primary thing that brought that to consumers in the 90's. After Intel came out with the Pentium, the Wintel marriage was solidified and thus began the downfall of CPUs in PCs other than x86.
- Microsoft continued to ride this domination wave until Javascript provided a way to deliver a desktop like experience without having to go througH Microsoft at all. 9/11 slowed things down everywhere. Microsoft let IE6 rot while it was working on Vista, giving Mozilla (backed by Google) a chance to sneak in a way to deliver a non-Microsoft experience on whatever platform was running the browser.
- 2007 - the iPhone - that began the shift from PCs to mobile for everyone. Because people wanted the Internet in the 90's, and email, and chat, and all it's good stuff, but they didn't really care about Windows. Windows was just what worked at the time. Apple adopted the walled garden model - meaning the browser was still the only way to deliver an experience outside of permission or control of another company. Why wasn't Microsoft in this position? It thought it was (and it looked lke it was)... it thought it could sit on its ass, collect OS license money and boss around both OEMs and cellular carriers like PC OEMs. What Apple did in the 00's with iPod->video iPod->iPhone iteration and timing is either super shrewd or super lucky.
- 2014 - cloud services - everyone finally saw what Google was doing and copied it, which was just a copy of the pre-micro mainframe way of doing things, but with prettier terminals that are virtualized and can do graphics and audio now. Unfortunately businesses don't want to give up Excel.
If anything, several C++ threads indicate those devs are tired of getting paid less.
Sure, my code will be 2-10x slower than the C++ stuff, but modern companies move really fast. A given user-facing project often gets thrown out every 4-5 years for yet another iteration. I will have been in maintenance mode and adding little features for 2-3 years. The C++ devs would barely be done with the MVP before it would be time to start over.
This means my total value to the company is higher than the C++ dev (even though they're a talented and amazing developer)
This is all before mentioning the supply and demand issue. Look at stackoverflow's surveys.
That's a 5-7x increase in demand since React was first released in 2013 (despite all the framework wars of prior years, the number of dedicated frontend devs was relatively small).Everyone wants senior devs, but the number of devs with just 10 years of full-time experience is going to be 5% or less (despite the rhetoric, it takes more than 5 years to learn the frontend and that's only if we disregard the seriously niche things like WebGL). Instead, we see lots of "senior" JS devs that don't even know JS let alone the DOM. In contrast, you can easily find C++ devs with 15-20 years of experience (in fact, they may be easier to find than a C++ dev with only a handful of years of experience because people aren't learning C++ and C++ eats it's young).
The combination of productivity and lack off seniors drives up the salaries of middle and top end frontend talent.
Well, I agree it will have fewer memory bugs. But fewer issues altogether… you're just bragging now.
Your application will have awful keyboard navigation, will not support normal well established shortcuts, will contain vulnerable js that you will never bother to replace…
...what?
These are all things that any developer - C++, JS based or otherwise - needs to implement and/or be mindful of. This has nothing to do with the language/runtime/platform and everything to do with the team implementing it and their level of attention to the platforms themselves.
Hell I cannot tell you the number of QT-based applications I've opened on macOS that violate established shortcuts. This isn't an Electron-only problem. ;P
You rag on them for "bragging" but your entire comment is basically one big attempt at kicking down on another development platform.
There are many other reasons though. JS has only two number types (double and BigInt). As such, we can also essentially get rid of overflow errors that C++ does nothing to prevent. JS has an event loop baked into the core, so another class of C++ bugs go away. That same event loop bakes in its own thread pool to safely manage IO eliminating another class of bugs. Web workers (system processes) limit data sharing to slower, but more safe methods and eliminate yet another class of bugs. I'd note that these are some of the biggest possible sources of the hardest to find bugs and eliminates essentially all of the security nightmares found in C++ code.
Adding to this, JS code is more dense which tends to correlate with lower bug counts (until you reach super-high density like APL at which point you get maintenance issues). JS first-class functions with automatic closures adds a very powerful tool that is all-pervasive in real-world JS code, but isn't even present in C++ code (yes, closures exist, but in an extremely limited and manual way). Since ES2015, JS has powerful features like destructuring that make all the little data manipulations (so common in UI code) much easier and less prone to subtle bugs. If bugs do happen, JS makes it much easier to continue gracefully without everything crashing to the ground.
None of this should be surprising. C++ is an amazing language in its low-level area of expertise where all the features that can create more bugs are necessary and lead to amazing performance.
It also shouldn't be surprising that a very high-level language tailor-made for UI would be better at creating and maintaining a UI with fewer bugs.
As to keyboard navigation, that is entirely up to the devs to implement (whether C++ or JS). That said, web standards take A11y very seriously. Electron has `globalShortcut` and easy handling of shortcuts is baked right into the system if devs care to use it.
https://www.electronjs.org/docs/latest/tutorial/keyboard-sho...
https://www.electronjs.org/docs/latest/api/global-shortcut
On the other hand the C++ developer can use boost and Qt libraries to have a wide range of well tested, well implemented components that implement a wide range of things, without having to sift in npm for hundreds of low quality abandoned modules.
So IN TOTAL, your point is far from proven.
> As to keyboard navigation, that is entirely up to the devs to implement
No. Toolkits for example implement decent tabbing. The qt designer offers a GUI to decide the tab order. And assigning shortcuts is even easier.
If you go and use kdelibs you get support to completely customize every single shortcut from the control panel, or from your own application.
Oh by the way with Qt you also get support to find in which directory to save settings, data, and so on. Which is not so trivial because all the defaults can be overridden by specific env vars.
You can either use C++ and a toolkit that does all this stuff, or JS and reimplement everything every time.
Now you're arguing that reimplementing every time is faster. It's an opinion but I don't think it's as obvious as you think it is.
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.
And I ran to the react stack about 7-8 years ago from native iOS development. It made everything so much easier. On the way out the Cocoa door, I was pelted with comments about Performance, which was viewed as lacking in JS, a true second class citizen on a smartphone.
And they were right. If your app needed it.
Which it generally didn't - until it did. When the app I was writing started dealing with larger and larger amounts of data, a larger and larger number of views to visualize that data, large images being panned and zoomed ... I wanted the bare metal, I wanted the multithreading. I wanted the memory control.
That said, if you aren't going to push things that far graphics wise, and most apps don't, js/css/html is, to me, a far more joyful way to go.
Author didn't even touch on compile-time benefits, but they are spectacular when you go from Xcode, to React, then put the afterburners on with Fast Refresh, which is, truly, instant.
But, is it really worth to have applications that take up 1 GB just for editing text or just for chatting? If it was only one such application, then it might have even been fine. But the plethora of chat applications and all of them heavy-weight Electron implementations really is a waste of memory. I need that saved memory to compile in parallel.
The same goes for Visual Studio Code. For me, it is visibly lagging when moving the cursor, scrolling, or editing, especially when it is large amount of syntax-highlighted text. Good old native text editors are still so much more responsive and less resource-intensive.
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)
Apparently not. You'd think the author would clearly recall the scenario you described.
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.
Not really my experience - it's obvious the GUI is doing a lot of work to take what Windows XP would require and redraw it the way Windows 11 thinks it should. They don't feel faster, but now they have animated transitions and transparencies, while the CPU does 10x more work (which becomes more or less the same amount of time for a CPU with 1/10 of its clock).
This is one reason why a lot of Unix graphics applications feel so responsive on modern Linux boxes - they are doing the same amount of time they did 20 or 30 years ago while the computer is 10x as fast.
Yep. Hardware wise, we're in the wonderful position where Lisp and Smalltalk systems, once regarded as too slow to be useful on commodity hardware, are open and ready for action before you can even blink.
There was a brief magical period when SSDs first became widely available that they seemed to have a huge impact because most software was still written for a HDD-based PC.
Easy. Use a high-framerate camera to measure the time it takes for an IRC client to change between channels. Thanks to being written in technologies decently close to the bare metal, every application in the Windows XP era was in the same ballpark of response times, when you disregard disk access times. We're only talking here about raw latency between a click and a graphical response.
Now compare it to the time it takes to switch channels in Slack, which is the 27$ billion company mentioned in the parent comment.
Spoiler: you won't even need the camera for the latter, because the web stack is so horribly inefficient that the GUI reaction is perfectly noticeable and I'd even say closer to a whole second.
"but apps do more thing nowadays" is a fair point but it gets cancelled with the fact that memory, cpu and disks have improved immensely since the older systems that are being compared here.
Every time a product owner decides to make a web UI, god kills a kitten. But with a lot of delay, so maybe we can still save it between keystrokes.
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
Performance differences aren’t that meaningful at the margins. You tend to give up a lot of velocity when you eschew browser based rendering.
JetBrains is far slower than both
Where is the slowness?
The post is about UI being in native for performance reasons, yet most of the processing/heavy logic of an IDE already is, or in a separate thread, even if the UI is in Electron.
At which point you're just discussing the performance gap between Canvas rendering and native graphics, which to a large extent disappears with WebGPU.
Who knows about memory, but I use modern hardware so not really a concern. Id rather software optimize for responsiveness than minimizing memory use. Computers are only getting cheaper over time, aggressively deflating in real terms
I can see how being more memory constrained might flip the priorities
I hear this a lot, and I don't think it's outright false, but it's a bit like saying a supertanker is slower than a tug.
The capabilities are just so far apart that it's not a good comparison, IMO.
I'm an IntelliJ fan (and customer) so I'll state that for bias, but the sheer volume of things IntelliJ _CAN_ do compared to VSCode I think is just mind boggling. It might be slower, but I think to compare that aspect while not looking at why is not quite useful.
I don't know what your definition of "modern hardware" is, but if a 32GB machine isn't enough to edit text files and run a glorified IRC without occasionally having to restart everything to reclaim memory, then yes, it really is a concern.
Re: the IntelliJ comparison: to me, IntelliJ feels qualitatively slower on average than VSCode, but VSCode routinely just stops doing anything at all and I have to restart it.
Hardly reducing any gap.
The truth is that the perception gap between web apps and native apps only shrinks over time, so that perceived performance matters less and less
> 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?
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.
If that would/could be standardized, I would never again complain about a desktop-scale data manipulation app shoved into an HTML/CSS/JavaScript host container.
Make CRUD/GUI Great Again! Mice & Desktops Live!
Do we need a mass petition to get the ball rolling? I'll sign, several times even ;-)
List of HTML shortcomings per GUI: https://www.reddit.com/r/programming/comments/otixwo/comment...
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.
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
You may want to go to a public library and see what books they actually have. Those are not good stuff. I have actually looked at those, have you?
At least on Youtube you have a comment section where people discuss the material. Or if you are willing to pay some money, udemy provides some decent discussions and Q/A. And there are even better options out there.
Old books about Windows or Mac programming have all sorts of information that has apparently been mostly lost.
Two books I remember, perhaps not the best, but definitely with information that transcends specific technical details, are Bruce Tognazzini's Tog on Interface (or Tog on Software Design), and Charles Petzold's Programming Windows 95. The original "Inside Macintosh" series also comes to mind.
Just googled “AppKit development guides”. Yes, they changed to a reference format, what a shame.
It seems that good guides were moved to archive: https://developer.apple.com/library/archive/navigation/#sect...
App Programming quick link: https://developer.apple.com/library/archive/documentation/Ge...
It seems you’re just a little late to learn it :)
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
Microsoft products are a big one. oneNote web lacks a ton of features, teams Linux is very unstable and will outright not show the message history, jumping days or weeks at a time. I needed to make a powerpoint once and it just wouldn't save, the page would repeatedly reload and lose all the changes.
MS intentionally cripples its web offerings because native ones can collect way more data. The web and its featureset are not responsible for issues like "unstable Teams on Linux" and "a page repeatedly reloading and losing all the changes"
It is the most astoundingly buggy software I've ever used. I've experienced what you mentioned and more. Once, the GUI elements somehow failed to load, and buttons and menus appeared as text strings, like `sidebar_contact_expander`, and it was this eldritch horror of long string spam everywhere. In a native application. On Windows. Written by Microsoft.
Sorry. I have to cathartically vent about it whenever given the opportunity.
Our most popular Teams sub-site is "How To Work Around Teams Oddities". I don't even know if they are "bugs" because I don't know what the fudge MS intended.
I could press a button that I looked at in native app 20 years ago. Current day apps can't even get stable layout displayed 99% of the time. The "see the link, click the link, whoops something else got moved under my cursor in that 200ms interval" is soooo common if you try to use anything web quickly.
Some web haters counter with the idea that if we had a common runtime / sandbox, native could target any OS as well. They miss that the browser is literally just that.
I remember when that was called "Java". :-) It didn't work out on the desktop.
The browser ultimately delivered on the promise
If applets had better up-front security, better version management and auto-updates (like current browsers do), and better download-modularity such that one didn't have to download the entire app to open one screen, for example. Oracle buying it didn't help, as they have a reputation for suing everything that moves.
But if you had a common VM, runtime library, and sandbox that was feature-competitive with browsers, you’d basically just have reinvented the browser platform, but without the ecosystem of existing code and developers.
Native widgets are also just design-wise ages behind web widgets. Rounded corners and a slight blurred drop shadow? Forget it.
FFS, in 1995 styling was something the user did to applications, now it is a way for developers to mangle the fucking GUI so they can look 'unique' and 'on brand'.
Fuck this entire goddamned industry.
The rest of the computer looks like shit. The Gnome 43 file browser, for example, is an abomination of microscopic buttons. Try hunting down the "new folder" button, it's hidden under a "..." menu that isn't the hamburger menu and isn't another dropdown menu.
Macs and Windows aren't much better. I haven't used Word in ages, had to use it for something yesterday at work, and when I hit "Save As" it did seemingly nothing, after some fumbling I realized clicking "Save As" added a very unrecognizable "Save As" icon to the fucking titlebar. I have no idea whose horrible idea it was to put some buttons in the title bar and some buttons in the toolbar instead of all the buttons in one place.
Except when I change theme, it all looks nice except your shitty electron app.
Nope. I'm not making a word processor. I was trying to match the application look and feel to the product and to other applications for that product.
It might suck to you but having a graphical application look like Notepad is not what anyone wants.
Looking like notepad is not what you or whatever high-on-their-own-farts developers want. Looking consistent with all the other software on my computer is what I, and many others, want.
Sadly there are too many people like you in our industry so it will continue to suck.
None of that even applies to software used to remote control a robot and mostly used by children who's primary other computer is a mobile phone or tablet.
Largely because of people with opinions like yours. It’s not that long ago that this was not the case.
Children are not idiots and they do not need things dumbing down for them.
No but if the next door app is shinier and more colorful they will go for it over your grey buttons, and you will lose business.
[0] Excepting games, I suppose.
That's part of the problem, eye-candy sells, but carries a complexity tax with it. Oracle Forms was butt-ugly, but got the every-day CRUD/GUI job done good-enough and was quick to develop with. Oracle Forms dev's ran circles around our web devs in terms of productivity. I looked into why, and Oracle Forms just required less code and less keystrokes to make apps and apps changes. (Oracle ruined OF when they rewrote the GUI client/browser into Java from C. Otherwise, OF would still be common. I don't like Oracle the company, but OF was magical productivity.) KISS style = KISS stack.
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.
The native GUI does nothing.
If you lay out something and resize the window to be smaller, your GUI will just get cropped, and there will be buttons offscreen. That's not a good experience.
Also when you have, say, a chatroom where you have a huge box of scrolling content and then an entry area, you typically want the entry area to be constant height and the scrolling content to fill the remaining space, whereas there are other applications where you might want a percentage-based split. The native GUI doesn't know you want this. You have to somehow tell it that. CSS makes it super easy. Other toolkits make it very annoying to specify logic like this.
Where CSS falls down is anything user-resizable. For example, a split view that collapses instead of cropping a text label. The CSS "resize" property is awful.
Media queries largely address this
Those are, BTW, where CSS got a lot of its basic layout features.
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.
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.
Frameworks like React don’t do as much as you think they do wrt the paradigm itself. Most of work goes into pleasing performance quirks of both js and dom.
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.
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.
[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.
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.
Which is exactly the point—the UI is written in HTML/CSS, not the native platform language, and the high-performance modules are written in C++ and Rust, also not the native platform language.
MSHTML and XUL eventually lost into obscurity, Electron will follow their footsteps.
I invite you to consider that the converse may be true: if you can keep things performant by RIIR or even C++, it makes a great case that desktop apps should resemble web apps, with a native backend talking to a JS/CSS/HTML frontend. It does not function as a cautionary tale, but as a compelling proof-of-concept.
As usual in this industry, those that have been around long enough have already been through this fashion statement.
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...
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.
Discord (@discord): "We use electron for the desktop app, so it’s all javascript and react!"
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.
Computer power usage is not even on a blip on the chart of power usage globally. A cult would infer the usage is small. On the contrary chromium is in almost everything nowadays, even medical equipment.
The most robust graphics rendering engine is of course going to be used everywhere for graphics.
Be careful with this reasoning: even if one Electron app might run fine, what about like 10 different ones at the same time? The overhead will compound worse than native apps.
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.
VirtualBox is free and open-source software, GPLv3 license.
HTML and CSS are sane approaches to the problem of highly flexible GUI being generated and/or delivered over the network. That said, their implementations could be vastly improved (CSS has come a long way, but HTML needs HTMX/Livewire baked in).
We need to push for Wayland. With MS Windows adding in advertising, and OSX being a locked-in expensive choice, Linux desktop needs to gain ground now.
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.
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…
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.
Styling every single input to look identical on every platform does indeed waste a lot of time—but that's not native's fault, it's the "everything must be On Brand at the expense of all other concerns" people's fault.
Meanwhile I very much doubt the customer gives even a subconsious shit that your "app"'s radio buttons look identical to the (also custom) ones on your website. They probably do give a shit that they look unfamiliar compared with natives apps, so take a little more mental energy to process, and they probably do give a shit if your theming introduces any jankiness that wouldn't otherwise be there (and it very often does).
But, yes, that level of making everything look and behave identically everywhere is far easier to achieve with webtech. But you could... just not, instead.
Qt development with C++ is slow.
What are you basing that on?
Development with QML means JS anyway
That's actually only for parameters of the QML UI, which is a tiny part of working program. Actually the GUI that can be done through any library is a very tiny part of most programs. Declaring widgets and laying them out is not difficult or time consuming, there isn't much logic there.
good luck finding JS devs with Qt experience
Any competent C++ programmer can just start using javascript after a day or two of tutorials. There is no need to hire "a JS dev", you just hire a good programmer. Javascript is not that hard. Modern C++ is not even that hard, but as a language javascript is even easier.
Anyone who calls themselves "a JS dev" is probably not that experienced to begin with. Learning languages is trivial to someone with experience.
Have you ever made a GUI program with modern C++ and FLTK ? It's incredibly easy and the results are lightning quick while starting at 100KB.
It is not like you can drop by and say “Joe tomorrow you also write JS”.
Same for JS devs as it is not that they could not do c++. It is that now you require more so you have to pay them more. If you don’t - they will go to work in company where they do only JS.
Yeah, it's not something anyone considers an issue.
It is not like you can drop by and say “Joe tomorrow you also write JS”.
I've never even met a C++ programmer that didn't know javascript. Every one knew multiple scripting languages and javascript isn't that different. Where are you getting this idea that individual languages are difficult?
Same for JS devs as it is not that they could not do c++. It is that now you require more so you have to pay them more. If you don’t - they will go to work in company where they do only JS.
This view that knowing more than one language means anything is usually not held by professional programmers. My experience is that this is only an idea held by people who have just learned their first language and feel overwhelmed by learning anything else.
JS is a completely different paradigm from C++ mixing in functional programming with dynamic objects in a way that C++ simply cannot do things.
If a C++ dev wanted to learn Python, they'd pick up and read some books on the subject. Same if they wanted to learn PHP, Java, Perl, C#, or whatever. But when it comes to JS, they just try to wing it.
Their stuff kinda works, but they don't even realize that they are fighting the language every step of the way. As a result, they complain that JS is slow and the design sucks when the reality is that they don't understand, but have too much hubris to actually go back to school for a little while.
I spent much of the early part of my JS career fixing the code written by these kinds of C++ devs. While they wrote amazing C++ code, the JS they wrote was a mess. I could rewrite their code in a fraction of the LOC while making it more readable and faster too.
Where do these ideas come from? Every modern language has elements that were originally considered "functional". Good programmers will do well with any language.
What are 'dynamic objects' and what is the way that 'C++ simple cannot do thing'?
You make these claims without backing anything up.
If a C++ dev wanted to learn Python, they'd pick up and read some books on the subject. Same if they wanted to learn PHP, Java, Perl, C#, or whatever. But when it comes to JS, they just try to wing it.
Where are getting this from? Most programmers learn javascript before C++ because it's so easy to try things out in a web browser.
Their stuff kinda works, but they don't even realize that they are fighting the language every step of the way. As a result, they complain that JS is slow and the design sucks when the reality is that they don't understand, but have too much hubris to actually go back to school for a little while.
Who are you talking about? Is this describing a single person you met?
these kinds of C++ devs. While they wrote amazing C++ code, the JS they wrote was a mess
I have news for you, their C++ was probably terrible too.
Even labeling someone as a "C++ dev" or "javascript dev" is a giant red flag of inexperience.
This is the foremost proof that knowing C++ doesn't mean you know anything about JS.
JS objects are dynamic with the ability to add/remove class properties and methods or to dynamically change what class/object it inherits from all as the program executes. C++ classes are static and determined at compile time.
> Most programmers learn javascript before C++ because it's so easy to try things out in a web browser.
Most C++ programmers started programming C++ long before JS became popular. Most people who "know JS" don't actually know the language to any meaningful degree. I'm not talking about subtle things like the difference between `-0 === 0` and `Object.is(-0, 0)` or why you might use `x === x`. I mean that most can't tell me what a closure is, why you'd want to use one, or even how to use it in something like a factory. For the record, this question isn't even JS-specific, but applies to Ruby, Python, Lua, PHP, the ML family, Rust (actually just a ML with C-like syntax), Erlang, most lisps, etc.
> Where do these ideas come from? Every modern language has elements that were originally considered "functional".
JS is multi-paradigm offering imperative, OOP, and functional approaches, but because its functions inherited heavily from Scheme (I really wish Eich could have implemented scheme), it gets a lot of really nice properties.
Consider the following code (leaning heavily into the point-free side for sake of illustration)
Sure, it is pointless code off the top of my head to illustrate my point (though with some changes it could be actual code I've seen). If you'd like to counter, write this functional-style code in C++ without changing to imperative code. It'll be 10x as long and an unreadable mess.> Even labeling someone as a "C++ dev" or "javascript dev" is a giant red flag of inexperience.
I consider language design as a bit of a hobby and I've spent time with a LOT of very different languages. Even so, I only consider myself proficient in a handful of them. Even setting aside the impossible task of learning all those standard libraries completely (even most experienced Java or C# devs don't actually know the entire standard library of those behemoths), just learning the warts and weird edge cases of almost any language you can name takes at least a couple years and with large and/or convoluted languages (eg, C++ or JS) it can take many years.
You realize they're just hash maps / dictionaries right?
Most C++ programmers started programming C++ long before JS became popular.
Do you think most C++ programmers today started 30 years ago in the early 90s?
You realize you can write everything you wrote pretty directly in C++, python, lua or a lot of other modern languages out there right? I get the impression that you don't know much about modern C++ and just base what you are saying off things you have heard from other javascript programmers trying to avoid learning other languages.
That's only a conceptual idea. In reality, the JIT uses real arrays and dynamically generated structs.
You can't actually implement them directly as conceptually described anyway. You have to have a has of boxed pointers and when you get around to adding functions with types, things get really weird. The class implementation is actually much more simple in many ways (not to mention being much faster).
> You realize you can write everything you wrote pretty directly in C++
I know you can't write curried functions "pretty directly" in C++ (Python and Lua are the languages I was discussing directly and both are far better for UI work than C++). Give it a try and post the results. I'd be very impressed if it took even just twice as many lines of typical C++ code.
Have you ever used modern C++?
Though I may be misunderstanding your point.
It was promised as a better way to write cross-platform UI Apps.
"Flutter desktop isn’t there yet" https://news.ycombinator.com/item?id=34643291
If one could somehow abstract and standardize GUI elements it could unleash a lot of creativity around browser-based desktop apps. Native app development frameworks would benefit too, they could re-implement some aspects of those GUI elements natively (outside browsers). Developers would have less friction to switch from browser to native and back.
Has any new UI paradigm emerged on the web in the last 25 years? Maybe the hamburger button? Honest question, I struggle to think of any. The richest web apps are still aping desktop apps.
But I think technically it is possible to overload whatever is available and have very decent, easy to build apps and have a productive, cross platform option. Its not going to make those pushing gui limits sweat, but that is not its point.
In any case its not going to happen as the experience with standard development and adoption is quite painful
"Technically", perhaps. "Easy", no! It appears the DOM is inherently too flawed to serve GUI's well, and fixing it would likely break backward compatibility. Forcing DOM to do GUI's is possible, but turns even women bald.
Not at all, but the Dreamcast was ;-)
Speaking from a FreeBSD user's perspective: No, actually they are not. No electron binary runs on FreeBSD because Electron is based on chrome, and some of the linux sandbox syscalls needed for chrome are not emulated. So when things move from a real native Linux app to Electron, they become unusable for me.
Not to mention that Electron is bloated compared to a native app..
I'm madder about google not allowing DartVM to be ported to FreeBSD because they "want to keep repo free of platform-specific code" while have code dedicated to Fuchsia, Chrome OS and Android-specific code in there.
[1]: https://www.freshports.org/editors/vscode
https://www.freshports.org/devel/electron19/
I've tried and failed to run slack and spotify. I've never tried VSCode because emacs is my IDE :)
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.)
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.
Well, there should be. It's a big gap in our current standards. DOM is missing roughly 15 common GUI idioms, and its text positioning reliability is broken and likely can't be fixed without tossing backward compatibility. More on these gaps: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
/? 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)
If you start with UI toolkit not dealing with any of the above points, you are limited in what you can do. Maybe you don't need the first two, that's fine, this is where electron is. But if you have to do a content creation application (Maya, 3DSMax, Blender, Unreal Editor, etc.) - you need to support multiple windows and docking windows in other windows - preserve layouts, etc.
And then Remote Desktop, because you may need someone to assist and log in to the machine, or work remotely (especially today), and if RDP does not work (sorry, but there are some pure OpenGL toolkits), then it's a loss.
OS X is a dream to develop for. It really is amazing.
Windows, is honestly, not terrible. I don't know anything about C# or Winforms or whatever modern Windows GUI apps are created in, I used Win32 API and MFC. They may have been a little kludgey, but they got the job done. Lots of documentation and code out there, like 20 times as much for the Mac.
Now, Linux... I've tried. Haven't gotten far. Both Qt and GTK.
Anyway, it's obvious why everything is written in Electron and friends. People are familiar with it. Everyone's a web developer. It's cross-platform. It's a big deal to learn another environment. Why wouldn't you want to be able to run on Windows, web (phones/tablets), Linux...?
Tried X11 directly on Linux before I decided that it was just too difficult. Switched to QT, and there were a million bugs and quirks that forced me back to just Windows GUI development.
JavaScript/HTML GUI frameworks along with embedded browsers have been the key to cross platform compatibility without all the fuss. But it seem to also have become the death of good real-time and responsive UIs.
Yet even as this happens and HTML/CSS/JavaScript rises that doesn't mean that there is a decline in the making of desktop applications. I think that desktop applications made with native technologies are being built as much as ever, its just that the industry as a whole has grown to accommodate the vast influx of new HTML/CSS/JavaScript developers. For example, my favorite applications are build in Swing (IntelliJ and related projects) or in QT.
> Just for completeness I should mention Linux, it is the best computing platform to happen to the world and should be admired in every way – except one! the desktop/UI sucks, its awful in almost every way
I say that KDE is awesome. So that is just your opinion, and not everyone agrees.
> Developing desktop apps in 2022 is essentially an HTML/CSS/JavaScript endeavour
That does not follow.
> 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.
That is not my experience. Visual Studio Code doesn't seem to run as smoothly as I would like. Meanwhile every C++/QT application I have run works perfectly. Where are you getting this from?
OTOH, it is not a beautiful, lovely app. The UI does look like 1999. But it works fabulously.
(ref https://sourceforge.net/projects/wsjt/)
I’m in a bit of a unique position where I work on both a Qt app using Qt Creator and a React app using VS Code. Qt Creator has crashed on me numerous times, has slower initial loads, regularly has weird visual bugs, and is overall much less enjoyable to use.
I develop on a modern windows computer. Maybe Qt Creator performance wins against VS Code on Linux? In my experience, VS Code does not perform as well on Linux as it does on Windows or OSX.
But I think that QT creator should have a faster initial load then Visual Studio Code, because the later has to open up an entire browser render-er to work. QT creator opens instantly on my system, but visual studio code lags for a second. The weird visual bugs might indicate something else wrong with your system which is messing up the program. A picture might help us to find what the bug is so we can fix it if there is a serious problem with QT creator.
As for the less enjoyable to use thing, there isn't much I can do about that. Visual studio code is probably more fun to use, and React isn't too bad either. Using React can be a joyful experience indeed. But enjoyment issues aside, I think that a good C++/QT based application should have a performance advantage over one made with HTML/CSS/JavaScript and Electron. Visual studio code can be more enjoyable but still perform slightly less well, because it doesn't have to make a difference to the end user that it does things a couple milliseconds slower.