Hacker News Reader

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.

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

Anecdata; mIRC is fast, snappy and uses barely any RAM compared to Slack.

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.

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.

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

> "I have been involved with software development for nearly 30 years now"

Apparently not. You'd think the author would clearly recall the scenario you described.

One point that came with the web stack is the entire "We won't optimize for anything, we just want to release quickly. Disk space is cheap, unused RAM is wasted RAM, every PC has at least 8 cores" (Maybe a bit hyperbolic, but still somewhat right imo) And this is something that has to be reverted. Sure I don't expect every application to just use C/C++/Rust with carefully hand-optimized algorithms like back then when the C compilers were not that good at optimizing, but at least I would expect applications to be aware of weak hardware

Perhaps they could even start to realise that using their application isn't the entire purpose of your life and you might also want to run other stuff as well.

Have you ever even tried any of the alternatives? I've scoured the landscape: Gio, egui, Iced, Xilem, imgui, Bevy UI, Qt, makerpad, all of them. Some interesting ideas and promising implementation but literally nothing even comes close to the productivity of a good js stack. Need cross-platform, embed video/youtube, embed (google)maps, custom design language, accessibility, you name it js is the only option here. I'd love to have something else but option just isn't there.

Agree on the topic of performance. Try joining the OpenAI discord channel and you'll see Discord slowly die and become unresponsive. Or VS Code being unable to read a 100 MB file. Or Teams slowly lagging out of existence when you open a large OneDrive folder inside it.

Just about any Electron app I know of can't do large tasks of any kind. The web platform is not built for this kind of work.

> The web platform is not built for this kind of work.

It requires clever tricks we learned in the 80's.

You can't keep the whole state of the application in a puny 64K of memory. With luck, you can keep about 30K of it, provided the app is small enough. What you need to do is to just load what you need to display, and get rid of the rest as it fills up the memory.

And beware of JavaScript arrays - they are a lie.

Most of the time an application built using web technologies is slow, it's not because the web's UI layer (HTML/CSS) is intrinsically slow.

A desktop app written in Tauri that punts most of the heavy data processing to Rust with a UI layer written in well-optimized React or Solid.js is really plenty fast. In practice what we get with most Electron apps is not especially well written React with frequent coarse grained re-renders, inefficient data processing, frequent allocations causing GC pressure, and excessive JSON RPC. The problems here aren't HTML/CSS + JS for basic event handling, it's everything else about how the software is developed.

I don't think HTML/CSS are all that good at making fancy layouts and designs. I find it quite common to have to fight my browser to get it to display things the way I want. CSS in particular in particular keeps massively growing because people come up with so much stuff that CSS can't really do. What makes the browser a great platform to develop complex designs is the development experience. Browsers have by far the best dev tools of any platform and most modern frameworks come with instant hot reload. It doesn't hurt that web apps are build with the same tech as websites either. Lot's of synergies.

I used to agree, but once I treated modern CSS as a proper language and bought a book on it I changed my mind. I love CSS grid.

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.

Could it be he's confusing electron with native?

VSCode (Electron) is faster than most native desktop IDEs.

Easy enough to disprove those that say browser based apps are inherently slow. Modern JS is significantly more optimized and faster than most other loosely typed runtimes, e.g python.

WebGPU will just close the gap further.

Anyway you can write highly optimized native code and deploy to browser via WASM anyway. No reason at all to deal with OS quirks. WASM compilation will get better and better over time

And yet every few days I look at my running processes to see what's chewing up all the memory and CPU and it's either VSCode or Slack. Kill them all and restart with all the same windows open and everything goes back to fine. I don't consider this good performance. (Note: I have never experienced this with IntelliJ)

I 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

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

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

VSCode has hardly any functionality a modern IDE has unless you had dozens of extensions and then it slows down

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.

Where is the slowness?

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

All of what you just described is made possible by rust-analyzer not VS Code.

Exactly my point.

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.

But even if you don't use any heavy plugins, it's slower than sublime text.

And most who used SublimeText left it for VSCode, myself included.

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

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.

WebGPU is based on how modern 3D APIs were in their version 1.0 back in 2015.

Hardly reducing any gap.

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.

vscode can handle larger files than most text editors. case closed.