4 ms·

I would say that 90% of my pc resources are consumed to execute JavaScript code. If we need dedicated hardware to execute this more efficiently so be it. We do

I would say that 90% of my pc resources are consumed to execute JavaScript code. If we need dedicated hardware to execute this more efficiently so be it. We do it anyway for so many other domains. Video, graphics, encryption etc.

deleted 6y ago
[deleted]
Jetrel 6y ago
One of the big deals with electron-et-al is that we're not married to JavaScript, really; we're married to "the DOM and css" as our gui, and things like FF/Chrome/Safari devtools to develop that gui. Most javascript developers are already using babel-et-al pipelines to build electron apps, which are already transpiling between major variants of javascript, and I wouldn't at all surprised to see a thing where it gets compiled into WebAssembly rather than interpreting javascript. I also think there's a thing, right now, where it's possible to build electron apps with Rust+WebASM; I'm not sure, but I think the main thrust here is it definitely would eliminate a huge chunk of the slowdown. I guess the main takeaway is just that the development revolution that's happened recently is mainly about how insanely good browser dev tools have become, and not about javascript - javascript was just along for the ride. As an aside - I recently saw a video of someone demoing one of the old Symbolics LISP workstations, and I was shocked to realize how much they had in common with a modern browser console - specifically of being able to inspect all of your gui components, live, and look at all the properties set on them. It's provided a hell of a way for me to explain what the deal was with all the old gurus in the 80s "AI Winter" diaspora who were pretty butthurt about having to move from programming in that environment, to having to write C on DOS (or whatever else paid the bills at the time).
- xvilka 6y ago
  WebAssembly is just another JVM which is notoriously slow for GUI compared to the native alternatives like Qt.
rmorey 6y ago
There basically already is in the M1: https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de... tl;dr it has really sick floating point double performance which directly translates to JS performance
- saagarjha 6y ago
  Most JavaScript JITs do math on integers.
  - rmorey 6y ago
    Only if using the BigInt type: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... all other numbers are floats
    - saagarjha 6y ago
      No, this is independent of BigInt. JITs speculate that numbers are integers for performance.
      - rmorey 6y ago
        Hmmmm okay! I see what you're saying now.

deleted 6y ago

[deleted]

Jetrel 6y ago

One of the big deals with electron-et-al is that we're not married to JavaScript, really; we're married to "the DOM and css" as our gui, and things like FF/Chrome/Safari devtools to develop that gui. Most javascript developers are already using babel-et-al pipelines to build electron apps, which are already transpiling between major variants of javascript, and I wouldn't at all surprised to see a thing where it gets compiled into WebAssembly rather than interpreting javascript. I also think there's a thing, right now, where it's possible to build electron apps with Rust+WebASM; I'm not sure, but I think the main thrust here is it definitely would eliminate a huge chunk of the slowdown. I guess the main takeaway is just that the development revolution that's happened recently is mainly about how insanely good browser dev tools have become, and not about javascript - javascript was just along for the ride. As an aside - I recently saw a video of someone demoing one of the old Symbolics LISP workstations, and I was shocked to realize how much they had in common with a modern browser console - specifically of being able to inspect all of your gui components, live, and look at all the properties set on them. It's provided a hell of a way for me to explain what the deal was with all the old gurus in the 80s "AI Winter" diaspora who were pretty butthurt about having to move from programming in that environment, to having to write C on DOS (or whatever else paid the bills at the time).

xvilka 6y ago
WebAssembly is just another JVM which is notoriously slow for GUI compared to the native alternatives like Qt.

rmorey 6y ago

There basically already is in the M1: https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de... tl;dr it has really sick floating point double performance which directly translates to JS performance

saagarjha 6y ago
Most JavaScript JITs do math on integers.
- rmorey 6y ago
  Only if using the BigInt type: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... all other numbers are floats
  - saagarjha 6y ago
    No, this is independent of BigInt. JITs speculate that numbers are integers for performance.
    - rmorey 6y ago
      Hmmmm okay! I see what you're saying now.