391–400 of 777 posts
Earlier quoted context omitted.
Mainly due to them being both more tightly integrated to C++/Python than JS/TS for building desktop apps.
Yeah, but, honest question, why would you want to use JS if you didn't have to? It's like, the worst language possible.
If you develop an application that runs in the web browser, I won't use it. That's not some dogmatic principle of mine, it's just an empirical fact. I use only one browser-based application: Gmail. I've never used another browser-based application and I can't imagine that I ever will unless there's truly no alternative and it's forced on me by an employer. I've happily paid for dozens of desktop applications, and I'm…
I use gmail but i get it through Thunderbird...
Pretty much all the jobs I've had as a software engineer have been working on desktop apps. There's tonnes of random enterprise applications that look like they're straight out of 2005 out there still.
But those things are getting fewer and fewer. And it annoys me to no end that I can't, say, run my favorite screencast/video editor (screenflow) on my Windows or Chromebook machine, since it seems pretty deeply tied to the OS. I don't want to have to learn another one, and I don't want to replace my Mac which is on borrowed time.
That said, I use a lot of apps like Gimp and Inkscape on my Mac, and they may be technically native, they can be really awful about "feeling native." I don't mind inconsistent user interfaces so much, as long as it is mostly cosmetic. But I've spent SO much time in both of those searching for lost windows, etc. (OMG Inkscape devs, has anyone even tried it on multiple monitors???) Things you never run into with "true" native apps (those two use GTK toolkit).
So, I certainly recommend web apps if you app can run sufficiently fast or otherwise can get away with being a web app.
Every single app that I use, I try and make sure it is native. I shun electron apps at all cost. It's because people who put in effort to use the native APIs put in a lot more effort in the app in general based on my anecdotal evidence. It is also more performant and smaller in size, things that I cherish. It also pays homage to limits and striving to come up with new ways of overcoming them, which hackers would have…
I admire your words here. I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks. I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.
The efficiency difference between native and "modern" web stuff is easily several orders of magnitude; you can write very useful applications that are only a few KB in size, a single binary, and that same binary will work across 25 years of OS versions.
Yes, computers have gotten faster and memory and disks much larger. That doesn't mean we should be wasting it to do the same or even less functionality we had with the machines of 10 or 20 years ago.
For example, IM, video/audio calls, and working with email shouldn't take hundreds of MB of RAM, a GHz-level many-core processor, and GBs of disk space. All of that was comfortably possible --- simultaneously --- with 256MB of RAM and a single-core 400MHz Pentium II. Even the web stuff at the time was nowhere near as disgusting as it is today --- AJAX was around, websites did use JS, but simple things like webchats still didn't require as much bloat. I lived through that era, so I knew it was possible, but the younger generation hasn't, so perhaps it skews their idea of efficiency.
In terms of improvement, some things are understandable and rational, such as newer video codecs requiring more processing power because they are intrinsically more complex and that complexity is essential to their increase in quality. But other things, like sending a text message or email, most certainly do not. In many ways, software has regressed significantly.
Earlier quoted context omitted.
I admire your words here. I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks. I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.
I agree too, and your average user is not going to care about the fact you've used Electron, or even know. It's a big win for development.
But most people are probably not saying "ugh, Slack is made with Electron, I should completely avoid it."
Earlier quoted context omitted.
This is not really accurate. Qt relies on a lower level windowing system (X Window, Wayland, Cocoa, win32 etc. etc.). Also worth noting that many creation-centric applications for the desktop (graphics, audio, video etc. etc.) don't look "native" even when they actually are. In one case (Logic Pro, from Apple), the "platform leading app from the platform creator" doesn't even look native!
> Qt relies on a lower level windowing system That's true of QtWidgets, but not QML / Qt Quick (the newer tool), correct? (I found this hard to determine online).
But :
- QML can be used with other graphics stack - for instance Qt Widgets like with https://www.kdab.com/declarative-widgets/ or alternatives to the official Qt Quick controls with https://github.com/uwerat/qskinny or with completely custom rendering like here with NanoVG : https://github.com/QUItCoding/qnanopainter
- QtQuick Controls can be made to use the same style hints than the desktop with https://github.com/KDE/qqc2-desktop-style
As a long-time Win32 developer, my only answer to that question is "of course there is!" The efficiency difference between native and "modern" web stuff is easily several orders of magnitude; you can write very useful applications that are only a few KB in size, a single binary, and that same binary will work across 25 years of OS versions. Yes, computers have gotten faster and memory and disks much larger. That does…
Work expands so as to fill the time available for its completion.[1]
Corollary: software expands to fill the available resources.