3 ms·
this is interesting , so i can turn electron into a native app now? whats the use case for this , make it hard to reverse engineer my node projects?
by zuzululu 3mo ago
this is interesting , so i can turn electron into a native app now?
whats the use case for this , make it hard to reverse engineer my node projects?
- repeekad 3mo agoSome of us don’t like Spotify, Slack, Discord, and a simple notes app taking 1-2GB of RAM each..
- isaachinman 3mo agoThis is a really important question. If true, it could end a lot of Electron wastefulness.
- jorisw 3mo agoDon’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
- nkmnz 3mo agoNothing 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.
- queenkjuul 3mo agoIm 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
- jonasdoesthings 3mo agoanother 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 https://bun.com/docs/bundler/executables
- lpribis 3mo agoStill need the entire browser DOM, APIs, layout, renderers, etc outside of JS.
- queenkjuul 3mo agoIm 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