6 ms·

> So what's your answer to Visual Studio Code then? Sublime Text, Kate, Notepad++ if you're looking for the same low learning curve or Vim/Emacs if you have ex

> So what's your answer to Visual Studio Code then? Sublime Text, Kate, Notepad++ if you're looking for the same low learning curve or Vim/Emacs if you have experience or are willing to learn either. Two days ago I finally snapped when I was refactoring a codebase that required me to have 4 VS Code windows open. Together with my regular browser I was eating 12 GB of RAM and I had no VMs open as I often do. The system ran slow as dirt despite having an FX-8320 (not a new chip, but it's no slouch and it's still an 8-core), an SSD and 4 more GB of RAM to spare. That's just downright unacceptable. > I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app? Excuse my french, but come the fuck on. I was 11 years old when I grabbed a copy of Visual Basic 6 because "I wanted to be a 1337 haxxor" and was able to drag and drop buttons and text inputs into an empty dotted window, bang them together a bit, copy paste some code from forums and have them working to some extent with no programming knowledge. You're treating JavaScript programmers as if they're mentally deficient just because many of them are new to the industry and don't know tools that aren't fashionable. If they grabbed Qt Creator and QML docs they would be producing lightweight apps in no time.

stouset 9y ago
And yet… they don't. You could continue arguing against the mounting evidence that Qt apps simply don't perform as well in the marketplace as Electron apps seem to be doing, or you could accept that perhaps one of your assumptions is wrong. Having used a few Electron apps on macOS, I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren, the software version of the uncanny valley. Even VS Code, the first editor I've actually liked since the original TextMate, somehow doesn't feel out of place (despite being themed uniquely). There was a list posted earlier of popular cross-platform Qt apps, and most of them (VLC, Google Earth, VirtualBox) share a common theme: they're effectively a thin UI around mostly non-Qt content. I'd be surprised if more than 5% of VLC's use isn't double-clicking a video, watching it, and closing the window (perhaps with some scrubbing around the content). Most of a user's interaction with VirtualBox is with the operating system inside of it. And Google Earth (isn't that dead?) has little toolkit-based UI inside of it, with most of the space reserved for flying around the planet's surface. Don't you think it's telling that the most popular cross-platform Qt apps are the ones with the least amount of Qt UI? On the other hand, popular Electron apps like VS Code and Slack are almost entirely about interacting with the UI itself. In the brief window of time Electron has been out, it's resulted in more popular cross-platform apps of this vein than Qt has in the 25+ years of its existence. "Are I out of touch? No, it's the other developers who are wrong!"
- mixedCase 9y ago
  >You could continue arguing against the mounting evidence that Qt apps... Let me stop you right there since from then on you're thinking with an incorrect assumption. I'm not talking about Qt Widgets; I'm talking about QML. And I've already hinted at why we aren't seeing an explosion of QML apps: Electron is front-end development with desktop APIs. This is something JS developers already do. On top of that, it's currently fashionable. QML isn't. It's easy to see why: QML has existed for a while, took some time to mature and it's not as good for making native looking apps as other traditional toolkits, therefore it never enjoyed widespread popularity among desktop developers outside of KDE and embedded development (an area where you need performance but don't have an an established HIG to follow). Therefore, it's normal for webdevs to not have even heard of QML or to confuse it with regular Qt widgets. > "Are I out of touch? No, it's the other developers who are wrong!" So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa. > I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren I hope you can see why I believe misinformation is the problem behind this epidemic. QML offers the exact same approach to theming, giving you simple primitives to create widgets of your own design without the need for an unholy mess of HTML, CSS and a JavaScript framework; just a tiny bit of QML in a file and you have your own component rendered on a 3D accelerated scene graph with the option to add JavaScript for complex logic. And I actually happen to have an example to back my words up. Here: https://github.com/grigio/borderless-camera https://github.com/grigio/borderless-camera is an Electron app the author posted on a programming subreddit a while ago. Take a look at the source code, build toolchain and so on; the usual. I made this as a response to the criticism he got about the high resource consumption for a seemingly trivial app: https://gitlab.com/mixedCase/qml-borderless-camera https://gitlab.com/mixedCase/qml-borderless-camera I invite you to take a look at the app.qml file. That is the entire source code.
  - stouset 9y ago
    > QML... is not as good for making native looking apps as other traditional toolkits. In disagreeing with me, somehow you've essentially re-argued my own thesis. It's not just about looking as good (although that's certainly a component), it's also about acting like native apps. Electron apps for whatever reason, in my experience, don't have this problem. Slack feels like a native app. VS Code feels like a native app. > So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa. I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders elements using Qt Quick. I'm not entirely sure how switching the mechanism for defining your Qt interface from code to a markup language invalidates my point. > And I actually happen to have an example to back my words up. It's unbelievable to me that you responded to my post about how the most popular Qt apps are the one with the least Qt interface, with an example of a Qt app you wrote (using QML) that literally has no interface. Qt apps haven't taken off because, while they may be easier for developers to build, they are worse for users to use (by a metric I'm leaving poorly-defined for the simple reason that I lack a good definition). Easier to develop but worse for users is not a good selling proposition.

stouset 9y ago

And yet… they don't. You could continue arguing against the mounting evidence that Qt apps simply don't perform as well in the marketplace as Electron apps seem to be doing, or you could accept that perhaps one of your assumptions is wrong. Having used a few Electron apps on macOS, I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren, the software version of the uncanny valley. Even VS Code, the first editor I've actually liked since the original TextMate, somehow doesn't feel out of place (despite being themed uniquely). There was a list posted earlier of popular cross-platform Qt apps, and most of them (VLC, Google Earth, VirtualBox) share a common theme: they're effectively a thin UI around mostly non-Qt content. I'd be surprised if more than 5% of VLC's use isn't double-clicking a video, watching it, and closing the window (perhaps with some scrubbing around the content). Most of a user's interaction with VirtualBox is with the operating system inside of it. And Google Earth (isn't that dead?) has little toolkit-based UI inside of it, with most of the space reserved for flying around the planet's surface. Don't you think it's telling that the most popular cross-platform Qt apps are the ones with the least amount of Qt UI? On the other hand, popular Electron apps like VS Code and Slack are almost entirely about interacting with the UI itself. In the brief window of time Electron has been out, it's resulted in more popular cross-platform apps of this vein than Qt has in the 25+ years of its existence. "Are I out of touch? No, it's the other developers who are wrong!"

mixedCase 9y ago
>You could continue arguing against the mounting evidence that Qt apps... Let me stop you right there since from then on you're thinking with an incorrect assumption. I'm not talking about Qt Widgets; I'm talking about QML. And I've already hinted at why we aren't seeing an explosion of QML apps: Electron is front-end development with desktop APIs. This is something JS developers already do. On top of that, it's currently fashionable. QML isn't. It's easy to see why: QML has existed for a while, took some time to mature and it's not as good for making native looking apps as other traditional toolkits, therefore it never enjoyed widespread popularity among desktop developers outside of KDE and embedded development (an area where you need performance but don't have an an established HIG to follow). Therefore, it's normal for webdevs to not have even heard of QML or to confuse it with regular Qt widgets. > "Are I out of touch? No, it's the other developers who are wrong!" So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa. > I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren I hope you can see why I believe misinformation is the problem behind this epidemic. QML offers the exact same approach to theming, giving you simple primitives to create widgets of your own design without the need for an unholy mess of HTML, CSS and a JavaScript framework; just a tiny bit of QML in a file and you have your own component rendered on a 3D accelerated scene graph with the option to add JavaScript for complex logic. And I actually happen to have an example to back my words up. Here: https://github.com/grigio/borderless-camera https://github.com/grigio/borderless-camera is an Electron app the author posted on a programming subreddit a while ago. Take a look at the source code, build toolchain and so on; the usual. I made this as a response to the criticism he got about the high resource consumption for a seemingly trivial app: https://gitlab.com/mixedCase/qml-borderless-camera https://gitlab.com/mixedCase/qml-borderless-camera I invite you to take a look at the app.qml file. That is the entire source code.
- stouset 9y ago
  > QML... is not as good for making native looking apps as other traditional toolkits. In disagreeing with me, somehow you've essentially re-argued my own thesis. It's not just about looking as good (although that's certainly a component), it's also about acting like native apps. Electron apps for whatever reason, in my experience, don't have this problem. Slack feels like a native app. VS Code feels like a native app. > So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa. I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders elements using Qt Quick. I'm not entirely sure how switching the mechanism for defining your Qt interface from code to a markup language invalidates my point. > And I actually happen to have an example to back my words up. It's unbelievable to me that you responded to my post about how the most popular Qt apps are the one with the least Qt interface, with an example of a Qt app you wrote (using QML) that literally has no interface. Qt apps haven't taken off because, while they may be easier for developers to build, they are worse for users to use (by a metric I'm leaving poorly-defined for the simple reason that I lack a good definition). Easier to develop but worse for users is not a good selling proposition.