another use case is getting standalone self-contained binaries which are easier to ship.

other projects like claude code use something like `bun build --compile`[^1] for that, which instead of producing a small native binary just bundle the JS runtime into the executable.

[^1]: https://bun.com/docs/bundler/executables

Some of us don’t like Spotify, Slack, Discord, and a simple notes app taking 1-2GB of RAM each..

This is a really important question. If true, it could end a lot of Electron wastefulness.

Don’t see how compiling Typescript changes how little Electron cares about the host OS in terms of UI and how it just ships Chromium in order to show any UI at all

Nothing more horrible than apps that "care about the host OS in terms of UI", thus looking different on every type of device I have to use for work.

Im 99% certain it cannot. This seems better suited to server side projects.

Deno is building a less-wasteful Electron style framework for native desktop apps

Still need the entire browser DOM, APIs, layout, renderers, etc outside of JS.

Im 99℅ certain this could not handle an Electron project.

The use case, imo, is to be able to write server side code in familiar TypeScript, then deploy it as a small single native binary (vs Node and Bun which embed the entire 100MB+ runtime when you build a native binary.) Electron for the record ships their own modified Node runtime (not ABI compatible) on top of the whole Chromium renderer