3 ms·

It's native as in supported directly by the company making the software. It's not some random 3rd party that's trying to implement a buggy client or wrapper.

It's native as in supported directly by the company making the software. It's not some random 3rd party that's trying to implement a buggy client or wrapper. At risk of being shut down at any moment, and probably violating the company's terms of use. (which is a whole different conversation around the sad reality of interoperable software today) --- It's native in the sense that I, as a developer employed by a company using it, can easily drop in a linux release without having to have a long drawn out cost/benefits analysis trying to convince PMs that we should do it, because it's not months or years of additional work - it's some manifest file tweaks to get icons in, and possibly some additional signing scripts to be run during the final packaging. --- It's not native in the sense that it directly uses OS specific APIs, but who gives a flying fuck? Seriously. I spend 95% of my time in a browser or a text editor already - "Browser with better system access" is just fine to me. It turns out RAM and disk space are really, REALLY, REALLY fucking cheap. as in - I can get 32gbs of ram for less than the cost of a windows license. So I'll take my linux support, thank you very much. (shocker - I also like mobile web apps, and strongly favor mobile moving that direction as well - For exactly the same reasons).

criddell 5y ago
> It's native as in supported directly by the company making the software. Except for the times when that isn't true. Elsewhere in this thread people are complaining about how the Logitech software is Electron based but doesn't work on Linux. > It turns out RAM and disk space are really, REALLY, REALLY fucking cheap. RAM and disk may be cheap and plentiful, but battery power and bandwidth are not. It's why web apps don't make much sense for mobile today.
- horsawlarway 5y ago
  Web apps are the default access mechanism for basically everything I do on my phone. And by that, I mean - I open chrome/firefox and navigate to the site I'd like to use. I have less than 5 installed apps that I use on my phone directly, and those are almost all exclusively apps that need direct hardware access - Camera - Phone - Maps I also happen to use a few apps to work around sites that are genuinely awful to their mobile users (reddit, for example, is a black whole of dark ux patterns if you open it in a browser without faking your user agent - So I run bacon reader which [ironically] is just another webview running on the device anyways)
  - bayindirh 5y ago
    Just because web apps are fitting to your current workflows and apps you use, it won't fit everybody else. I'm just the opposite of you. Just using web to reach HN, and Google, nothing else. Everything I use is native, and I'm happy with all the native apps I have. Hardware is cheap, network is reliable notion is just an illusion. No resource is cheap and nothing is reliable. I'm in a remote location with 4G network access and, while it's not slow, it's unreliable and choppy as hell (with full bar / excellent reception). Even well-baked and battle tested algorithms and applications (e.g. Zoom, Skype and other similar covid-19 critical, realtime software) choke, shudder and fail with smallest network congestion. Also, while RAM is relatively cheap, processing power is not. Just because you have fast flash and plentiful RAM on the device, it doesn't mean all is yours. You can't just assume to use all of that. If that software is running on a resource contained system, It'd be probably confined in a cgroup, and it'd be killed or crashed with OOM exceptions constantly because of this assumption. At the end of the day, Electron is useful for some stuff, however it's not native in any means. If it was literally native, Evernote for Linux would've been released by now. Tiddly Desktop wouldn't have some silly fullscreen bugs. Spotify Linux wouldn't be a volunteer project inside Spotify. A simple application wouldn't consume as much memory as a full blown IDE with gazillion plugins enabled and written in Java. Visual Studio Code wouldn't need plugin subsets or "Hey, group the plugins you use by language, otherwise memory usage becomes unwieldy" warning. I can go on and on and on. We have alternatives. We have Qt, GTK, Python compiled with Cython (if you need binary code), heck even Lazarus and WX widgets, and Java. It's unbelievable that JVM is lighter than Electron with all bells, whistles and Hotspot and whatnot. Some of these technologies can adapt themselves to the hardware resource limits of the system they're running on, transparently, with negligible performance impact most of the time. So, you can tell that Electron is a better RAD tool than Java, but it's nowhere the only feasible tool to enable native cross-platform applications. Electron is lazy. It's the perfect manifestation of MVP meets mock-ups with enough features baked in to allow rapid-fire releases. I agree that 640K is not enough for everybody, but no resource is as abundant as hydrogen in the universe.

criddell 5y ago

> It's native as in supported directly by the company making the software. Except for the times when that isn't true. Elsewhere in this thread people are complaining about how the Logitech software is Electron based but doesn't work on Linux. > It turns out RAM and disk space are really, REALLY, REALLY fucking cheap. RAM and disk may be cheap and plentiful, but battery power and bandwidth are not. It's why web apps don't make much sense for mobile today.

horsawlarway 5y ago
Web apps are the default access mechanism for basically everything I do on my phone. And by that, I mean - I open chrome/firefox and navigate to the site I'd like to use. I have less than 5 installed apps that I use on my phone directly, and those are almost all exclusively apps that need direct hardware access - Camera - Phone - Maps I also happen to use a few apps to work around sites that are genuinely awful to their mobile users (reddit, for example, is a black whole of dark ux patterns if you open it in a browser without faking your user agent - So I run bacon reader which [ironically] is just another webview running on the device anyways)
- bayindirh 5y ago
  Just because web apps are fitting to your current workflows and apps you use, it won't fit everybody else. I'm just the opposite of you. Just using web to reach HN, and Google, nothing else. Everything I use is native, and I'm happy with all the native apps I have. Hardware is cheap, network is reliable notion is just an illusion. No resource is cheap and nothing is reliable. I'm in a remote location with 4G network access and, while it's not slow, it's unreliable and choppy as hell (with full bar / excellent reception). Even well-baked and battle tested algorithms and applications (e.g. Zoom, Skype and other similar covid-19 critical, realtime software) choke, shudder and fail with smallest network congestion. Also, while RAM is relatively cheap, processing power is not. Just because you have fast flash and plentiful RAM on the device, it doesn't mean all is yours. You can't just assume to use all of that. If that software is running on a resource contained system, It'd be probably confined in a cgroup, and it'd be killed or crashed with OOM exceptions constantly because of this assumption. At the end of the day, Electron is useful for some stuff, however it's not native in any means. If it was literally native, Evernote for Linux would've been released by now. Tiddly Desktop wouldn't have some silly fullscreen bugs. Spotify Linux wouldn't be a volunteer project inside Spotify. A simple application wouldn't consume as much memory as a full blown IDE with gazillion plugins enabled and written in Java. Visual Studio Code wouldn't need plugin subsets or "Hey, group the plugins you use by language, otherwise memory usage becomes unwieldy" warning. I can go on and on and on. We have alternatives. We have Qt, GTK, Python compiled with Cython (if you need binary code), heck even Lazarus and WX widgets, and Java. It's unbelievable that JVM is lighter than Electron with all bells, whistles and Hotspot and whatnot. Some of these technologies can adapt themselves to the hardware resource limits of the system they're running on, transparently, with negligible performance impact most of the time. So, you can tell that Electron is a better RAD tool than Java, but it's nowhere the only feasible tool to enable native cross-platform applications. Electron is lazy. It's the perfect manifestation of MVP meets mock-ups with enough features baked in to allow rapid-fire releases. I agree that 640K is not enough for everybody, but no resource is as abundant as hydrogen in the universe.