Hacker News Reader

Comment by r-w | Hacker News Reader

We're talking about small, quick operations supporting a synchronous, interactive user interface here. When it comes to performance, asymptotics aren't everything.

View on HN

JS has Workers. VS Code uses them wisely. Other Electron apps? Not so much.

Block the event loop in other languages and you'll also see shitty results..

Have fun implementing all the overhead just communicating with those workers. That's a serialisation pass, a serialisation pass and two event queues, all just so your application doesn't lock up.

https://developers.google.com/web/updates/2011/09/Workers-Ar...

For 10 years an ArrayBuffer has been able to be sent by reference but good effort on disinformation.

You still need to serialize/deserialize to put your object graph into the array, no?

Not if you use WebAssembly. You can simply pass an Array Buffer to be worked on, you postMessage it with transferable=true.

  transfer Optional
  An optional array of Transferable objects to transfer ownership of. If the ownership of an object is transferred, it becomes unusable in the context it was sent from and becomes available only to the worker it was sent to.

You can compile JS itself or pretty much any other language to WASM using Emscripten or the other LLVM toolkits. Looking at VSCode, it appears they use this technique for some of the heavy lifting.

JS is very performant if you know how to use this hybrid architecture. The C++ guys above are shitting all over JS when an Electron app can simply use C++ transpiled to WASM if they really wanted to. Electron isn't really for JS as a coding language. It is much more for the awesome cross-platform UI you get with HTML, CSS, and JS. A lot has been done to optimize rendering engines. The same techniques that render snappy web pages can be used within Electron. All the griping above is really just ignorance.

https://github.com/microsoft/vscode/search?q=wasm

https://github.com/microsoft/vscode/search?q=arraybuffer

https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t...

https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...

Why use C++ when JS is faster? VSCode proves that. It's orders of magnitude faster than old VS, has more features, uses less resources, etc.

Let's wait thirty years for the legacy to accrue and then compare weenies, shall we?

VSCode does not prove that at all. The main reason why it feels faster is because it's written from scratch to be async. VS is a legacy codebase going all the way to 1997 (if not earlier, in places), with lots of code still running on UI thread, and all extensions running in-process.

WASM isn't Javascript. WASM is a way to represent native code in Javascript that some Javascript runtimes then can use to run it as native code. If the Javascript runtime hasn't implemented a hack to run WASM as native code then WASM is ridiculously slow. If the VSCode team writes their code in C++, compiles it to WASM and then runs WASM and it is fast, then it was C++ that was fast and not Javascript.

If that is really how they got their performance then no wonder that few others actually managed to do it, because most teams wouldn't write their Electron app in C++ and then compile it to WASM. The difference is that Microsoft has a ton of C++ engineers so they could do it easily, but I doubt many Electron teams put out job postings to hire C++ people.

That's like saying if you use the _asm directive in any language, your entire project is now assembly. Subtlety is not your strong suite. One can use WASM for manual memory critical paths while using raw JS for other parts. And you did not hear me. You can write WASM in JS. Transpiling. Amazing, huh?

And how fast is JS compiled to wasm? Are you claiming that it's also as fast as C++ compiled to wasm?

Yes, Typescript to WASM is just as fast as C++ to WASM.

Reply on news.ycombinator.com