The crazy thing is that all these web apps also do a fraction of the things that the native apps used to do. They’ve somehow managed to strip down all the features while making the apps slow and bloated. Watching Microsoft’s To-Do blog is comitragic. Elon Musk will be living on Mars before the Microsoft tools allow you to schedule todos by dragging them to the calendar like Outlook has done since what, 98? (You can drag a todo from the web sidebar to the calendar now—but it somehow doesn’t actually schedule the due or start date in the todo itself or even have any link back to the todo.) And I feel like that’s one thing that’s different now. I also complained that Word 97 was a slow bloated big compared to Word Perfect, etc. But back in the day there was feature bloat. Now, everything is both slow and and non-functional.

I have to assume that it’s a structural thing with the industry. Machine learning, big data, security, etc., has become the hot areas, so all the “A” teams have migrated over there. I hear Apple is having trouble even getting people to do kernel work on MacOS.

They won't bring in a ton of cash, but I can continue to make beautiful apps that are fast, focused, and respect the user's time and computing resources.

It's been fun to work a bit closer to the metal than I've been with JS for the last few years. Made about 50 sales so far. Can't imagine it'll make me rich but maaan it makes my video editing way faster :D

For tech, I'd consider both Cocoa + Swift and SwiftUI as candidates for UI components, on a case-by-case basis. Swift is not my favorite language (feels like I have to use Xcode; have yet to try out the JetBrains IDE), but it gets the results I want. Perhaps in the future, we can use Rust in a more ergonomic fashion to talk with native UIs.

Honestly, I'd love an ObjC-like language that interops with ObjC and has strong static typing with a dynamic typing escape hatch for metaprogramming.

http://fox-toolkit.org/

The FOX codebase isn't terribly modern, as it's older than the standard C++ concurrency machinery, but it works.

It depends on the target market for your application I suppose - if your target won't be happy unless they have html/CSS or similar animations, then using something with low latency isn't going to make them happy.

Personally I don't mind the Windows 98 look, it strikes me as clean and no-nonsense. Everything is clear and high-contrast. Unlike with many 'flat' themes, it's generally clear what's clickable. I realise not everyone likes the Windows 98 look though.

If someone is serious about developing fast GUI apps, trading off on themeability is the kind of thing they should consider. As you say, FOX really is fast. I presume this is because of its uncompromising hard-coded native-code-only approach - it's just a C++ codebase. All the drawing operations are implemented directly in C++. Unlike Qt, there's no JavaScript. Unlike JavaFX, there's no CSS. It's all just C++.

Perhaps a GUI toolkit could add themeability without any performance impact by implementing it as a compile-time abstraction.

> depends on the target market for your application I suppose - if your target won't be happy unless they have html/CSS or similar animations, then using something with low latency isn't going to make them happy

Right, but mattgreenrocks said fast, focused, and respect the user's time and computing resources, presumably in contrast to current norms.

Also, if I click the "Switch to New Outlook" button, it says that it can't copy over my custom IMAP accounts for work. I would think that supporting things besides exchange or gmail accounts would be something they would do before releasing a new version.

There have been a bunch of interesting rumors that Microsoft is planning to hollow out the insides of Outlook Desktop (anything that isn't nailed down to big corporate contracts and their extensions), and directly replace those guts with Web Outlook via React Native or something like it.

Really, a web app wrapped in a desktop app would be fine if it could perform better. I don't even need good, just better.

But anyway in the enterprise sector, it doesn’t matter whether an app is web or native, it will be slow regardless lol.

This could really be applied to any good or service where the purchaser is not the end user. For example, in the U.S. dealing with your health insurance company is a nightmare, and a lot of that has to do with the fact that it's your employer who's the customer. If the health insurance company treats you badly, you can't go with another provider, so they're free to offer terrible service so long as they don't piss of your company's HR department who decides which health plans to go with.

If there is UI, UI responsiveness matters for employee output.

Research that has been done on this topic suggests that increase in UI latency non-linearly decreases user productivity, whith the ultimate effect on the cost of doing business.

And that has been known for decades - take a look at the "The Economic Value of Rapid Response Time" from 1982:

https://jlelliotton.blogspot.com/p/the-economic-value-of-rap...

It's puzzling to me why businisses still don't prioritize UI latency, but it's not a rational decision.

Perhaps it's just human nature, as hinted in the linked article:

"...few executives are aware that such a balance is economically and technically feasible."

I only wish this were true; then value propositions for software could climb a value ladder. The challenge is business' are not standardized beyond some very basic functions, and new standardization comes at a brutally high cost (time and expense). So I see where office productivity has settled on Microsoft Office (though even there, I see huge fragmentation between versions, how people don't use styles, how most people have no idea of pivot tables in Excel, etc.), and we've pretty much just crawled along at a snails pace since then.

If anything, judging by how little I can transplant of business processes that emerge around software from one company to another, and how much those processes mutate over time, I would assert software standardization is getting worse, because getting businesses to standardize even when moving to the cloud has been a bigger challenge than I anticipated.

I've seen devs arguing this, though IMO that is more the devs speaking out of resignation and learning to say the right things rather than the truth.

- User visits website - downloads binary (preferably small size, use an appropriate language and cross-platform graphics library) - launches it (preferably without installation) - Perhaps creation of a local storage directory on the file system is needed the first time. - and voilà!

What would be the main obstacles to such a workflow? Are there projects who try work like this?

On some days, I manage to type faster than XCode can display the letters on screen. There is no excuse for that with a 3 GHz CPU.

And yes, 200ms seems plausible to me:

Bluetooth adds delay over PS2 (about 28ms). DisplayPort adds delay over VGA. LCD screens need to buffer internally. Most even buffer 2-3 frames for motion smoothing (= 50ms). And suddenly you have 78 ms in hardware delay.

If the app you're using is Electron or the like, then the click will be buffered for 1 frame, then there's the click handler, then 1 frame of delay until the DOM is updated and another frame of delay for redraw. Maybe add 1 more frame for the Windows compositor. So that's 83ms in software-caused delay.

So I'd estimate a minimum of 161ms of latency if you use an Electron-based app with a wireless mouse on a DisplayPort-connected LCD screen, i.e. VSCode on my Mac.

You type in a letter and that starts off a cascade of computations, incremental compilation, table lookups, and such to support syntax highlighting, completion, etc. and then it updates whatever parts of a dynamic UI (the user decides which widgets are on the screen and where) need to be updated.

It almost has to be done in a "managed language" whether that is Emacs Lisp, Java, etc. and is likely to have an extension facility that might let the user add updating operations that could use unbounded time and space. (I am wary to add any plug-ins to Eclipse)

I usually use a powerful Windows laptop and notice that IDE responsiveness is very much affected by the power state: if I turn down the power use because it is getting too warm for my lap, the keypress lag increases greatly.

Table lookups for syntax-highlighting can't be backgrounded, but they should be trivial im comparison to stuff like compilation, intellisense, etc.

From a UX perspective, I can see doing simple syntax highlighting on the UI thread...so long as it is something with small, bounded execution time. I don't quite get why completions and other stuff lags the UI thread, as it seems obvious that looking that information up is expensive. I can't tell if that is what's happening, or there's something more going on, such as coordinating the communication between UI/worker threads becomes costly.

I've seen it in a bunch of IDEs though, especially those in managed languages. You're typing, it goes to show a completion, and then....you wait.

Surely VGA would have more latency than DP for an LCD? It's gotta convert from digital to analogue and then back to digital again at the other end.

Is the overhead of the protocol really greater than that? (genuine question)

But to answer your question, digital to analogue and analogue to digital conversions tend to be so fast that you don't notice. It is more of a convention thing that most VGA devices will display the image as the signal arrives, which means they have almost no latency. DP devices, on the other hand, tend to cache the image, do processing on the entire frame, and only then start the presentation.

As a result, for VGA the latency can be less than the time that it takes to send the entire picture through the wire. For DP, it always is at least one full transmission time of latency.

If the required video data rate is lower than the link symbol rate the micro packets are stuffed with dummy data to make up the difference, and up to four micro packets may be sent in parallel over separate lanes, so some buffering is required, but this need only add a few microseconds of latency, which is not perceptible. Of course it's possible for bad implementations to add more, but the protocol was designed to support low latency.

In that case, I'm guessing the latency is coming from the fact that most LCD screens are caching one full image so that they can re-scale it in case the incoming video resolution isn't identical with the display's native resolution.

I vaguely remember there being an experimental NVIDIA feature to force scaling onto the GPU in hopes of reducing lag, but not sure that ever got released.

Where CRTs do have an advantage over LCDs is response time, which is generally a few ms even on the best monitors but basically nonexistent on CRTs.

But overall, a good monitor is only about half a frame worse than a CRT in terms of latency if you account for response time. At higher refresh rates it's even less of an issue; I'm not aware aware of any CRTs that can do high refresh rates at useful resolutions.

Got my numbers by glancing at a few RTINGS.com reviews: https://www.rtings.com/monitor/reviews/best/by-usage/gaming

I'm sure Id notice if typing had that much lag on vs code. I am using manjaro Linux but I can't imagine that it would be much faster than osx.

https://humanbenchmark.com/tests/reactiontime

I get electron or MS have optimised the typing path. I don't click that much in VS Code so I don't think its ever bothered me.

Months ago I noticed picom causing issues with keynav I was too lazy to find a (proper, pretty-window-shadow retaining) fix for, so I just killed it and — while I can’t confidently say I remember noticing a significant lag decrease — I can say I don’t really miss it (and my CPU, RAM, and electricity use almost certainly decreased by some small fractions).

* - actually it could be Wayland but doesn't work with my old window manager config.

If you are using Android, you are in luck.

1. Open Settings > About Phone, Tap the build number 7 times (Or google other methods to open Developer menu for your phone model)

2. Go to Developer options -> Drawing

3. Set all animation scale to 0.5x

You'd be amazed to find how fast the phone appears

But even that's overkill for modern phones. I just tried turning off animations entirely, and things still feel pretty much instant, despite the phone being a few years old at this point.

In any case, the animation shouldn't take longer than it takes to start the program.

It help a lot in that "computer user bill of rights" issue that you start to worry at some point that the button press wasn't registered and might then mash the button with unpredictable effects.

(e.g. you might get more customer satisfaction from a crosswalk button that doesn't do anything at all except 'click' instantaneously)

These settings completely disabled my on-screen home button and other UI elements, and setting the anim scale back to 1.0 and rebooting did not fix that, no more home button for now.

I probably have to reset the phone, did not find any further info so far on how to fix it (pointers, anyone?). But the UI seemed snappy indeed at 0.5 ...

Edit: "other UI elements" including e.g. the Tab switcher in the Lightning browser. The widgets are all displayed, but totally unresponsive.

https://www.youtube.com/watch?v=nn2FB1P_Mn8

The researchers telling me I don't notice 100ms delays are smoking something. Yes, human reaction time is 200ms on average but we process information much faster than that. Moreover, the delays make it impossible to do "learned" chains of actions cause of the constant interruptions.

Hackers typing insanely fast and windows popping up everywhere in movies? The reason why that looks very unrealistic is just that our tools do not behave like that at all.

You can absolutely detect when your ping gets above 25ms even. It can't be missed.

> Hackers typing insanely fast and windows popping up everywhere in movies? The reason why that looks very unrealistic is just that our tools do not behave like that at all.

Right on. That's why, even though I have an insanely pretty Apple display (on the iMac Pro) I move more and more of my day work to the terminal. Those movie UIs are achievable.

Related: I invest a lot of time and energy into learning my every tool's keyboard shortcuts. This increases productivity.

What task is actually being measured here matters, too. For example, while it is true that humans cannot generally react faster than 100ms or so; most actual skills being tested by competitive gameplay are not pure reaction tests. They are usually some amount of telegraphed stimulus (notice an approaching player, an oncoming platform, etc) followed by an anticipated response. Humans are extremely sensitive to latency specifically because they need to time responses to those stimuli - not because they score really well in snap reaction tests.

Concrete example: the window to L-cancel in Melee is really small - far smaller than humanly possible to hit if this was purely a matter of reaction times. Of course, no player actually hits that window, because it's humanly impossible. They don't see their character hit the ground and then press L. They instead press L several frames in advance so that by the time their finger presses the trigger, their character has just hit the ground and made the window. Now, if I go ahead and add two frames of total lag to the display chain, all of their anticipated reactions will be too late and they'll have to retrain for that particular display.

Yeah this resonates for sure. Multiple times per day i tell citrix ctrl+alt+break, down arrow, return (minimise full screen citrix, go to my personal desktop) and about 50% of the time an app inside the citrix session will be delivered the down arrow, return keystrokes :-/

Surprisingly, I find MS Windows native stuff to be head-and-shoulders the best at this queuing.

These days I see people casually adding network hops to web applications like it's nothing. These actually take multiple milliseconds in common scenarios such as cloud hosting on a PaaS. (I measured. Have you?)

At that point it's not even relevant how fast your CPUs are, you're blowing your "time budget" in just a handful of remote function calls.

If you stop and think about it, the "modern" default protocol stack for a simple function consists of:

    - Creating an object graph scattered randomly on the heap
    - Serialising it with dynamic reflection 
      ...to a *text* format!
      ...written into a dynamically resizing buffer
    - Gzip compressing it to another resizing buffer
    - Encrypting it to stop the spies in the data centre
    - Buffering
    - Kernel transition
    - Buffering again in the NIC
    - Router(s)
    - Firewall(s)
    - Load balancer

then the forward -- and -- backwards stack -- again -- for the response

If this isn't insanity, I don't know what is...

What you are doing is like a machinist complaining about a carpenter not measuring everything in thousands of an inch or micrometers. The reality is that wood is soft and can shrink or grow. It's maybe not the best material but it's good enough for the job and it's cheap enough that you can actually afford it.

With web content it’s the exact opposite. Every time you are a bit lazy, and add another mushy, poorly optimized dependency, the cost is paid by every one of your users.

The better analogy is that the web is like an assembly line that serves content. Do you want wooden equipment with poor tolerances making up that assembly line which takes twice as long and occasionally dumps parts on the ground, or do you want a well-optimized system working at peak efficiency?

History and inertia also are nearly synonymous with "easier to use" in this context.

Plain HTML renders several order of magnitudes faster than post-load JS rendering, and yes, it is noticeable, especially if you account for variable connection speeds.

Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows.

Well, "several orders of magnitude" is a bit much, but the point stands.

However, that's only during the initial load. After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again. If done properly (and that's a big if!), and where appropriate, this can be much faster.

> Most web devs develop on localhost and test on some of the best connections you can get today, leaving network performance testing as an afterthought at best... and it shows.

Very true! And on beefeir CPUs/GPUs, more RAM, faster storage etc.

For the last couple of years, I've been careful to develop on "midrange" hardware, exactly so I can spot performance problems earlier.

Primary and by far most frequent use case.

> After that, JS can just keep modifying the DOM based on the data retrieved from API, and never download HTML and construct new DOM again.

And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.

Anyone who doesn't support JS to the level you want? Well, fuck those people, let them make their own wheelchair ramps.

> If done properly (and that's a big if!), and where appropriate, this can be much faster.

A big IF, indeed.

For "application paradigm" my points stand. That's where JS is appropriate. I did say "where appropriate", after all.

> Primary and by far most frequent use case.

In document paradigm.

> And then you can never return to the same page again, it's gone into the either, and the Back button doesn't work properly.

Not if the client-side routing is done properly. I did say "if done properly".

> Anyone who doesn't support JS to the level you want?

With modern transpilers, you can produce lowest-common-denominator JS. Essentially you are treating JS as a build target / ISA.

> Well, fuck those people, let them make their own wheelchair ramps.

What's the alternative? They can download a native app, but that doesn't work for everyone either (both from the developer and the user perspective).

And not only is the stack you describe full of delays, several of the layers are outside of the control of the software in question and can just… fail! Sure, there are cases where I need my software to communicate with the outside world, but I get furious when some page with text on it dies because somewhere in a datacenter some NIC failed and thus the shitty webapp I was viewing fell over.

You were motivated by submitting a cool demo, they are motivated by not being fired after deadlines. An additional network hop is nothing compared to not shipping.

When I look at the massive backlog of requests from my users, not a single one is "speed."

I've recently come across several such applications that were "split up" for no good reason. Just because it's the current fad to do the microservices thing. Someone liked that fad and decided that over-architecting everything is going to keep them employed.

To clarify: This was strictly worse in every possible way. No shortcuts were taken. No time was saved. Significant time and effort was invested into making the final product much worse.

Can you tell what is your occupation? Are you dealing with assembler level programming regularly?

It just grinds me gears that we have all these wonderfully fast computers and we're just throwing the performance away.

My analogy to customers where I consult is this: What you're doing is like buying a dozen sticks of RAM, and then throwing ten of them into the trash. It's like pouring superglue into all but a couple of the switch ports. It's like buying a 64-core CPU and disabling 63 of those cores. It's like putting some of the servers on the Moon instead of next to each other in the same rack.

Said like that, modern development practices and infrastructure architectures suddenly sound as insane as they truly are.

To be fair, profiling is way more difficult than it was in the days of single-core local applications. A single-threaded single-machine application means you can get a very clear and simple tree-chart of where your program's time is spent, and the places to optimize are dead obvious.

Even if you're using async/await but are basically mostly releasing the thread and awaiting the response, the end-user experience of that time is the same - they don't give a crap that you're being thoughtful to the processor if it's still 0.5s of file IO before they can do anything, but now the profiler is lying to you and saying "nope, the processor isn't spending any time in that wait, your program is fast!".

Not if you graduated from the printf school of profiling[1].

Measure the time when you start something, measure the time when you finish, and print it. Anything that takes too long gets a closer look.

[1] unaffiliated with the printf school of debugging, but coincidentally located at the same campus.

Write a riddle for a CPU with 100% cache miss rate, confusing the prefetcher to clog the memory bus, and enforcing a synchronous memory access. Such thing is very likely to run literally with an MCU speed on an x86 PC CPU.

Nobody wants slow software, its just cheaper, in upfront and maintenance costs. Going with analogies, its like a race car mechanic complaining that a car is using like 3 cylinders where it could have 8. Sure but some people have other priorities I guess.

In theory yes, in practice this almost never happens. 95% of the teams just quickly mash the product together and peace out before anyone notices what mess did they make. And then you have some poor Indian / African / Eastern European team trying to untangle and improve it.

Seen it literally tens of times over a course of 19 years career.

> Nobody wants slow software, its just cheaper, in upfront and maintenance costs

That is true. But nowadays it's more like taking a loan from the bank and running away to an uninhabited island to avoid paying it off.

Much of my work is in highly parallelized computing (think Spark across thousands of nodes) processing 10s or 100s of TiB at a time with declarative syntax. It's super cool. Until someone decides they're going to use this one line expression to process data because it's just so easy to write. But it turns out doing that absolutely destroys your performance because the query optimizer now has a black box in the middle of your job graph that it can't reason about.

Bad practices like that occur over and over again, and everyone just figures, "Well, we have a lot of hardware. If the job takes an extra half hour, NBD." Soon, you have scores of jobs that take eight hours to run and everyone starts to become a little uneasy because the infrastructure is starting to fail jobs on account of bad data skew and vertexes exceeding the predefined limits.

How did we get here? We severely over-optimized for engineer time to the detriment of CPU time. Certainly, there is a balance to strike, no doubt. But When writing one line of code versus six (and I'm not being hyperbolic here) becomes preferable to really understanding what your system is doing, you reap what you sow.

On the plus side, I get to come in and make things run 5x, 10x, maybe even 20x faster with very little work. It sometimes feels magical, but it would be preferable if we had some appreciation for not letting our code slowly descend into gross inefficiency.

But time and time again I see that projects with a fast “enough” interfaces and flexible systems win out on more specialized, faster ones. And I hate that but here we are. Sometime we see a really performant piece of software hit the sweet spot of functionality for a while (for example sublime text) but then get overtaken by a fast enough but more flexible alternative (vacode)

Eastern European coders are highly competent, they did magic back in the day with just a ZX Spectrum.

Very few people enjoy producing junk, but management (and customers) often demand junk today rather than quality tomorrow.

>> most of those "primadona devs", as you call them, would much prefer to write well-designed programs cleanly coded

Most of them - yes. But there's a non-negligible chunk of them who are too careless or incompetent to care about quality - they've been around long enough to gain knowledge about project and get Vice-President title(inflated ego included).

It is especially visible in big banks (I suppose it's typical for other big non-tech corps as well) where tech culture is generally on poor side.

edit: grammar

Given the chance I'd likely collect a fat paycheck and bail out at the end of the contract as those other people did. But that attitude is responsible for the increasingly awful mess that modern software is becoming.

Almost everyone is at fault, me included. The perverted incentives of today's world are only making things worse.

I mean the web stack itself was never designed per se. HTML is essentially a text annotation format, which has been abused to support the needs of arbitrary layouts. The weakness of CSS is evident by how difficult it has been to properly center something within a container until relatively recently. And Javascript was literally designed in a week.

And then in terms of deploying web content, you have this situation where you have multiple browsers which are moving targets, so you can't even really just target raw HTML+CSS+JS if you want to deploy something - you need a tool like webpack to take care of all the compatibility issues, and translate a tool which is actually usable like React into an artifact which will behave predictably across all environments. I don't blame web developers for abusing libraries, because it's almost impossible to strip it all down and work with the raw interfaces.

The whole thing is an enormous hack. If you view your job as a programmer as writing code to drive computer hardware - which is what the true reality of programming is - then web development is so far divorced from that. I think it's a huge problem.

Now? You need Windows desktop, mobile on 2 different operating systems, web, MacOS, and possibly TV depending on your market.

What's the lowest common denominator? Web stack.

I only have a problem with the ones among those hammer only people that are proud of not knowing anything else and proclaim everybody not using a hammer for everything stupid, because "look on all those perfected hammers we created! your choice doesn't have such nice ones".

This stuff was fixed at least 5 years ago. If you can drop support for IE11 (released in 2013 and no longer supported by Office 365), you’ll find that framework-free web development has improved massively since React was first released. And if you keep it simple and rely on what browsers support natively, you can achieve great performance.

Rendering hundreds or thousands of meshes and doing complicated 3D math for physics is no problem, UI is still extremely hard and complex, especially if you are supporting multiple arbitrary resolutions for example.

Godot, for example, has a full UI toolkit built in (the Godot editor was made using Godot components). However to actually get it working the way you want in most cases is a horrendous struggle, a struggle with ratios, screen sizes, minimum and maximum UI control sizes, size/growth flags, and before it gets any more complicated please just throw me a Tailwind flex/grid box model instead, because HTML/CSS has solved these problems repeatedly already.

So responsive Electron apps are certainly possible.

1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993

2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889

Both of the above examples revolve around opening files for the first time, and I suspect a lot of the slowness I perceive is because I open a lot of different projects and source code files when I'm working, and this is a bad use of VS Code.

In practice, VS Code behaves more like a multi-language IDE than a text editor. Slow startup times are generally acceptable in IDEs because you're exchanging speed for power. A programmer should ideally be proficient in both an IDE and a text editor, because they're tools applicable to different problems. E.g., VS Code is a terrible choice for things like analyzing log output, formatting large files, testing isolated snippets of code, or working on source code files that aren't part of the same project. I find this to be a shame because VS Code is flexible enough that it would otherwise be excellent for all of these tasks if it were just more performant for some operations that it struggles with now.

I would agree that VS Code isn't the fastest thing when the editor is starting up, though I find it fine when started. I pretty much always have VS Code running so I don't find this a problem.

A lot of the overhead seems to come from making a new window (even though the app itself is already running), although notably most of the time spent in the Prettier example seems to be spent syntax highlighting the JavaScript. If you want to try a direct comparison of opening a file vs. a window, you can see the difference between opening a new file in an existing window (on Mac, `⌘N` / `File > New File`) or new window (on Mac, `⌥⌘N` / `File > New Window`). For me the latter is far slower than the former.

The whole point for then from the start was to not to repeat the Atom fiasco.

The entirety of the project was running around of making Webkit not suck.

They spent ennormous effort on that.

I think it’s only noticeable if you’ve used a native application for a while. It’s not enough to go from VSC to Sublime and back to VSC again for five minutes. Make an effort to use a native app for a week or a month and then switch back.

Emacs will sometimes become slower (especially remote emacs), but it will always buffer your keypresses and do them in the correct order.

Jupyter (for whatever reason), doesn't do this with the result that I ended up wanting to create a new code block, but that keypress got lost and then i end up ruining my original code block.

I 100% noticed the difference, and it was super frustrating (fortunately I left that job, and have managed to avoid Jupyter in the new gig).

Emacs/Spacemacs can still be weirdly slow sometimes but UI responsiveness is generally miles ahead of all Electron-based software still.

Which makes it even funnier. Emacs is decades old and still uses quite a few ancient techniques that are only hampering it. Even with that, it's still so much better in terms of speed! Funny.

Yes, and no. They have a really interesting tale of convergent evolution.

Atom was the original Electron app (as pointed out Electron was even originally named "atom-shell"), so it predates VSCode as an Electron app. But the extremely performant "Monaco code editor" that VSCode was built on top of (that forms the heart of VSCode) was started at Microsoft years before to be a code editor in parts of the Azure Portal, and also it was the code editor in IE/Edge dev tools from as far back as IE 9 or 10 I think it was (up until the Chromium Edge). It wasn't packaged into an Electron app until after Atom, but it has an interesting heritage that predates Atom and was built for some of the same reasons that GitHub wanted to build Atom.

(ETA: Monaco's experience especially in IE Dev Tools and the wild west of minified JS dumps it had to work with from day one in that environment is where a lot of its performance came from that led VSCode to jumping Atom on performance out of the gate.)

I'm guessing it's pretty much dead now that github is under the same company that also makes vscode, right?

Well electron used to be called "atom shell" :)

VS Code also used to have far more native code earlier on in its development life, but seems to be transitioning a lot of it to WASM (paralleling the Node ecosystem as a whole moving a lot of performance heavy stuff from native NAPI plugins to WASM boxes; as one example: the major source maps support library moved from JS native to Rust to WASM compiled from Rust, IIRC).

Blame OS vendors for refusing to get together to specify a cross-platform standard API for UIs. We have mostly standard APIs for networking, file I/O, even 3D graphics, but not for putting a window on the screen and putting buttons on it.

OS vendors are still trying to play the lock-in game by forcing everyone to write GUI apps for only their platform. This is a non-starter, so everyone goes to Electron.

There are a few third party cross-platform UI libraries around. They suck. Qt is as bloated as HTML-based UIs, and then there's wxWidgets which is ugly and has an awful API based on 1990s MSC.

We could have something better, but it's an extremely large and difficult project and nobody will fund it. OS vendors won't because they don't want cross platform (even though all developers and users do). Nobody else will because nobody pays for dev tools or building blocks. The market has been educated to believe that stuff should all be free-as-in-beer.

Bullshit. Qt is much faster than Electron, the Mumble client is really fast on my Turion laptop, that with OpenBSD.

And I say this even if I prefer Barnard IRL.

1) Would need to be lowest-common-denominator by nature

2) Would quickly stagnate due to friction against changes/additions

3) Would have few allowances for platform HIGs

If it were permissible to have vendor specific additions on top of a common core, that could probably work fine otherwise this hypothetical standard UI library would share many of the problems suffered by Qt, wxWidgets, etc.

The other option I could see working is something like SwiftUI, in which some control over the behavior, layout, and presentation is ceded to the platform — basically having developers provide a set of basic specifications rather than instructions for every pixel on-screen.

As for the free aspect, I feel like this ship has sailed like 20 years ago. Nobody will pay for an UI toolkit these days. This is not Unreal Engine 4, you know. That stuff only works on AAA games market, apparently (although I am curious as to why it doesn't work everywhere else -- likely thin profit margins and/or middle management greed outside of the gaming genre).

Crazy you say? Start making a list of the features a modern UI toolkit has to have to even be considered for serious projects.

I get annoyed with Windows having the cursor randomly stutter for a split second rather than smooth motion. Or Teams taking half a second to load the conversation I clicked on. Or Powershell taking 3 seconds between initial render & giving me a damn prompt. Or the delay between me pressing the Windows button & the start menu appearing. None of these delays exist on my Linux machine where I've had the freedom to select the programs I use

I've made fast UIs with Javascript & React. Like all optimization it comes down to sitting down & profiling. Not taking "this is as fast it it can be" as an answer. In short, saying "Javascript is just slow" is part of the problem

Blaming languages is chasing a fad. I deal with it when people think the service I'm working on in Ruby is going to be slow because Ruby is slow. Nope, architectures are slow. If you know what you're doing Ruby will do just fine at doing nothing, which is really the trick behind speed

Languages like JS and Ruby make it easier to write slower code (and harder to detect that you're doing it) by the virtue of how their ecosystem and culture turned out with time.

I stood behind the romantic statement of "you are holding it wrong" when I was younger but nowadays it seems to me that the languages live and die by the culture of their communities. It rarely if ever matters if the language itself can be better / faster.

So while I agree JS/Ruby might have undeserved reputation for being slow, I think you should also agree that they are easy targets because observably a lot of software written with them is in fact slow.

I am looking at it empirically / historically while you are postulating a theoretical construct. I don't disagree with you per se but prefer to work with the reality that's in front of me.

---

That being said, kudos for being the exception in the group of the JS devs! The web frontend industry needs much more people like yourself. Keep up the good work. <3

As an example, my grandmother-in-law has been putting up with Microsoft Jigsaw's desktop app for years. Last time I watched her load it, we sat there for awhile and had to restart multiple times because it was getting stuck loading some advertisements. The startup time was absolutely brutal and the run-time performance while playing wasn't great either, even with a decent laptop.

So when I saw how slow, bloated and laggy this app was, I wanted to try to make her a better jigsaw app for the web and I think I succeeded [1]. It loads almost instantly, has no advertisements, and feels super smooth while playing... and it's mostly just js, svelte and a little bit of Rust WASM.

Anyway, I do prefer a good native app over a web app when available. But with native apps, it's also harder to block ads and other trackers compared to the web.

[1]: https://puzzlepanda.com

I've been working with the horrors called Windows MFC and Java Swing a long time ago. It was tough but if you did it right (moderately hard) you had a very snappy app on a computer that was 5x slower and had 10x less RAM than a midrange today's Android device.

It takes someone who really cares about performance and monitors it to make a fast web app and to keep it that way. Unfortunately it's still too easy to accidentally make it slow.

Especially after the walkbacks that Xbox Game Studios had to do after flak about scummy microtransactions in Halo, Gears, and Forza, it still seems incredible that Microsoft continues to allow Arkadium to do it to a far bigger audience (and a lot of people's parents and grandparents especially) with their brand name attached to it.

Yupp, it's on my todo list to give users the option on how difficult they want the rotation to be. So far I have users that want click-to-rotate and even no rotation at all.

Meanwhile, here I am, making a decentralized social media server and being afraid to add an extra <div> lest it bloats the page.

I'm consider myself lucky to be born in the 'transitional period(1980s) I see the world of my parents and also have abilities to adapt with technology.

TL;DR - users can get used to pretty much anything because they don't know it could be so much better

My company, like many, bloats Windows with security software. We have the type of PC where McAfee uses 80% of resources for an hour every Monday morning. PCs with spinning hard drives take a good 15-20 minutes to fully boot, and some engineers still have those. Those who complain just get told to wait a few years for their planned laptop replacement, to finally get an SSD.

There's no solution, so users just cope.

https://apple.stackexchange.com/questions/17929/how-can-i-di...

https://superuser.com/questions/455313/disable-os-x-enter-fu...

It looks "pretty" to the UI people.

https://thedailywtf.com/articles/The-Speedup-Loop

tl;dr : programmer inserts a large empty loop in a UI, so that in weeks when he achieves nothing, he removes a single zero from the end of the loop counter to speed up things a bit.

We later created a light version for a specific use case, and the product owner came prepared with a nice splash screen for this one too. The app was so lightweight that it loaded near instantaneously - so the engineer added a six second delay just to meet the splash screen requirement.

Buys them time to get stuff done under the hood while you are gazing upon the 'sands of time' (good old Windows hourglass).

It conditions you/me/everyone to be impatient. I opt out of all such transition effects on my phone. I prefer that the screen goes black of freezes until the next screen comes up. This way I don't get distracted by irrelevant junk (spinning wheels, hourglasses, etc.). It is crunching bits. Don't add more junk to it. Let it crunch bits without tricking me.

Chromium is a huge boon to developers for this reason. Now there could have been a different history here. Apple after acquiring NeXT had also gotten OpenStep, https://en.m.wikipedia.org/wiki/OpenStep . OpenStep was a cross platform UI development kit, even the web could be a target. Apple decided (possibly for good reasons, hard to argue with success) to kill this off. But, they had toyed with it, https://www.macrumors.com/2007/06/14/yellow-box-seems-to-exi... . So, Apple had effectively what Chromium has become. A cross-platform development and runtime environment.

Would things be different today if that wasn’t killed off? Would Apple have never come back from the brink of death to become the behemoth it is today, because it would have starved its own platforms? One thing you might have had is a cross-platform “native” UI platform, and that might have meant faster more efficient UIs like you want now.

Shoutout to GNUStep trying to keep the dream alive: https://en.m.wikipedia.org/wiki/GNUstep

Follow up question: maybe with Apple being so successful, now they could revive this and make it profitable for themselves, rather than starving their own platforms?

The bad news is that doesn't seem likely to happen.

People here crying about load times and FPS rendering are completely out of touch with reality of SW development - getting stuff to function correctly and reliably with requirements constantly changing > performance, and that's hard enough with tools that simplify SW development. Optimising for performance is a luxury very few can afford.

Hilariously, I wouldn't even say that modern software does that well either.

To have performance, you have to understand the data you are working with and how it can transformed efficiently by your hardware. To have maintainability you have to create good abstraction around how you transform your data. To have correctness you have to implement and composite those data transformation in a meaningful way.

All of those things are orthogonal.

Game developers usually and rightfully skip maintainability and invest barely enough regarding correctness. Games are like circus performances while business apps should be made to run the circus.

Game engineers are wizards, but real general-purpose UI is a different problem than they are generally solving. A game UI is typically very limited in terms of what types of information has to be displayed and how. Many applications have to support what is essentially arbitrary 2D content which has to be laid out dynamically at runtime, and this is something different than the problems most games have to solve.

That sounds exactly like the problem most games have to solve. The age of fixed CPU speeds and screen resolutions is long gone. Games have to content with a plethora of dimensions along which to represent an interactive, dynamic, multimedia world.

Most game developers will make it as fast as they have to... in fact most developers do that.

Games are usually developed as abandonware. Do you want your apps to be developed as abandonware?

https://coherent-labs.com/

Not really. I'm sure plenty of people remember the quick feel of early PC UIs. Ironically, q3 kind of came at the end of that era.

Some of the same people might even remember when, with a little training, voice recognition software could do its thing without an internet connection and a warehouse full of computers at the other end, on a PC with less RAM than the framebuffer of a modern PC or phone...

I'm sensitive to latency.. first thing I do when I setup a new android phone is go into the developer settings and speed up all animations.

For our own company [0], we also treat speed as a top feature, though it's not something that's easily to market. It's something that power users appreciate. I even wrote a similar blog post [1] to this. The magic number, from what I've found, is 100ms. If you can respond to a user action in 100ms, it feels instant to the user.

0: https://www.enchant.com

1: https://www.enchant.com/speed-is-a-feature

I would immediately apply but I'm not interested in Ruby or HTML/CSS anymore (although I still know the last two rather well and plan on making a return there to author my own blog theme).

Main focus are Elixir and Rust -- the latter exactly because I want to make efficient and ultra-fast software. Also very invested and averagely skilled in DevOps / sysadmin activities.

I hope there are more companies like yours out there -- and that yours is thriving!

Current situation is people creating abstraction at the wrong level and not understanding the performance cost of things like reflection and ORMs.

Kudos to you. We need more people like you.

I wouldn't say native UIs necessarily, IMO, but I definitely agree that something has to change.

Current systems are not only getting slower and less useful, but they're also getting harder to develop, test and maintain as well -- and, consequently, buggier.

The fact that there still are many old, TUI-based systems out there AND that users favor them over the newer ones exposes a lesson we've been insisting on overlooking.

If Electron is rewritten in C / Zig / Rust / whatever and becomes much more lightweight then I'll be on board about using it myself.

But the abusive relationship between today's software and what is essentially supercomputers has to be ended and started anew on a more respectful foot.

The problem is the abstraction level, instead of a locally running program manipulating objects that are turned into render instructions basically in a one-to-one fashion, there is a whole added indirection with generating and parsing HTML and then converting the dynamically created DOM into renderable elements.

Maybe not necessarily something as radical as terminals, but anything providing the same programming ergonomics (in order to be easy to build and maintain) and constrained by the same restrictions (so that functional requirements get tamed).

At first, it would definitely sound as an involution, but I feel somehow confident that the market in general will accept such constraints as soon as the results become evident.

I've had enough of today's slow buggy messes that require gigabytes of memory and two CPU cores to show me a splash screen for 10 seconds.

A lot of the TUI apps I stumbled upon seem really well-done.

I'm currently using nvlc and cmus for music playback, and then of course your standard complement of text editors etc. I like Lynx et al. for some web browsing, but compatibility is a pain.

- `lazygit` is extremely valuable.

- `lnav` for inspecting log files has turned out to be surprisingly good.

- Do you use `fzf` in tandem with your shell so you can also search your command history (and not just look for files)? I use that for like a year now and can't live without it.

- `mc` for TUI file management has been moderately alright.

- How about `ripgrep`? Can't believe I lived without that one too.

- Rust's tool `skim` (the command is `sk`) in tandem with `ripgrep` or `the_silver_searcher` to very quickly search in file contents in big directories has saved me a ton of time already (although I moved to search file contents in projects in Emacs since). To be fair, you can just use `fzf` instead of `sk` here though; I am just positively biased towards Rust.

- `ripgrep_all` allows you to search in ZIP archives, PDF docs, Office docs/spreadsheets etc. Really useful.

- `ht` is a Rust rewrite of `httpie`, the Python friendlier `curl`. I like `ht` much more because it doesn't incur any startup overhead and started replacing my scraping / syncing scripts with `ht` where applicable which is NOT everywhere because `curl` is extremely powerful and it doesn't often make sense to replace it.

- Command-line or in-terminal charting/plotting: `jp`. I have made a CSV file out of all file sizes on my NAS (bucketed by powers of 2) and then invoked it on the input. Here's a sample CSV from a random directory:

0k,79

1k,6

2k,1

4k,166

8k,34

16k,7

32k,6

64k,3

128k,27

256k,2

512k,2

1M,3

2M,4

4M,8

8M,10

16M,135

Then do this:

`cat THIS_FILE.csv | jp -input csv -xy '[*][0,1]' -type bar -height 57`

And enjoy an in-terminal vertical bar charts. :)

- ...And I have a ton more.

But your question makes me sigh. I really have to start a blog. I am a very practical guy and people usually love my posts (scattered on different forums) where I make such lists. I should roll my own blog static web site generator in Rust I suppose, because the existing ones are either slow or don't support what I need... So, not going to happen in the next year, most likely. :(

The rest I haven't looked at, but will have to add to my list, they fill a couple voids I've been feeling.

> I should roll my own blog static web site generator in Rust I suppose, because the existing ones are either slow or don't support what I need... So, not going to happen in the next year, most likely. :(

It isn't powerful enough to support what you need I'm sure, but I actually did something similar a little while ago.

http://a-shared-404.com/programs/

It's written in Rust, with dependencies on sh and markdown. I'm thinking about adding the ability to automatically execute an (optional) shell script in each directory, so that it would be easier to do things that markdown doesn't.

The code quality is atrocious (first Rust program of any size, and I'm not great at programming in the first place), but it may be useful. If you're interested in me adding that functionality, let me know, it may be the push I need to move it to the top of my pile.

I'd also like multilingual article ability (but I think some of the engines out there can do that). The more I think of it, the more I wonder if it should be something like Ghost.org: namely backed by sqlite and not naked files. But who knows.