As much as I'm all in favour of blaming AI bros for the RAM shortage, there was always going to be a squeeze on RAM prices for some reason eventually, and we really did make sure it would be maximally painful for ourselves when we started treating RAM as functionally free.

RAM prices in 2026 are about the same as they were in 2008 when the original MacBook Air launched. It had 2GB of RAM and it ran like a goddamn dream. There is absolutely zero technical reason we couldn't ship an even better computer with 2GB RAM today — except everything these days is a JavaScript app running in a dedicated Chromium instance and needs at least its own gigabyte to run around in.

That said, it's probably pretty safe to blame AI bros for everything being a Chromium instance — I'm willing to bet it's largely the same people trying to ship something that just about works with the absolute minimum of time and effort now as it was then

@andrewt What's less bad: an application built as a Chromium instance, or a native application that ends up unavailable to most users because Linux and Windows don't implement the Cocoa API of macOS?
@PinoBatch I mean yes, cross-platform releases are a great thing — but the day before Electron came out we already had the JVM and .NET/Mono so I'm not sure what Electron contributed there except that now we can make our cross-platform apps in a language with no native support for integers, with UIs that diverge wildly from the native OS conventions

@andrewt JVM was owned by Oracle since 2010, and the ASF felt frustrated about inability to license the Technology Compatibility Kit (TCK) for Harmony. Mono's reimplementation of .NET Windows Forms always felt janky and crash-prone in my experience as a user.

I've seen WebAssembly as a successor to the JVM, except less opinionated about a particular object-oriented paradigm and not under encumbrance of One Rich American Called Larry Ellison.

#java #dotnet #wasm

@PinoBatch Oh yeah, there are some very good reasons JVM and .NET didn't catch on like Electron did — but they do at least prove that cross-platform app development can be done with reasonably sized dependencies shared between apps.

Heck, Tauri manages that, and that's just Electron but using the OS' native webview. Even if we accept that the web is the best shared abstraction we have, we don't need to ship a whole browser with every app

@andrewt I think one of the reasons that Electron caught on as opposed to Tauri's approach of using the system HTML renderer is that Apple WebKit was missing so much compared to Blink and Gecko. See "Progress Delayed Is Progress Denied" by Alex Russell.
https://infrequently.org/2021/04/progress-delayed/
Progress Delayed Is Progress Denied

Apple's iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store. This is a bold assertion, and proving it requires examining the record from multiple directions.

Alex Russell
@andrewt @PinoBatch and additionally, im pretty sure its possible to make webapps that dont require absurd amounts of memory, even if you're using JS and not WASM.
@andrewt @PinoBatch I am not sure it's a good reason but most 'application's today don't really have a protocol, they are intended to run an up-to-date collection of minified javasctipts directly off the platform provider's cloud server, and out-of-date collection of javascripts is not supported.

It's possible to repackage that collection of javascripts as an electron 'application' but it's not really feasible to replicate and maintain that in a different language.