51–60 of 289 posts
Earlier quoted context omitted.
Yes - WebAssembly. It would hopefully kill the whole thing as an end game.
I have a, probably misguided, fear that We Assembly will inadvertently usher in an era of read only web, basically breaking the "view source" idea almost unique to the Web.
Earlier quoted context omitted.
> "Separate instances of chrome for every app is dumb and consumes too much memory" That one is true though. Different Electron apps could at least share the runtime.
Except they cannot, Chromium (or is it Blink?) changes too frequently to reliably code for one version and expect backward compatibility of future releases. Electron versions could be shared libraries... except again BC breaking releases proliferate.
Hey, another electron thread. Wait a second, did someone already mention how horrible Javascript is? The memory consumption? The minimal integration into the OS/desktop (think accessibility)? Hmm ok, I need something new... Here it comes: chrome is inherently instable. The Google developers give a shit about their dependency management and have trillions of open source projects just literally copied into their trunk.…
Disclaimer: Electron dev So few quick things, the projects that are copied are done so to guarantee deterministic builds in an isolated build environment (no dependencies on third party systems). The API you say they don't provide is literally the API that Electron uses. --> https://chromium.googlesource.com/chromium/src/+/HEAD/conten... And as for the build process, eh, it's kinda slow but it's hardly arcane. On lin…
Give it a try with the current HEAD of their home-grown and undocumented build tool and see how far you get.
And regarding the deterministic builds: I call bullshit. They just don't want to follow the different packaging guidelines from the different operating systems, so they repackage everything. Now I have to trust them to keep all these dependencies up-to-date and I have to accept the unecessary bloat? No way.
There's hate directed at performance, but Electron apps are just profoundly buggy . For example in Slack: 1. Non-functional items are routinely offered in the main menu and context menu. 2. The Undo and Redo menu items often just don't work. These do different things than the command key equivalents which should never happen. 3. It is easy to get into a state with multiple blinking insertion points. 4. The inactive a…
Earlier quoted context omitted.
I'd rather see SwiftUI or something like it ported to other systems with a "driver" that translates it to each platform's 100% native UI. It's already amazing in how it abstracts common elements for such distinct environments like desktop, phone, TV and watch while still exposing OS-specific features. Why not other operating systems?
Insert any framework in place of SwiftUI. You're describing Qt, essentially. The approach has been tried, and succeeded to some degree. But the web is the only app where cross-platform is the default , and it's truly hard to avoid it. Even if the widgets all look different. Even if nothing looks native (people got used to it anyway). And to be clear I want the status quo to improve in this regard, especially in terms…
SwiftUI's syntax feels closer to a markup language than code, though, so it might be more appealing to web frontend devs.
Earlier quoted context omitted.
Agreed. We need a cross-OS definition of "web views" and a standard way to say, "use my default browser for all web views, including Electron".
It seems like that's not really going to work for the developers of these apps due to browser variation and version skew? (If it were okay, why aren't they supporting web browsers already?) But maybe apps on the same version of Electron could share a runtime?
It also comes as an Electron app, because it wants more system privileges than browser tabs are ever allowed to get -- to tell people what game you're playing.
There's hate directed at performance, but Electron apps are just profoundly buggy . For example in Slack: 1. Non-functional items are routinely offered in the main menu and context menu. 2. The Undo and Redo menu items often just don't work. These do different things than the command key equivalents which should never happen. 3. It is easy to get into a state with multiple blinking insertion points. 4. The inactive a…
Earlier quoted context omitted.
I'd rather see SwiftUI or something like it ported to other systems with a "driver" that translates it to each platform's 100% native UI. It's already amazing in how it abstracts common elements for such distinct environments like desktop, phone, TV and watch while still exposing OS-specific features. Why not other operating systems?
Insert any framework in place of SwiftUI. You're describing Qt, essentially. The approach has been tried, and succeeded to some degree. But the web is the only app where cross-platform is the default , and it's truly hard to avoid it. Even if the widgets all look different. Even if nothing looks native (people got used to it anyway). And to be clear I want the status quo to improve in this regard, especially in terms…
No. Chrome is the only platform that is cross platform by default. But IE, eg, has definitely had behavior differences in the past.
On the other hand, Qt is cross language, but not necessarily cross platform (it excludes iPhone and Android, say)