> There are just too many levels, and JavaScrip is an interpreted language, not a compiled one, so by default, it will be orders of magnitude slower than an app written in Swift, Rust, or C++.
JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.
For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptional cases like WebGL-type stuff.
What's also not mentioned is that because JavaScript is single-threaded and garbage collected, classes of issues that you'd see in C++ are completely avoided (of course at the cost of absolute performance potential). I'd argue that TypeScript is probably the easiest language to grok, but I'm biased.
Anyway, Electron is its own circle of hell as it redundantly ships a ton of stuff and eats memory due to its own inefficiencies (though some of this is necessary sadly as letting you Bring Your Own Browser would create complexity of its own). I'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now, given the popularity of the apps.
Though, I guess with newer apis such as the File System one Electron is slowly becoming unnecessary (but I doubt it'll ever go away because it's doubtful Chrome will include all of the APIs necessary).
The other issues mentioned in the article, such as UI could easily be addressed if Google and Apple cared to. They could release a CSS framework and style guide and people would quickly adhere to it. Google kind of did this with Material, but it doesn't go far enough, which is why you see 3rd parties picking up the slack.
> For a web app the speed of the language is rarely the bottleneck anyway
I think there’s some selection bias in this; the apps that get built as web apps tend to be the ones that are not bottlenecked by JavaScript. For exceptions that are pushing the limits of performance, you’ll more often than not find Rust/C++ compiled to Wasm in the stack.
We build a full game creation IDE and game engine which is entirely browser-based and almost entirely written in JavaScript (including all the performance-sensitive stuff), and the performance is ridiculously good[1]. You don't need WASM for good performance[2].
Fair enough, Construct looks cool. If you or anyone from your team is interested in doing an interview for a technical newsletter about browser-based apps[1] I'd be glad to get a JS perspective on high performance in the browser.
I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. I can't think of a single webapp or electron app I use which performs heavy computation. Maybe VSCode? But I don't know if any of the computation is happening on the frontend. People have been extolling the virtues of WASM to me for a while but I have yet to find a use for it where it improved the speed of development, since that's the only metric that matters to me working on CRUD apps
>I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. I can't think of a single webapp or electron app I use which performs heavy computation.
Figma
Teams (the web version)
Outlook (the web version)
MS Word (the web version)
MS Excel (the web version)
Google Documents
Google Sheets
Google Earth
(similarly the iCloud versions for Pages, Numbers, etc)
Even those CRUD apps you and I use daily have substandard performance, as they get bottlenecked by amount of data they can process, in at least two major ways:
1. Code "fast enough" to manipulate a few things (say, listings) will not be fast enough to handle hundreds of them;
2. UI frameworks and components people use are designed to look nice for demo case, which is again few elements, and tend to choke under actual, real workload of dozens, or hundreds, or thousands of elements.
Next time you see a website that paginates your results, like e.g. a store that shows you 20 results per page, look for a dropdown controlling the pagination threshold. See if you can bump it to 50 or 100 elements per page, and ask yourself, why do you dread doing so.
I see it mostly with what I would call “industrial applications”: video editing, CAD, etc. Besides games, consumer software tends not to be computationally intensive, so there are few consumer examples (which I think leads to a sort of “JavaScript is fast enough for everything” fallacy among web devs)
I happen to write a newsletter where I interview this sort of company, here are some recent examples that use Wasm:
Webdevs seem to have a blind spot around UI. Plenty of end-user apps - like music players - and websites - like e-commerce stores - tend to have compute-intensive UIs. They may not look compute-intensive for a dev on a beefy machine, playing with mockups and toy loads, but they absolutely become noticeable compute hogs on real machines with real loads.
And by "real loads" I really mean just more than two dozen items on a list of whatever it is the app displays.
My company has several tables in our UI whose API endpoints simply query for all records in that table without pagination. hundreds of rows are loaded into a table plugin, even if you'll never get past the first page
That's... good. Hundreds of rows is a trivial amount, so unless they're expensive to generate on the backend and/or meaningfully large, it should be a non-issue. The question is, what is the page size in the UI, and why is it less than "hundreds of rows"?
Browsers can handle hundreds of rows just fine, even on, say, a modest Chromebook. No problem. If you're looking for someone to blame, you need to blame the crummy UI frameworks in use on the site and the half-rate developers who chose not to vet (and veto) their use. And blame the screwy job requirements and hiring practices at the company that insisted that those developers—the ones who took this development approach and worked with this kind of tech—were the right ones to hire and others were the wrong ones.
Of course. I'm definitely not blaming browsers for this - we're talking about trivial requirements here, while browsers themselves are absurdly well-optimized these days. Which makes it even harder to watch the webdevs casually throw that all away using crummy tools, too focused on moving fast themselves to give a damn about letting users move fast too.
Figma is a good example. Likewise, many games. Google Sheets? GIS apps? Probably the next big things in both DAWs and video editing will be in the browser too…
Oh yeah I guess Figma is one, but I'm not in the design department. I guess there are a lot of apps out there that benefit from it, but I don't seem to use any of them
> JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.
Sorry, not even remotely close. I want to see some serious evidence.
JS id as unoptimizable as can be, thanks to its hyper dynamic nature. And js developers without any clue about memory will happily allocate hundreds of thousands of unnecessary objects to save a line of code. Completely unknowingly of course.
Speed is achieved via optimization, which is achieved via constraints. Javascript is being known for its inefficiency.
Saying JS is just as fast is a hot take and whoever claims that has the burden to proof otherwise.
Sorry, about benchmarks I just quote myself:
> I take these performance benchmarks with a rock of salt. They are mostly hyper-optimzied generics which are as far away from actual production code as it can be. They are written in a way to allocate as little memory as possible and is done by people who know exactly what they are doing.
I take these performance benchmarks with a rock of salt. They are mostly hyper-optimzied generics which are as far away from actual production code as it can be.
They are written in a way to allocate as little memory as possible and is done by people who know exactly what they are doing.
Especially the garbage collection strategies of Java are second to none (sorry, don't want to be a shill).
> For real-world applications....compare IntelliJ, Eclipse, Visual Studio, or Sublime against VSCode.
My experience is that VSCode has horrible input latency and Intellij is blazingly fast once indexing is done.
This is classic goal-post moving - you started out by saying that Intellij was faster than VSCode, then after a commentator said that their experience was the opposite, you moved the goal-post to "well it doesn't matter". You should be willing to admit when you're wrong.
> Sorry, not even remotely close. I want to see some serious evidence.
There was this blog post of a company trying improve their clients' webpage performance by incrementally migrating them from JS to WASM/Rust: https://zaplib.com/docs/blog_post_mortem.html
In short, their idea failed. Those rewrites did not yield the "orders of magnitude" perf improvements that they were hoping for. A quote from the article:
> Rust is faster than JS in some cases, but those cases are rarer than we expected, and the performance gain is on the order of 2x some of the time, not 10x most of the time.
Having had a good deal of experience programming in JS, this doesn't surprise me. JS engines are extremely good at JIT optimizing, especially if you know what you're doing and give them code that's suitable for optimization (e.g. using mostly primitives and arrays, simple loops, avoid creating tons of intermediate data structures, etc).
IDK if any of this counts as "serious evidence". It's purely anecdotal really. But it's on par with the "evidence" presented as a counter to this.
Yes, it's a 30 year old game but the typical CRUD web app doesn't have close to the complexity of quake. Good C++ code is significantly faster than JS, that's true, but JS is also much, much faster than you'd think.
I did a double take when I read this too. However, I’d wager that in 99% of cases the bottleneck isn’t at the language level for most desktop apps or GUI apps in general.
I have an app that has one pretty frequent cpu intensive call (it computes the lcs for diffing). I decided to benchmark a rust wasm bindgen implementation against the js one I was using and found that ironically enough, node did perform better than rust. To be fair to the rust version, I think the JS implementation was slightly better optimized. I then looked into parallelizing LCS, (which is possible) but bindgen and almost all node:rust ports don’t support multithreaded calls, I can think of a myriad of ways to overcome this but not in a browser context. At that point I gave up on worrying about porting to lower level languages for cpu intensive work because if you’re forced into a single threaded context the gains of a memory managed language are going to be trivial at best and add ipc overhead at worse.
The main culprit of poor JS performance in native contexts is almost always bridges and the serialization/deserialization that comes with them. Electron apps don’t really suffer from the bridge problem. While, I’d never claim that JS is as fast as GO or Java (objectively it isn’t), it’s seems equally naive to suggest that using memory managed languages without exploiting multicore is going to lead to significant performance gains in a native app or web app.
I think the real power of wasm is the power of virtualization, it won’t be performance unless web APIs decide to break the single thread paradigm.
Well then you’re back to the bridge problem. postMessage is crazy slow. There are some problems where parallelization will outperform the ipc cost with postMessage but those problems are few and far between. I haven’t dove into the new web GPU api but it does look kinda promising (shared memory is hard, so I’m apprehensive). I’m sure some of these things will get solved in the long run but for the time being, the bottleneck to browser performance is not necessarily JavaScript itself but the webapis that are crafted around a single threaded model. This is really my only point. Aside from providing systems engineers familiarity with syntax/devex and possibly some portability with some llvm/wasm compatible libs, there is little point in wasm runtimes at this current time imo.
“Data is sent between workers and the main thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler (the message is contained within the message event's data attribute). The data is copied rather than shared.”
The key words here are: "around", which is to say same order of magnitude for performance, and "in some cases" which is to say for certain applications. I've already posted evidence for this claim specifically in sibling posts.
Also, why do you compare JS written by amateurs with Go/Java experts? There are JS experts too.
I once wrote an image generation program that used every color in a provided palette exactly once, then ported it to a few different languages. The main data structure was a kd-tree to store RGB points, with each point being marked as used after returning it.
Rust and C++ were both within about 10% of each other. Python was about 3 orders of magnitude slower. The surprising result was that JavaScript was only about 7-8x slower than the C++ version, which was much faster than I had expected.
The Javascript JIT arms race was the most heavily funded dynamic language arms race since forever - involving three major players (Apple, Google, Mozilla), dedicated teams, tons of benchmarks, constant tracking of performance improvements, total rewrites of the engines and additional JIT stages added, and public boasts in the official company blogs and marketing material!
Given the disadvantage that it starts at, JavaScript is astonishingly fast, due to the extreme investment in it that you mention. However, in almost all real-world scenarios, it’s still generally pretty easily beaten by ahead-of-time-compiled languages, even if on some microbenchmarks and for a few specific sorts of tasks it can end up competitive with certain of these compiled languages.
>However, in almost all real-world scenarios, it’s still generally pretty easily beaten by ahead-of-time-compiled languages
The claim to be refuted was not "Javascript is faster than AOT compiled languges" however.
Instead, the claim was: "[Javascript is] around the speed of Java and Go in some cases, which are compiled", which is not far off. Especially given that these two are not in general among the fastest kids like C, C++, and Rust.
Yeah, what I expressed was a bit sloppy. Go is AOT-compiled, but kinda the weak link among most such languages as regards performance. Java is somewhere in between the two, and the HotSpot JVM is also generally handily faster than JavaScript engines (it also has had rather a lot of effort put into optimising it, and without most of the starting disadvantages of JavaScript).
That being said, the specific performance characteristics isn't really the point. Even if you accept JavaScript and Go being similarly fast (same order of magnitude), JavaScript uses way more memory (which I'd argue doesn't really matter, but it's worth mentioning) and the DOM is the main bottleneck in the browser, so WASM won't save you completely there.
"In some cases" seems reasonable to me. Google poured a lot of money into V8 performance for 15 years. There's also situations like AWS's Lambda environment where more time was spent getting node/JS optimized for the environment.
I think that one of JavaScript’s biggest problems is that on average, the quality of code written in it is somewhat low due to its lower barrier to entry, its relatively loose nature, and the less-engineering-inclined nature of many who write it enabled by that looseness. It doesn’t matter how fast your runtime is if it’s running crappy code.
That’s not to say that all code written in Rust or Swift is all AAA grade or anything, but to write those to the point of being able to publish a product that functions reasonably well, a deeper level of understanding is required which acts as something of a filter.
It would be interesting to see what would happen if all browsers added support for a sort of “JavaScript Next Gen” that were much more strict, sitting somewhere between TypeScript and Swift without the various escape hatches that TS currently has. My bet is that sites and web apps written with this would be on average of higher quality than their legacy JS counterparts.
> I guess with newer apis such as the File System one Electron is slowly becoming unnecessary
Last time I tried, it was still a pain point. For one, the API felt... alien. Also, the performance was not good. I'm not sure why, maybe it's my Javascript-FU that's bad, but all in all I'd still use another language for this if possible.
Sure it is - the vast majority of webapps are glorified CRUD. I'm not saying there are not high performance use cases. I'm saying if you list every app, most of them would be fine with exclusively JavaScript, and for the rest you have careful use of WASM or backend delegation to a faster language.
And to the author's point, something slow in JavaScript is better than nothing at all.
JavaScript isn't as fast as C++ or Rust, but it's pretty fast. Around the speed of Java and Go in some cases, which are compiled.
For a web app the speed of the language is rarely the bottleneck anyway, other than some exceptional cases like WebGL-type stuff.
What's also not mentioned is that because JavaScript is single-threaded and garbage collected, classes of issues that you'd see in C++ are completely avoided (of course at the cost of absolute performance potential). I'd argue that TypeScript is probably the easiest language to grok, but I'm biased.
Anyway, Electron is its own circle of hell as it redundantly ships a ton of stuff and eats memory due to its own inefficiencies (though some of this is necessary sadly as letting you Bring Your Own Browser would create complexity of its own). I'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now, given the popularity of the apps.
Though, I guess with newer apis such as the File System one Electron is slowly becoming unnecessary (but I doubt it'll ever go away because it's doubtful Chrome will include all of the APIs necessary).
The other issues mentioned in the article, such as UI could easily be addressed if Google and Apple cared to. They could release a CSS framework and style guide and people would quickly adhere to it. Google kind of did this with Material, but it doesn't go far enough, which is why you see 3rd parties picking up the slack.