trading speed of development with 'hardware optimization'.
Mac being a small market, some users are still opiniated/loud enough to reward nicer/native UI vs cross-ish platform lowest common denominator UI.
Maybe there is hope Arm mac stays fast.
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.
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).
It's slightly more nuanced than that - you can of course just block it from doing so, and there's certainly an argument for it being updated to not need a network call each time, but phrasing it like this makes it sound worse than it actually is.
I'll just quote Jeff Johnson, who's looked into this and written about it - his comment[1] on this is post is quite useful:
>The request to http://crl.apple.com/root.crl is simply checking the revocation status of Apple’s own Developer ID Certification Authority intermediate signing certificate. If you examine the cert in the System Roots keychain, you can see that URL under CRL Distribution Points. This request contains no information specific to third-party developers or apps. In contrast, there’s no CRL for third-party Developer ID leaf certs signed by Apple’s intermediate cert. Their status is only available via OCSP.
Notably, this:
>This request contains no information specific to third-party developers or apps.
The parent comment is incorrectly stating that each request to Apple is checking a binary, and it's not. This has been well documented both here on HN and across the web.
That's not the definition of refute. The distinction between a lazy-implied always and merely often is pedantic. The point is that it happens enough to reduce performance, while doing something no end-user asked for and is difficult, if not impossible to disable without reducing other security protections.
I don't know what qualifies as a success, but I saw in Git Tower's developer survey that it has about 5% share. The share of the whole developer industry should be lower, because Tower's audience is interested in premium tools, but I expected it to be struggling to break 1%. https://www.git-tower.com/blog/mac-dev-survey-2021-results
trading speed of development with 'hardware optimization'.
Mac being a small market, some users are still opiniated/loud enough to reward nicer/native UI vs cross-ish platform lowest common denominator UI. Maybe there is hope Arm mac stays fast.