That's what always annoys me. I have a computer that's easily 100x or 1000x more powerful than my 1995 desktop yet so many actions have noticeable lag.
Like, try it, resize outlook right now (just stretch the side left and right). You'll see so much jank and jitter. How is something like that not instantaneous?
When you resized a window on classic Mac OS, your program had to actually like, draw the new window. Your program is spinning in a loop listening for events, you get a window-resize event. So you allocate space for the new bitmap, calculate what you need to display within the enlarged view, and then draw it. Did the user drag another window over your window, and then drag it away again? You get an event for that. Gotta draw what was there all over again.
This is all very close to the metal. On early 68K Macs, this is driven by QuickDraw, some very tightly coded assembly routines in ROM. Invoking them is only 2 bytes of code, as they're simply CPU opcodes (trap instructions). Render this string at this point size with this font at this X, Y location. Redraw the menu bar. Draw a rectangle. And so on. If you sequence these Toolbox invocations correctly, as a great master programmer of coroutines who never mistreats a handle as a pointer, you can render a complex scene with hundreds of polygons and a full screen of text in 200 milliseconds at 8 MHz.
But it takes thousands of lines of hand-holding the machine to do it.
Today, all of this is typically handled by instantiating a window object which draws into a private framebuffer which the system composites. That right there is tens of megabytes of RAM overhead. Then you use a thread to handle the UI and a thread to draw and etc. There's almost no boilerplate to just show a window. Perhaps one line of code. And it doesn't get overwritten by intrusive neighbour windows. Creating frameworks that can do all that bookkeeping in a flexible and general way (don't forget you want to be able to render vector fonts for any Unicode language) has a tremendous overhead.
Well, you see, they've traded end-user performance for productivity. This is why it only takes a team five times as large to deliver the same functionality as a comparable program from the 1990s, and that team can make a buggier initial release in merely twice the time.
There might be something in what you are saying but it's not really like that.
The current macOS is humungous, kernel aside. There is a variety of systems running under the hood (Spotlight, fsevents, Apple Events, duet, launchd, MIGs, XPCs, caches, endless network services, launch services, anti-malware background programs, AppleID agents, diagnostics, cloud/AppleID integration, auditing, RAM compression, energy management, backups, filesystem snapshotting, COW,.... not to mention that huge OS inside the OS that is the browser) that is more than a surgeon can know about the human body.
Of course most of that is spying on you and telemetry... But you just have much more features these days and stability and security increased a lot. If that is not added value for you just work on one of those "minimal" OSes that appear from time to time. I guarantee you that you will miss a modern "bloaty" OS in no time.
One might expect all those extra services and capabilities would make application development faster, though. Less for application developers to worry about, since the OS and built-in services do way more than a typical 1990s OS—and any that aren't helpful, ought at least not be getting in the way. So, sure, the situation for our industry's even more embarrassing than my original post implied.
However in support of Apple's M1/M2 macs, I dont have this problem so much!
Apart from Electron based apps...
Which is why I find the wide spread love of VS Code so befuddling!
It's fine.. but so laggy when redrawing windows, switching tabs and so on!
Maybe it doesn't seem slow when in isolation, but compared to a GUI editor like Sublime Text, it's very noticeable!
But yes - your broader point stands and drives me nuts!
Somewhat gone are the days of upgrading your computer and everything being noticable faster because the software is the same!
(to be fair, the M1 upgrade from Intel was impressive)
These days to have a decent experience (as a self confessed geek with high standards) you need an M1 Mac or on Linux and Windows a modern CPU, decent GPU and as much RAM as you can fit!
I have the same feelings about VS Code. JetBrains is working on a competitor (Fleet) that is running on the JVM and renders using Skia. But everywhere I keep seeing it get flack for not being web-based...
+1. I can't speak to Windows but I suspect it's similar: if you're running a well-implemented native app (ex. Pixelmator) the responsiveness is entirely there and in fact significantly better than it was in the 90s. Even fairly graphically heavy apps have no issues resizing and otherwise being real-time interactive.
I would hazard that the vast majority of "jank" you see in desktop apps today is due to cross-platform code. A large portion of this is webviews (ex. Slack), but some of it is also poorly-implemented shims between the platform's native APIs and shoehorning that into some cross-platform library (ex. Photoshop).
I recently used a legacy win32 app at work, on a windows 10 laptop. It looked old, even though the buttons etc got styled the win10 way. Since the app had some issues, I wanted to rule out a compatibility problem with modern Windows, and ran the app in a windows XP VM on the same laptop. Unfortunately the same issues arose, but I was really surprised by how snappy the app felt. Everything was just immediate, sub-windows popped up instantly. Sure, the machine was an order of magnitude faster than the typical XP machine back in the day, so it's not an apples to apples comparison, but still it was one of these revelations that we just seem to be taking one step forwards and at least one step back every time we improve something.
Modern macOS is a significant counterexample to that claim. Most of it is janky. Zooming and dezooming the Finder is not something a 2.5 years old MacBook Air (€1200) can keep up with smoothly, for instance. Opening a Save dialog takes over 3 seconds, and expanding/collapsing the file explorer in it is comically janky.
That's simply not true. A 2019 MacBook Air has no trouble with any of these things. If you're having trouble with these, something is seriously wrong with your computer.
Ah, I misunderstood what you were referring to. Now that I understand, I'm less surprised. For some reason I was thinking File I/O.
The Early 2020 MacBook Air is a joke from a CPU/Graphics perspective - even compared to other Intel Macs.
I still think something's wrong with your computer, as I have worked with multiple of that model and they weren't nearly this bad (even accounting for screen recording) - perhaps your cooling is worse?
Is this any better in performance? Looks like rust bolted to a system webview (chromium in the case of Windows) instead of electron (chromium bolted to v8)
Yup that’s the answer, and cyber security, we had to add thousand of code lines in order to circumvent login properties and such, in order to make software more secure (and less private)
Sure, under the hood Electron is powered by Chromium V8 (which also powers Node.js), which is written in C++. But that is just the basic packages and services available to all Electron desktop and Node.js apps.
It's not slow. It's just that modern OS's redraw at every intermediate size between the initial size and the final size. The name of the setting in Windows is "Show window content while dragging", you can disable it and all your windows will be 100x snappier than Mac OS 9.
> Like, try it, resize outlook right now (just stretch the side left and right). You'll see so much jank and jitter. How is something like that not instantaneous?
Outlook is old, old code and still does things network I/O in the same thread as window repainting. I wouldn't treat it as a reference of anything other than how much Microsoft has struggled with the baggage from a bunch of mistakes they made in the 90s.
If you use Safari, Apple Mail, or almost any other macOS app, it is instantaneous — and unlike the older Mac apps like the Finder which did the rubber-band overlay until you released the mouse button, that means things like Safari seamlessly reflowing the entire Mac OS 9 emulator the whole time.
See, the whole problem is that you're running Outlook, probably on Windows. A light-weight Linux desktop is not slow. If anything it's a bit faster and snappier now than those older systems were on their historical hardware, since it can save a lot more disk I/O via caching in RAM.
Some of that you can tune down as it’s trying to redraw at every single step in between.
Sometimes there are accessibility options that speed it back up (don’t redraw until mouse let go) - I know you can turn off animations but not sure you can disable that one.
That's a distinction without a difference. Running JS is slower than native. The user of JS cares about the real world speed of emulating a quadra machine, which is shown as very slow at this webpage.
This conversation went on a tangent. It started off with people complaining about modern GUIs then moved onto Outlook and then someone rushes to blame JavaScript / Electron. JS runs 50-80% as fast as native, which is more than fast enough thanks to Moore's law, for virtually any GUI application. The web has a reputation for being slow, thanks to a traditional lack of GPU acceleration as well as 25 years of legacy code attached to its Document Object Model, that are pretty gnarly for browser vendors to deal with. That has nothing to do with JS itself.
The MacOS 9 demo as shown, is impressive, but it is far from optimized, given that it is a side project. But it's impressive all the same that it's emulating a full Mac environment in the browser. Read the developer's own comments on it: https://blog.persistent.info/2022/03/blog-post.html
The discussion was to answer, "And why is everything just so slow!"
> The web has a reputation for being slow, thanks to a traditional lack of GPU acceleration as well as 25 years of legacy code attached to its Document Object Model, that are pretty gnarly for browser vendors to deal with. That has nothing to do with JS itself.
That's not exactly true, though, as many discussions here on HN have demonstrated. The web is not slow due to, "a traditional lack of GPU acceleration." The DOM is the execution environment of JS in the browser. This isn't a discussion about JS in any other environment.
While you may have a vested interest in JS, that doesn't change its properties. Please, let's get back to the actual discussion.
That's what always annoys me. I have a computer that's easily 100x or 1000x more powerful than my 1995 desktop yet so many actions have noticeable lag.
Like, try it, resize outlook right now (just stretch the side left and right). You'll see so much jank and jitter. How is something like that not instantaneous?