391–400 of 438 posts
Earlier quoted context omitted.
If you cared about performance, would you really be using Electron?
Yes. Why not? HTML/CSS great (from the development POV) for UI, and I can always write the performance critical code in C and linked them to the electron HTML/CSS frontend.
Earlier quoted context omitted.
> Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps. I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business…
Electron exists because there's a horde of developers whose only tool is a JavaScript hammer, so every problem looks like a nail. That's how you end up rewriting `dd` for Chrome[π]. π: https://www.balena.io/etcher/
It might be because it is slower and doesn't overheat my usb sticks, I don't know, but if nothing else works you can try etcher.
(Not sure how I found out, can have been something I read or a recommendation by a colleague 3 a 7 years ago or something.)
Earlier quoted context omitted.
> it's inefficient computation to energy ratio Probably true. > affects the global climate in a negative way If electricity consumption of all computers in the world doubled because of Electron apps, the total annual electricity consumption would increase by 0.01%. So probably false.
In 2012 PCs (only PCs, not network appliances, not data centers, not phones...) were estimated at 1.5% of global electricity use, so you're off by a good margin. And that is deeefinitely not negligible, nor is the need (and eco impact) to buy newer computers because a 2016 MacBook Pro is unusable when your work requires 4/5 electron apps side by side.
Earlier quoted context omitted.
A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…
An alternative to Electron should be built using Servo and Deno, both written in Rust.
Earlier quoted context omitted.
An alternative to Electron should be built using Servo and Deno, both written in Rust.
I agree, however last time I checked Servo was not that stable.
https://visualstudiomagazine.com/articles/2021/02/17/net-6-p...
C# will then be compiled to WebAssembly.
Earlier quoted context omitted.
I'll take Win95 in a heartbeat; consistent, accessible, responsive and clear. Vastly superior to the majority of web interfaces.
Also totally inflexible, you better have the right-sized screen/resolution: too small and you can't see that "ok" button; too large and you'll have a ridiculously small and crammed winform to fill/see your information.
Actually even WinForms supports them, even though too many are happily doing fixed canvas positioning without using them.
Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…
A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…
Give up pixel-accuracy and fine-grained control of your app's UI layer, and just treat it how people like Peter Norvig and Chris Lattner treat their home pages.
There isn't any browser with even 0.1% share that can't render those things.
You also don't really have to go as far as those guys do, leaving the font 14-point Times New Roman and using HTML 1 tables. You can add some style, fonts, etc... just don't add anything that would make it _not work_ if somebody opened it in Netscape Navigator 4.
There is definitely a big downside, in that your app won't look all dope and modern. For many apps that is a deal breaker. Also, some UIs really do require a higher fidelity UI. Not all UIs are just like, buttons and menus (although a lot are).
But there is also a big upside: durability, in the sense that your app's UI will work on most 10-year old computers, and most computers 10 years from now.
Earlier quoted context omitted.
I'm really hoping Flutter or Kotlin Desktop have a breakthrough here soon. Personally, I'm rooting for Flutter, but I'll take what I can get.
It would be fun that Dart finally takes over Javascript this way (Flutter is written in Dart, which was originally written to be the new Javascript)
Earlier quoted context omitted.
I think most companies that already decided on the electron UX vs dev effort tradeoff will happily trade user resources for a guaranteed, uniform browser version target. It makes a big difference in development and testing.
Yea, but as a user, it's disappointing, and kind of impossible for me to push back on this trend. I can avoid using these apps, but it's an impotent show of protest. It won't make a difference. User experience, native look and feel, and the user's RAM are all being sacrificed on the altar of More Comfortable Developer Experience.