9 ms·

> 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

> 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.

JeanMarcS 3y ago
> I'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now Well, a solution might be to share the chromium "vm" across all electron app, but maintaining compatibility will be horribly difficult so, no I guess.
- endisneigh 3y ago
  you solve it the same way you do with iOS and Android - an LTS release with careful deprecation of APIs.
- easton 3y ago
  Microsoft has this on Windows: https://learn.microsoft.com/en-us/microsoft-edge/webview2/ https://learn.microsoft.com/en-us/microsoft-edge/webview2/ Teams 2 is supposed to use it (and there's a couple smaller system apps that use it).
BigJ1211 3y ago
> Around the speed of Java and Go in some cases, which are compiled. That is quite the claim, I wonder if you have any data to back that up. As it goes against everything I've seen.
- endisneigh 3y ago
  You really should take benchmarks with a grain of salt, but: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... There are others as well like: https://programming-language-benchmarks.vercel.app/go-vs-javascript https://programming-language-benchmarks.vercel.app/go-vs-jav... 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.
- tyingq 3y ago
  "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.
- coldtea 3y ago
  Is it "quite the claim"? 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!
  - chrismorgan 3y ago
    It is still quite the claim. 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.
paulgb 3y ago
> 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.
- shortrounddev2 3y ago
  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
  - jasode 3y ago
    >I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. This page has a list of examples: https://madewithwebassembly.com/ https://madewithwebassembly.com/ Many apps that are not CRUD need more efficient cpu performance of WASM... physics rendering engines, AutoCAD modeling, machine learning, etc.
    - shortrounddev2 3y ago
      Oh yeah I'm sure those applications exist, I just don't seem to use or work on any of them
  - zztop44 3y ago
    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…
    - shortrounddev2 3y ago
coldtea 3y ago
>For a web app the speed of the language is rarely the bottleneck anyway, other than some exception cases like WebGL-type stuff. If we're talking about a glorified form/CRUD app, no. For web apps proper, that's not really the case.
- endisneigh 3y ago
  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.
MereInterest 3y ago
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.
guggle 3y ago
> 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.
rhaway84773 3y ago
I suspect MS is working on some sort of common browser layer for Electron apps on Windows. Their primary reasoning for picking V8 for Edge was that node, electron etc were built on V8. We haven’t seen anything specific to those environments in Windows yet. I expect that to probably change pretty soon.
DarkNova6 3y ago
> 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.
- gizmo 3y ago
  Quake 1 (about 100k lines of C) runs in the browser just fine: https://www.netquake.io/quake https://www.netquake.io/quake 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.
  - stanleydrew 3y ago
    That quake demo is surely running on the WASM runtime which isn't really related to JavaScript: https://en.m.wikipedia.org/wiki/WebAssembly https://en.m.wikipedia.org/wiki/WebAssembly
    - medo-bear 3y ago
      now you can make web apps in your compiled language of choice (limited choice) and not worry (as much) that its not fast enough
    - chrisco255 3y ago
      Webassembly started its life as a JS hack, called asm.js: https://en.wikipedia.org/wiki/Asm.js https://en.wikipedia.org/wiki/Asm.js, which itself was fully capable of running Quake. Here's the Unreal engine demo from 10 years ago: https://www.youtube.com/watch?v=XsyogXtyU9o https://www.youtube.com/watch?v=XsyogXtyU9o
- fouric 3y ago
  > Sorry, not even remotely close. I want to see some serious evidence. Funny that you say "not even remotely close" while providing zero evidence yourself, but then ask other people to present their evidence. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... There you go. There's the evidence. No goalpost-moving, please. For evidence that Javascript can be used to build large, production-quality applications, see coldtea's comment: https://news.ycombinator.com/item?id=37568707 https://news.ycombinator.com/item?id=37568707
paulddraper 3y ago
> 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. Indeed, JS is pretty darn fast. Not because of innate characteristics, but because of the human-centuries spent optimizing JIT VMs.
- deleted 3y ago
  [deleted]
jwells89 3y ago
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.

JeanMarcS 3y ago

> I'm honestly surprised the Chromium team hasn't already addressed this with the Electron team somehow by now Well, a solution might be to share the chromium "vm" across all electron app, but maintaining compatibility will be horribly difficult so, no I guess.

endisneigh 3y ago
you solve it the same way you do with iOS and Android - an LTS release with careful deprecation of APIs.
easton 3y ago
Microsoft has this on Windows: https://learn.microsoft.com/en-us/microsoft-edge/webview2/ https://learn.microsoft.com/en-us/microsoft-edge/webview2/ Teams 2 is supposed to use it (and there's a couple smaller system apps that use it).

BigJ1211 3y ago

> Around the speed of Java and Go in some cases, which are compiled. That is quite the claim, I wonder if you have any data to back that up. As it goes against everything I've seen.

endisneigh 3y ago
You really should take benchmarks with a grain of salt, but: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-node.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... There are others as well like: https://programming-language-benchmarks.vercel.app/go-vs-javascript https://programming-language-benchmarks.vercel.app/go-vs-jav... 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.
tyingq 3y ago
"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.
coldtea 3y ago
Is it "quite the claim"? 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!
- chrismorgan 3y ago
  It is still quite the claim. 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.

paulgb 3y ago

> 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.

shortrounddev2 3y ago
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
- jasode 3y ago
  >I've always wondered what kind of apps these are. The vast majority of web apps I use are all CRUD. This page has a list of examples: https://madewithwebassembly.com/ https://madewithwebassembly.com/ Many apps that are not CRUD need more efficient cpu performance of WASM... physics rendering engines, AutoCAD modeling, machine learning, etc.
  - shortrounddev2 3y ago
    Oh yeah I'm sure those applications exist, I just don't seem to use or work on any of them
- zztop44 3y ago
  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…
  - shortrounddev2 3y ago

coldtea 3y ago

>For a web app the speed of the language is rarely the bottleneck anyway, other than some exception cases like WebGL-type stuff. If we're talking about a glorified form/CRUD app, no. For web apps proper, that's not really the case.

endisneigh 3y ago
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.

MereInterest 3y ago

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.

guggle 3y ago

> 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.

rhaway84773 3y ago

I suspect MS is working on some sort of common browser layer for Electron apps on Windows. Their primary reasoning for picking V8 for Edge was that node, electron etc were built on V8. We haven’t seen anything specific to those environments in Windows yet. I expect that to probably change pretty soon.

DarkNova6 3y ago

> 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.

gizmo 3y ago
Quake 1 (about 100k lines of C) runs in the browser just fine: https://www.netquake.io/quake https://www.netquake.io/quake 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.
- stanleydrew 3y ago
  That quake demo is surely running on the WASM runtime which isn't really related to JavaScript: https://en.m.wikipedia.org/wiki/WebAssembly https://en.m.wikipedia.org/wiki/WebAssembly
  - medo-bear 3y ago
    now you can make web apps in your compiled language of choice (limited choice) and not worry (as much) that its not fast enough
  - chrisco255 3y ago
    Webassembly started its life as a JS hack, called asm.js: https://en.wikipedia.org/wiki/Asm.js https://en.wikipedia.org/wiki/Asm.js, which itself was fully capable of running Quake. Here's the Unreal engine demo from 10 years ago: https://www.youtube.com/watch?v=XsyogXtyU9o https://www.youtube.com/watch?v=XsyogXtyU9o
fouric 3y ago
> Sorry, not even remotely close. I want to see some serious evidence. Funny that you say "not even remotely close" while providing zero evidence yourself, but then ask other people to present their evidence. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... There you go. There's the evidence. No goalpost-moving, please. For evidence that Javascript can be used to build large, production-quality applications, see coldtea's comment: https://news.ycombinator.com/item?id=37568707 https://news.ycombinator.com/item?id=37568707

paulddraper 3y ago

> 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. Indeed, JS is pretty darn fast. Not because of innate characteristics, but because of the human-centuries spent optimizing JIT VMs.

deleted 3y ago
[deleted]

jwells89 3y ago

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.