Which is like, the reason people invented multi-tasking operating systems, somewhere around 1960s.
Which is why current disregard for application performance really irks me. A computer is meant to run a lot of things at the same time. To some point, the utility of a computer scales with the number of things you can run simultaneously on it. Your Electron chat client that thinks it own 100% of CPU and RAM essentially puts a soft limit on that. It's less of a problem for power users, who know how to work around such problems, but it is a deal for regular people, who'd love to run a few things at a time but can't, because one or two apps grinds their cheap computer to a halt.
> If you think you browser is fast, you'd be blown away by any decent application.
In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow.
A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C.
Bigger - and slower - parts of the web app can be loaded after the app starts interacting. So - at least in principle - no sizeable speed difference, which would blow somebody away.
Advantage of web app is cross platform uniformity. Write once, run everywhere.
Of course, reality can make adjustments, but we can see and invent things.
This is misleading as all get-out. "JavaScript assembler" is WASM, I assume? Running it in a browser still includes the overhead of a browser. The slowness is not from the wasm runtime (which has been implemented standalone and is fast), but in the browser-y gui stuff (which is what electron is good for). Also, WASM has less tooling etc. around it than JS, so JS is used for now. And jS is slow, but it's what is used by electron.
Your saying "electron could be made faster if we did all these huge things" is like me saying "but the c could be faster if we did great threading, really efficient code, inline ASM, and used intel's crazy compiler for maximum optimization". I get there's hope for the future, but not currently. In any case, implementing a custom graphics stack (like the web) will always be a heavy-weight task compared to one application.
> The slowness is not from the wasm runtime (which has been implemented standalone and is fast), but in the browser-y gui stuff
Not entirely true: In representative benchmarks, WASM has only 65% of the performance of native code. Of course, everything gets much worse the moment you interact with browser mechanics—WASM is only this fast while doing raw computations.
> In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow.
Most people however don't live in a data center. On regular computer and with regular Internet connection, even spinning rust blows the network out of the water. And computers increasingly ship with flash memory these days.
> A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C.
A desktop app has already loaded that assembler at build-time, and when executed, it loads and runs native code.
(Well, sorta. Scripting is a huge thing for modularity and extensibility, and people do frequently choose slow languages like Python for that. Then again, some languages (like some Python implementations) let you compile scripts on first run and execute binaries later on. I actually wish more languages were designed like Common Lisp is, where you keep a seamlessly integrated compiler available at runtime and are expected to take advantage of it - in case of SBCL (a CL implementation), this means a fast to-native compiler, which on occasions can make an application faster than it would be in an otherwise ahead-of-time compiled language.)
> Bigger - and slower - parts of the web app can be loaded after the app starts interacting. So - at least in principle - no sizeable speed difference, which would blow somebody away.
So can desktop apps. Except they rarely need that, if huge, because it's harder to make them slow by default.
I mean, take Slack - a frequent target of performance complaint. They have a bloated web client, an even worse Electron app, and here I am, using Ripcord[0] on both Windows and Linux (and it has a Mac version too), getting the same functionality at a fraction of the resource use, and there's literally nothing slow there. Nothing. Not a thing (except connecting) takes a perceptible delay. That's how fast you can make a modern chat client, if you care.
> Advantage of web app is cross platform uniformity. Write once, run everywhere.
That's a big advantage, true. It's easier. Though it does come at a cost.
> Advantage of web app is cross platform uniformity. Write once, run everywhere.
In theory -- yes. But in practice, it is write once, debug anywhere. Remember a certain electron app consuming 100% CPU for a blinking cursor on a certain platform?
> In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow.
RDMA has no relevance to this discussion.
> A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C.
This is incredibly wrong. An Electron app goes through many stages before code is executing with acceptable performance:
1. A full web browser loads.
2. JavaScript is loaded and parsed.
3. JavaScript runs interpreted, which is very slow. It is only here that the "application" starts.
4. After a while, the JIT may decide to compile some code. This is very resource intensive.
5. After compilation, you finally have some parts that have decent performance. However...
6. Gaurds fail (i.e. bad assumptions), and the code is deoptimized, running at slow speed again. JIT compilations may be tried again later with new assumptions, and if you're lucky, they might hold.
At #5, you have code that is as fast as it gets. It is nowhere near as fast as native code (any benchmarks you think of are synthetic and designed to show JavaScript as fast—it doesn't take a lot to shake out the issues).
For a native application, however, the process looks like this:
1. The application starts, and it runs.
Done. There is no parsing, interpreting, optimization. This single step is orders of magnitude faster than just #1 of the life of an Electron app.
> Bigger - and slower - parts of the web app can be loaded after the app starts interacting. So - at least in principle - no sizeable speed difference, which would blow somebody away.
We are talking a speed difference in orders of magnitude here. An electron application is not even done preparing Electron before a good native application is done loading.
And it's all fine and dandy that you can load heavy things later, but for a good native application has nothing to load later. It's done.
A fun comparison:
1. Slack cold-start on my machine: ~3 seconds before anything shows up, ~5 seconds until a main window with a loading indicator is visible, ~10 seconds till fully loaded and usable.
2. Telegram-desktop cold start on my machine: ~1 second till fully loaded and usable.
And telegram-desktop is a very slow native application! A speedy application starts in 250ms or less, and never waits after that.
> Advantage of web app is cross platform uniformity.
And the disadvantage is that they are are huge, resource intensive and pathetically slow.
We have very functional cross-platform toolkits, like Qt that telegram is based on.
> At #5, you have code that is as fast as it gets. It is nowhere near as fast as native code (any benchmarks you think of are synthetic and designed to show JavaScript as fast—it doesn't take a lot to shake out the issues).
This. And to make matters worse, a lot of benchmarks start with something like, "To be fair to <the slower language>, let's cripple <the faster language> by implementing the programs using the paradigm favored by <the slower language>." If you want the real results, have an expert in each language implement the spec without looking at the other program.
Someone mentioned Photoshop being slow compared to Slack/VSCode. That is Apples to Oranges comparison if I ever saw one.
> And the disadvantage is that they are are huge, resource intensive and pathetically slow.
And don't work natively on any platform. You essentially program for the lowest common denominator and do not take advantage of any of the features provided by the platform -- especially accessibility. For example: Zoom In on any half-way decent editor increases the text size. Zoom In on VSCode (macOS) blows up the entire UI -- leaving little space for actual text. This is just one example -- I can line up many more.
Probably because your desktop apps are bloated, too. Any software that needs longer than zero point two seconds reacting to user action (this includes starting the program) should be improved upon.
I write moderately complex web apps and I have to say 200ms for a user interaction sounds like far too long. All apps regardless of where they're running should be managing a solid 60fps, which gives you a budget of 16ms for the UI to react to a user event.
Obviously starting the app is going to take longer, especially from cold, but if you ignore things like DNS resolution and download time then 200ms is more than enough for most things to get from 'downloaded' to 'interactive'.
It shouldn't be obvious that startup is slower and I didn't mean UI reaction, but the more broader reaction time. For example from typing a location and hitting enter, it should take something like Google Maps zero point two seconds at most to completely load the page and be done with everything. The user shouldn't have a concept of "loading time" and that includes starting the application.
I think the only native apps that I use are Steam, Unity, Photoshop, SourceTree and VSCode. Out of those the only "fast" one is VSCode, which is actually written in JS. Even though you mentioned the browsers being "bloated", for me Chrome always starts up instantly and I have no responsivness issues when browsing sites, playing browser games or using browser apps.
Out of those the only "fast" one is VSCode, which is actually written in JS
Typescript I think? Anyway, much as Microsoft has done an amazing job with VS Code, it really doesn't have quite the snappy feel in all circumstances of a native app. Extension loading on start up is one example. If you use a keyboard mapping extension it's quite possible to start typing on launch and find the mapping hasn't kicked in yet.
That's not to say it isn't worth the tradeoff. The costs are inconsequential, and the benefits great. I'm mostly an IntelliJ Idea user, but the sheer speed with which VS Code is developed often tempts me towards it (eg. it's well ahead of Idea on wsl integration)
I do like performant apps, but I've never understood the emphasis on startup time for most of them. There's the odd utility (eg. screenshotting) where an instant start is desirable. But the main things I use (terminal, editor/ide, browser etc) are started once per week at most.
I personally wouldn't want the developers of the software I depend on most to waste resources speeding up something of such marginal significance.
[Edit: an instant-start editor for config file, vim commit edits etc is of course crucial]
I have a workflow where I spawn and close terminals depending on whether I want something done. If my terminal startup wasn't instantaneous, I'd be switching to one that was. (Currently using urxvt). The only reason I keep my browser open is because it doesn't start instantaneously. Imagine a world where your computer and all your apps can start instantaneously. It would be viable to shutdown your computer when leaving the room instead of just locking it.
In this reality, however, I would already be happy if tabs in a browser could load that fast, so I wouldn't have to keep hundreds of them open all the time.