I mean, I thought it was a pretty good explanation.
JavaScript plays fast and loose with types. Which means that when JIT compilers generate code for it, they have to make all sorts of conservative decisions. This makes generated code more complex and, in turn, slower.
The difference is primarily algorithmic. Java on WasmGC is about 2x slower than Java on the JVM. The remaining 50x is just Chrome's regex impl being awesome.
We had a pretty awesome team of people working across the entire stack optimizing absolutely everything. The blog post only talks about the three optimizations that made the biggest difference.
I don't know absolute values but Excel still has several advantages which make it faster:
- Excel is written in C++ and compiled natively which will be a bit faster than Java running on the JVM. And Java running as WasmGC is about 2x slower than Java on the JVM.
- Sheets is limited to 4GB of RAM by the browser, Excel isn't.
- C++ can do shared memory multi-threading, WasmGC cannot.
You are forgetting many people use Excel on the Web nowadays, running on the same WebAssembly infrastructure as well.
And Microsoft would rather push everyone to the 365 Web subscription, than keeping selling native Excel, which by the way, nowadays uses plenty of React Native code instead of pure C++, exactly because of code portability to Office 365.
Not claiming it has the same performance as real shared memory,
But at least rough semantics can be had: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Can be read and written from multiple workers / main thread.
Synconized with WASM atomics.
Propgation speed of writes is undefined, likely to leave side channel attack mitigation options without spec-breaking.
1M is xlsx file format limitation, and Excel on Mac can work with 1M just fine. But Excel is spreadsheet and not a database, so if you use it for so big datasets (anything over 1000 rows or so) you are very probably just using plain wrong tool.
Please leave out the snide remarks in spirit of the HN guidelines[1].
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Was that really "name calling"? It's a reference to antennagate and if anything, if you take it within the original context it's really a comment targeting the product Excel, not a person.
Not sure why you’re comparing the c++ Excel to the browser version of sheets. It would make more sense to compare the native version of Excel to the native versions of sheets, ie. android iOS and chromeOS, and the browser sheets to the browser excel.
Why do you suggest that the web version of sheets is faster than the swift or Java versions? I haven’t tried them, and certainly haven’t benchmarked them, but I would imagine they’re faster.
AFAIK the mobile versions are different, since the whole UX is designed for touch control and small screens. It's not full featured, there's a bunch of stuff that you can't do, or are very hard to reach, but that's the limitation of mobile control.
While you technically can run it on ChromeOS through the Android emulation, it's still a mobile app and you're far better off running the web version.
And by "the JS version", you mean the Java version—compiled to run in the browser by targeting its JS engine. There is no JavaScript version. This is a consistent mistake made throughout your article.
It's not an especially rigorous or intellectually honest article. It's a good example of how software development differs from other disciplines. The sleights of hand used in this piece are something that ideally would be rooted out in peer review.
You're comparing JVM bytecode as a compilation target for Java programs vs using JS as an alternative bytecode for Java programs. Unsurprisingly, the former wins. Who knew.
You're right: the article is comparing compilation targets for Java programs (or rather, one specific Java program in this case study). That's my point: despite that being what the article actually is, it's written like it's comparing Java programs to JS programs—the performance that a Java program can achieve versus the performance of a comparable JS program written to give the same results. But again, it's not comparing those. It's comparing how well they can compile Java, in Java source files, to JVM bytecode (or Wasm) and execute it on the corresponding VM versus how well they can get those Java source files to compile and run on v8 and various other JS runtimes. It's an analysis that simply doesn't show what is suggested by the authors' comments (e.g. "The challenge: JavaScript" and "Why is JavaScript slower than Java?" or anywhere that they refer to the (nonexistent) "JavaScript version").
Very sloppy and irresponsible use of language throughout. The whole article is a mess of confused thinking (at best, that is—the alternative is deliberate malfeasance).
I have read it closely no fewer than three times. It's junk and filled with sleights of hand like I already mentioned, which you don't pick up on by not paying enough attention.
The JS was converted to Java and at that time was _at worst_ 5% slower. This might be a shock to you that J2CL is actually good enough to get the same performance as hand-written JS but it's been measured.
There was a similar effort done where the Docs Android app began to run on Java instead of J2CL output and I guess you should be surprised to learn that it was actually slower and significant work had to be put in to make Java running in the JVM faster than that Java (via J2CL) running within a JSVM.
Then that's worse. Because it means that the misleading way the article is written is deliberate.
> This might be a shock to you that J2CL is actually good enough to get the same performance as hand-written JS but it's been measured.
This is such an obnoxious comment when it doesn't have to be, and it's orthogonal to the issue at hand—which is that a Java program compiled to one or more object files that are nevertheless ECMA262-compliant so that it can run on V8 is still a Java program, in the same way that a when you compile a Java program to JVM bytecode, it doesn't stop being a Java program.
There is no "the JavaScript version". There is only the Java version built for different compilation targets. It's not possible to frame it any other way and still be rigorously honest about the results presented here.
(And it's telling that nobody taking issue with my criticism here, and who have proferred a defense of the article that amounts to equivocation, is willing to defend the other passage that I called out that is exemplary of the { Confused XOR Dishonest } way that this article communicates its message. <https://hackernews.hn/item?id=40820423>)
I do wonder if you're intentionally being dense or just not reading the words people write. So I will make this incredible simple for you.
Google Sheets was released in 2006 and "Written in JavaScript" [1].
Around 2014 the codebase is mostly converted to Java. At this time the Java version and JS version's performance are measured and the Java version won't be allowed to launch if it's >5% slower across many use cases.
Note: The Java code isn't emulated by the browser. It's literally converted into a JS source file by GWT and your browser runs it just like any other JS file.
Note: This means the "Java" performance and "JavaScript" performance is equivalent.
Note: Rust is 2015 and full of lifetime markers [3] (i.e. not nearly as ergomatic as it is today); might even have green threads then too.
Around 2018 (?), GWT was replaced by J2CL. Similar story with performance rules.
Note: Not only is the file provided to your browser JS code, the JS file might contain handwritten JS source code for certain "Java files" as opposed to the J2CL output for that file.
Around 2023, J2CL is semi-replaced by WasmGC and WasmGC was 2x faster than the JavaScript being ran by the browser. That generated JS has a similar performance to completely handwritten JS so it's entirely honest to say WasmGC is 2x as fast as JS because
1. It is. It doesn't matter that the JS comes from transpiling Java files; open up a network tab and you'll see it's `.js` files.
2. Transitively it's better than the original handwritten JS files.
---
> And it's telling that nobody taking issue with my criticism here, and who have proferred a defense of the article that amounts to equivocation
No, it's just that you're using jargon to mean different things than other people use that jargon for and getting confused when things don't make sense in your state of the world.
It's a "JS version" because it's the version that is JS code. Much like how the output of J2ObjC produces the ObjC version.
A quick search brings up this RFC to remove green threads [1] which is dated "2014-09-16". So, it's entirely likely that Rust (sure, pre-1.0) had green threads around the time that the Java conversion happened.
Although the only important thing is that WebAssembly is 2015 [2] so there's pretty much no reason to convert to Rust to target WebAssembly when neither of them were actually released.
Yeah, to be clear, I'm not taking any position on what should have been ported. Just that you had indicated you weren't sure when green threads happened, and so I'd figure I'd chime in and let you know the details.
> After all these optimizations, the final WasmGC version of Sheets achieves a calculation performance approximately twice as fast as JavaScript, representing a fourfold improvement from the starting point of the initial WasmGC version.
JavaScript plays fast and loose with types. Which means that when JIT compilers generate code for it, they have to make all sorts of conservative decisions. This makes generated code more complex and, in turn, slower.
Does that make sense?