So every app using it has all of #Electron’s disadvantages:
• lowest-common-denominator #GUI obviously foreign to the host OS
• non-portable shims to integrate with host OS features
• an individually bespoke runtime consuming storage, memory, and compute as if it were a separate virtual machine
For me it is: there is more freedom to choose which GUI system you like without being forced to change the OS just because you dislike the GUI. YMMV @mjgardner@andros@marcolas
@mjgardner@marcolas But any graphic application works that way. On the one hand you have the language and on the other the graphical interface libraries. There is no extra memory expense. The binary is a few megabytes.
Electron is another topic, since it is a complete browser for creating web apps as desktop applications.
@andros@marcolas Web applications use #JavaScript to shoehorn themselves into an environment designed to browse hyperlinked documents.
And “#Emacs applications” (e.g., Org Mode, Gnus, calendar/diary, ERC, and even multiple web browsers!) use #Elisp to shoehorn themselves into an environment designed to edit text documents.
You’re so blinkered by the ubiquity of apps shoehorned inside apps that you’ve forgotten the compromises they introduce.
@andros@marcolas The problem is that developers have prioritized their own convenience while wasting users’ time learning each app and wasting users’ money on more computing power, memory, and storage
@mjgardner@andros@marcolas The problem isn't what a framework was designed to do IMHO, it's what the tradeoffs are. A framework designed for one purpose may find use in other fields. Of course, there are issues with the way many web apps are distributed, but I don't think that makes web apps uniquely bad across the board.
The issues of bad performance and large apps are often the result of distributing painfully old versions of chromium with security holes with every app. The solution is to leverage the web for a web app, so people can run it in their actual browser, which is what PWAs were supposed to be.
Same thing here; I don't think making an app in Elisp is bad, even less so than JS, actually. Emacs has a culture of creating individual packages which are installed on top of your Emacs package, so you don't need one Emacs per application.
@mjgardner@andros Okay, I'll bite: I know that webapps are problematic in the real world, but that largely seems to be a problem of market pressures and profit incentives forcing developers to not properly optimize and focus on features instead, as well as it not being good enough (in the eyes of managers) to just ship a website, but it has to actively be installed (Electron).
The worst offenders have, in my experience, always been proprietary web apps; Discord, Teams, Spotify, MS Office, YouTube etc. The only bad example I can really come up with of a FOSS app being this bad is VSCode, which I haven't used much. Then there are some which I find to work great, like OnlyOffice, Jitsi, and Element, and all of them run well across browsers.
Maybe you've encountered more bad examples, but my experience leads me to believe that it's more the the devs or the pressures on the devs which make the apps bad than HTML/CSS.
@boo_@andros I’m acutely aware of the top-down macro pressures via warped economics, markets, and management. And while I live on the salary that comes from them, I fight at that level too.
My responses in this thread have been about fighting from the bottom up. One can do both.
@mjgardner@andros Okay, from your responses in this thread, it sounded a lot like arguing against the usage of web tech/non native platforms overall. My argument is that these issues don't stem from using non-native dev platforms (where appropriate), under the assumption that was what you were arguing against, as I doubt someone's gonna make a commercial project on top of Emacs.
@boo_@andros I didn’t foresee anyone turning Google’s #Chrome browser #JavaScript engine V8 (2008) into the server (#NodeJs, 2009) and desktop (#ElectronJs, 2013) runtimes that ate the world, but here we are.
And Electron was originally developed for #GitHub’s #Atom text editor (2008) before they were acquired by #Microsoft in 2018, subsequently discontinued in favor of #VSCode in 2022.
Don’t tell me what you can’t see happening if you don’t remember what already did
@andros@marcolas The better applications share common libraries, usually provided by the operating system, so that:
• users can carry across their knowledge of how to use each app
• developers can carry across their knowledge of how to implement features
• the computer only has to store and keep in memory a single library of the same functions… (1/2)
These advantages are thwarted by each app including their choice of competing libraries, whether they duplicate ones provided by the OS or, as in Linux’s case, have to include or depend on their unique batch of them because the OS doesn’t have a standard set. (2/2)
Add comment