3 ms·

WebAssembly is basically the latest in the line of Java Applets and Macromedia Flash. Maybe it'd be useful if someone built a tiny wasm emulator for x86 linux s

by jart 6y ago

WebAssembly is basically the latest in the line of Java Applets and Macromedia Flash. Maybe it'd be useful if someone built a tiny wasm emulator for x86 linux stdio binaries and posted it on a google cdn. I haven't seen anyone do that yet. I'm pretty happy with web pages as a GUI framework. If I needed a desktop GUI, I certainly would not want my binaries to be 200megs with Electron. If we're OK trading away drop-down boxes, wizards, and installers, then it's actually possible to build 10kb static native win32+linux+bsd+mac terminal programs using ape. https://justine.storage.googleapis.com/ape.html https://justine.storage.googleapis.com/ape.html

giancarlostoro 6y ago
> I certainly would not want my binaries to be 200megs with Electron. We're discussing how to avoid this overhead.
- jart 6y ago
  You asked me how to avoid the overhead of Electron and I suggested you try αcτµαlly pδrταblε εxεcµταblε since the distributables are 10,000x smaller. If it's not possible to meet your requirements using a command line c program, or a web application that runs in the browser, then could you help me understand why you need electron?
  - giancarlostoro 6y ago
    I'm not advocating for Electron... I think either you're misunderstanding me or we're misunderstanding each other (quite possible as well). I'm advocating for some small cross-platform cross-language API / runtime / framework (not sure what it looks like, but since most languages are targetting WASM (if this is what's making you think I'm advocating for Electron... then you missed my commentary about people making stand alone WASM runtimes) as opposed to solutions that are platform or language specific, and when I say platform specific lump in web (which means Electron too) in that bucket. What most people want is to be able to use their own preferred language and do a UI without having to import a bunch of C or C++ libraries that will add additional overhead over their language. Edit: Just saw the post you were referring to, it would of made more sense had you linked to it: https://news.ycombinator.com/item?id=24256883 https://news.ycombinator.com/item?id=24256883 While this answers the 1 binary problem while producing a rather massive executable file larger than Electron in many cases, this still doesn't solve the problem I'm mentioning: We need a cross-platform cross-language UI solution. If you want to do away with things like Electron, you need to consider all platforms and all languages.

by jart 6y ago

giancarlostoro 6y ago

> I certainly would not want my binaries to be 200megs with Electron. We're discussing how to avoid this overhead.

jart 6y ago
You asked me how to avoid the overhead of Electron and I suggested you try αcτµαlly pδrταblε εxεcµταblε since the distributables are 10,000x smaller. If it's not possible to meet your requirements using a command line c program, or a web application that runs in the browser, then could you help me understand why you need electron?
- giancarlostoro 6y ago
  I'm not advocating for Electron... I think either you're misunderstanding me or we're misunderstanding each other (quite possible as well). I'm advocating for some small cross-platform cross-language API / runtime / framework (not sure what it looks like, but since most languages are targetting WASM (if this is what's making you think I'm advocating for Electron... then you missed my commentary about people making stand alone WASM runtimes) as opposed to solutions that are platform or language specific, and when I say platform specific lump in web (which means Electron too) in that bucket. What most people want is to be able to use their own preferred language and do a UI without having to import a bunch of C or C++ libraries that will add additional overhead over their language. Edit: Just saw the post you were referring to, it would of made more sense had you linked to it: https://news.ycombinator.com/item?id=24256883 https://news.ycombinator.com/item?id=24256883 While this answers the 1 binary problem while producing a rather massive executable file larger than Electron in many cases, this still doesn't solve the problem I'm mentioning: We need a cross-platform cross-language UI solution. If you want to do away with things like Electron, you need to consider all platforms and all languages.