Teams is an entire web server written in an interpreted language compiled on the fly using a "Just in Time" optimiser (node.js + V8) -- coupled to a web browser that is basically an entire operating system.
You're not "starting Teams.exe", you are deploying a server and booting an operating system.
Seen in those terms, 9 seconds is actually pretty good.
Seen in more... sane terms, showing 1 KB of text after 9 seconds is about a billion CPU instructions needed per character.
But that's not really the the slow part. JavaScript with V8 is one of the fastest interpreted languages. A bare Electron app starts pretty fast. Google wants to have the fastest browser, so they invest a lot into Chromium (which Electron uses).
Even React isn't all that slow. If you look at benchmarks you may be impressed by how quickly it can do some operations. It's consistently a bit slower than other frameworks, but not that far off. There are (big) React apps that are quite fast, too.
So writing performant applications with these technologies isn't impossible.
Yet a lot of apps built with them are slow. The fast ones are rare.
I don't know what it is yet (happy to be pointed somewhere), but I'm fairly convinced that these technologies have common footguns that encourage programming things in slow ways. I can imagine it being related to React's coarse-grained and easy mismanage reactivity and wonder how much of an improvement Solid is in comparison (it is also functional, but is built to always recompute as little as possible rather than saying "whatever, it's cheap", which React does).
I don't like Javascript but you're mistaken on the performance part, even I have to give the JIT people props for how fast they've made the language in general.
Depending on specific use-case, today's JavaScript code is only 2–7 times slower than corresponding C++. That's pretty damn fast. Faster than some compiled languages. Fast enough that if you wanted to obsess over performance you can build the fastest backend framework in Node.js[0][1]
> showing 1 KB of text after 9 seconds is about a billion CPU instructions needed per character
Correct me if I'm wrong, but on a 3ghz CPU (3bln cycles per second), there are 27 billion cycles per character for 1kb of text. Take into account that on any non-stone-aged CPU you've got probably 4-16 cores, and can do ~4-8 SIMD ops per cycle (at full clock rate), so at the limit we're actually talking .. something like _3.4 TOPS PER BYTE_ ..
A typical modern CPU can retire 2-3 instructions per clock, per core. Somewhat more due to hyper-threading, so maybe 5 per clock per core. So a 3 GHz, 8-core processor for 9 seconds is 5i x 3Ghz x 8c x 9s = 1 trillion instructions. Divide by 1KB to get roughly 1 billion instructions per character.
SIMD is a little unfair, because virtually none of what an app like Teams does is amenable to vectorisation. If we allow SIMD, then we have to allow the GPU, and then we're talking about an entire different order of magnitude.
A decent last-gen GPU has something like 30 teraflops, so about 265 billion instructions per displayed character!
Well, and then there's my work laptop which seems to enjoy clocking in at 800 MHz instead of the rated 3.4GHz because 60°C is too warm or so?
But yeah, it is incredible when stuff used to load on single core 500 MHz CPUs.
Or that I had a full graphical desktop on a 20 MHz CPU once. And it really wasn't that different? Launcher of apps at the bottom, even, despite being a completely different OS…
> You're not "starting Teams.exe", you are deploying a server and booting an operating system.
Sounds about right and, actually, is quite a feat.
I just wonder how they went from "build a chat app with some filesharing built in" to "include everything and the kitchen sink and oh, in your own universe" kinda thing...
Because then they could be absolutely sure that the people they hired to build their application didn't need to know how to build the things needed to build their application, or build the things needed to build those things, etc. Looking at electron et al apps purely based on performance is like comparing the cost of a restaurant meal to the cost of cheap groceries without acknowledging the benefits. If you're a software developer, the benefit probably doesn't seem worth it. If you're a project manager hiring developers to be responsive to new feature requests from the product managers, interface changes from the UX team, branding changes from the identity team, adapt to infrastructure changes from the devs designing the services, etc etc etc then having a battle-tested-on-most-platforms batteries-included platform makes a lot of sense... even if it comes with 60 kinds of batteries when you only need 5. Especially when for the most part, only a tiny percentage of people actually give a shit about whether something takes 50ms to load vs 3s. The large operations that take 30s to load occur rarely enough (startup, for example) that most users just don't care.
You're not "starting Teams.exe", you are deploying a server and booting an operating system.
Seen in those terms, 9 seconds is actually pretty good.
Seen in more... sane terms, showing 1 KB of text after 9 seconds is about a billion CPU instructions needed per character.