3 ms·
> People don’t care that an application is a streamlined 3MB or a big round 200MB boy Assuming all else to be equal (UX, functionality, etc), people will absol
by writepub 7y ago
> People don’t care that an application is a streamlined 3MB or a big round 200MB boy
Assuming all else to be equal (UX, functionality, etc), people will absolutely gravitate towards the [5MB storage, 20MB RAM, 0.5% CPU] combination to electron's [300MB storage, 200MB RAM, 5% CPU], especially when they are running multiple such programs.
But, what electron offers is getting from zero to product across all desktop OS-es in arguably the least time possible. So, the real choice is between [PRODUCT_NO_SHIP] to [300MB storage, 200MB RAM, 5% CPU], and we all know what the world chose.
- klingonopera 7y agoThis is actually an issue in app development? I thought with SDL, QT, wxWidgets, et al., writing native apps was basically a covered topic...?
- writepub 7y agoIt is a problem. Here's [1] a talk from fossdem on the various issues, and a couple solutions. [1]: https://youtu.be/ANcU1g7ZWdU https://youtu.be/ANcU1g7ZWdU
- klingonopera 7y agoIt seems to me, that the issue here is mostly web developers who are used to coding for browsers, are slowly moving into the desktop application domain, and instead of them applying the traditional languages used there (C and C++), are circumventing these by creating frameworks that allow them to continue using their web langs in a desktop environment. If that is the case... they'll never get rid of the megabyte bloats. That's basically just baseline overhead from a browser engine itself. Crazy idea: Reverse the entire process? Use C for everything, including web tasks, i.e. FastCGI? Correct me if I'm wrong, but with WebAssembly around, is it possible that C programming might make a comeback into web development?
- writepub 7y agoI think the central problem with native UI is how much better looking web-based UIs are, and the talk I cited spends time making this point. HTML/CSS/Js built UIs have much better, modern, reactive styling options & when done properly, look much better than, say GTK. I'm personally a huge proponent of C and would love to have access to WebApis [1] via Webassembly. That would still necessitate a runtime capable of interpreting HTML/Css into views, but projects like webview [2] have demonstrated that this access needn't come at a huge cost. For instance, in [3], for a UI in HTML/CSS with business logic in C, system resources clock in at [RAM: 6MB, CPU: 1.3% Storage: 10MB], which is completely reasonable. [1]: https://github.com/WebAssembly/webidl-bindings/blob/master/proposals/webidl-bindings/Explainer.md https://github.com/WebAssembly/webidl-bindings/blob/master/p... [2]: https://github.com/zserge/webview https://github.com/zserge/webview [3]: https://fosdem.org/2019/schedule/event/godesktopapps/attachments/slides/2994/export/events/attachments/godesktopapps/slides/2994/slides.pdf#page=19 https://fosdem.org/2019/schedule/event/godesktopapps/attachm...
- klingonopera 7y agoWow, thanks, those resources will hopefully keep me busy later... I'm building a cross-platform C engine, and had the usual suspects of "Windows, Linux, maybe Mac", but then recently also "discovered" this ancient FastCGI technology, and just day or two ago skimmed the WebAssembly wiki, and I'd like to explore possibilities of implementing my engine in web applications, too, afterwards. But if I understand WebView correctly, wouldn't this be HTML in C/C++, i.e. is WebView... "just" a browser? Or... is it "just" spawning a minimal OS-Window on the target system with a system-built-in browser engine? For my intents and purposes, that's kinda the reverse of what I'm aiming for with my C project, which rather would be to bring sprites and raw data formats to your browser window. In essence, what I meant with "reversing everything with C" is basically programming webpages like C programs. Taken to the extreme, what I mean is for example compiling Windows to run in a browser-context instead of a physical x86-PC.