241–250 of 418 posts
Smart move from the Deno team to get me to try out their ecosystem. I probably wouldn't have bothered prior. I've been mostly fine with npm, as its been much faster of late, and the security features recently released are good.
Earlier quoted context omitted.
Consistency is a large factor in any good design, UI design more so.
Consistent like what? Like maybe a decade ago one could say that osx was consistent, but nowadays even SwiftUI and cocoa is visibly different, let alone every second app that uses electron. And people don't care. Windows has like 4 frameworks available on a bare new, latest OS install, just go deep enough in the "settings" or whatever they call it, and you can reach down to winforms. And on top the start menu is a re…
Earlier quoted context omitted.
Consistency is a large factor in any good design, UI design more so.
Consistent like what? Like maybe a decade ago one could say that osx was consistent, but nowadays even SwiftUI and cocoa is visibly different, let alone every second app that uses electron. And people don't care. Windows has like 4 frameworks available on a bare new, latest OS install, just go deep enough in the "settings" or whatever they call it, and you can reach down to winforms. And on top the start menu is a re…
Earlier quoted context omitted.
I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits. I see it in a different way. The fact that "web UI slop" has managed to make great inroads on the desktop is an indictment of the state of native toolkits. If you think it's a problem that desktop apps are being written with web toolkits, the solution for that isn't to shame (as the…
Yes, native UI toolkits are not perfect, even though I consider Qt very close to one (I'm sure naysayers will find nitpicks). In the end, the choice is between the apps that eat 1GB of your RAM and learning to deal with some idiosyncrasies of native toolkits.
So thankfully we can still have our REPLs with live reloading and nice documentation (MDN, W3schools etc.) and large library of embeddable UI components without most the costs of using electron.
> Web technology is the most widely-known UI toolkit in the world. Poor choice of words there IMHO. The reason Electron apps get a lot of flak is because they are everything _but_ a UI toolkit. They consistently miss the mark in adopting UI patterns from their host OS. Web tech is just web tech. Yes it will allow you to render a button, but even unstyled, the button won't necessarily look native to the OS, and will v…
How is it a poor choice of words? It might not be "native" UI, but they never claimed as such. I've always felt that native UI on Linux always looks incredibly ugly and I'd much rather use a nicely styled HTML+CSS layout instead. In my experience, Electron mostly gets flak for being bloated and slow, it not being native is sometimes a secondary point people add on top. I've always wanted to build a direct-browser int…
Blitz (https://github.com/DioxusLabs/blitz) is exactly that. It's a new custom browser engine supporting standard HTML/CSS with a native Rust API (and optional integration with Dioxus which is a React-like UI framework in Rust). Baseline binary sizes are around 10mb.
We share a few components with Servo (Stylo the CSS engine (also shared with Firefox), and html5ever the HTML parser), but we've built a bunch ourselves too: notably we have our own layout engine, DOM tree and event handling. Servo is unfortunately tightly coupled with SpiderMonkey, and there is little prospect of removing that dependency in the short term.
> Web technology is the most widely-known UI toolkit in the world. Poor choice of words there IMHO. The reason Electron apps get a lot of flak is because they are everything _but_ a UI toolkit. They consistently miss the mark in adopting UI patterns from their host OS. Web tech is just web tech. Yes it will allow you to render a button, but even unstyled, the button won't necessarily look native to the OS, and will v…
On Windows you have 20 different ways to write native apps that all look different.
On Linux you have Qt/GTK and god knows what else.
Only macOS is somewhat consistent although with Liquid Ass it's also getting worse.
> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just sli…
Just to let you know, CEF was used for Riot and League of Legends client as well [0]. The results haven't been nice, but I'm not aware if this was a problem with the CEF technology itself or other component/processes are to be blamed. [0]: https://www.riotgames.com/en/news/architecture-league-client...
Earlier quoted context omitted.
Try dioxus, it has live reload but it's a work in progress.
Dioxus seems to be 'just' another way to generate HTML on the desktop. Electron but Rust? Is there a legitimate upside there?
Earlier quoted context omitted.
Yeah, it is mostly laziness and cost cutting at the expense of users. Nowadays there isn't even an excuse anymore, just vibe code it away in native frameworks.
Which native framework? Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything. SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they ma…