4 ms·
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/Chro
by Jetrel 5y 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 5y agoWebAssembly is just another JVM which is notoriously slow for GUI compared to the native alternatives like Qt.