7 ms·

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

• goldenkey 5y ago
  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..
  • xg15 5y ago
    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.
    • goldenkey 5y ago
      https://developers.google.com/web/updates/2011/09/Workers-ArrayBuffer 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.
      • int_19h 5y ago
        You still need to serialize/deserialize to put your object graph into the array, no?
        • goldenkey 5y ago
          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=wasm https://github.com/microsoft/vscode/search?q=arraybuffer https://github.com/microsoft/vscode/search?q=arraybuffer https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API https://developer.mozilla.org/en-US/docs/WebAssembly/Using_t... https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
          • npigrounet 5y ago
            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.
            • hoseja 5y ago
              Let's wait thirty years for the legacy to accrue and then compare weenies, shall we?
              • npigrounet 5y ago
                In thirty years, every single codebase will have been re-written in JS.
                • hoseja 5y ago
                  Ah, I see. I appreciate the effort but maybe try being subtler, I was almost mad until you overdid it.
            • int_19h 5y ago
              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.
          • Jensson 5y ago
            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.