| |
| ▲ | ogoffart 7 months ago | parent | next [-] | | It's also possible to use JS (or TypeScript) on the desktop, without having the need for a browser or a webview.
That's for example what we're trying to do with Slint https://slint.dev
Then you get the good part of javacript for your application logic, without the bloat and attack surface of a browser. | |
| ▲ | pdimitar 7 months ago | parent | prev [-] | | If you say so. Take a look at Slack and Teams and tell me that's what a performant and lagless UI feels like. ...Oh? What's that? I am hearing something faint in the distance, like... "their devs are not using JS well", maybe? Tell you what. If a technology can be held wrong, then it's a bad technology. Which, yes, encompasses most technology nowadays. You heard me. | | |
| ▲ | DecoySalamander 7 months ago | parent | next [-] | | I use Discord daily and can't really call it slow and laggy, it feels adequate if anything. Can't really comment on Slack and Teams - I've obviously used both, but haven't been a heavy user of Teams and never was in a large "corporation-wide" Slack instance. I have, however, been a heavy user and developer of a Slack competitor. Not surprisingly, it had a lot of problems, but most of them stemmed from a) clumsy handling of megabytes of chat logs, b) a codebase that grew organically out of a startup project and needed a major rewrite, c) misallocation of resources (for the longest time, everything Electron-related was handled by a single developer in a satellite office). In my opinion, we would have had the same performance issues and bugs if it had been developed in any other language. We actually had some Qt apps that we deprecated and rewrote in JS as part of the main client - there was no user-noticeable performance drop, but significantly fewer crashes. | | |
| ▲ | pdimitar 7 months ago | parent [-] | | ...OK? It was already mentioned that people can do better apps with Electron than others. Not surprising. My objection is that the possibility to make laggy and bad apps exists. It should not exist. As for what problems a Slack competitor faces, well, I am not interested. That's the dev team's problem and not mine. I want a lagless Slack. | | |
| ▲ | DecoySalamander 7 months ago | parent [-] | | > the possibility to make laggy and bad apps exists. It should not exist I see. Then the only way forward is to stop all software development altogether and enjoy memories of apps that we used 20 years ago when we were much younger, and fantasies of apps that we could build with newly acquired wisdom, but will not. | | |
| ▲ | pdimitar 7 months ago | parent [-] | | Funny, still not what I said. Progress is way too slow and blindly follows local maximii. That's not OK. That's the part I am expressing displeasure with. |
|
|
| |
| ▲ | foldr 7 months ago | parent | prev [-] | | But can you point to an app that has the same UX functionality as Slack that's been successfully implemented using Qt or another native toolkit? | | |
| ▲ | rubymamis 7 months ago | parent | next [-] | | I'm building a chat app - well, a client for LLMs using Qt (QML + C++). It's highly performant with beautiful animations: https://rubymamistvalove.com/client.mp4 I also created a native block editor (like Notion's) in QML and C++: https://get-notes.com I really hope that I can show that Qt with QML is a viable alternative to the inefficient resource hogs that are Electron/web apps. | |
| ▲ | pdimitar 7 months ago | parent | prev [-] | | Wish I could but many people gave up and started using Electron due to employability. And we're stuck with crappy laggy UIs. I remember the MirandaIM multi-messenger from 20+ years ago very fondly... 50MB RAM usage and I was signed to 4 services, on a computer that my smartphone today can emulate 16 of, simultaneously, and it was still running faster than you can blink. Ehhhh, good times. Electron/JS is a herd just running in one direction, personified. The fact that something is popular does not imply quality, not at all. Most of the time it implies that everybody settled on it and does not want to hear otherwise for various reasons (in this case: money, as employers are never going to give you the requisite time to build stuff with Qt or others). | | |
| ▲ | foldr 7 months ago | parent [-] | | It could be that Qt would work better and no-one is using it for the sorts of reasons that you mention. But I think the more plausible explanation is that no UI library can compete with what the browser offers anymore. This would hardly be surprising. The person hours invested in HTML+CSS rendering vastly exceed those invested in Qt or any other UI lib. The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising. I don't personally find Electron apps laggy in general. VSCode is very responsive, for example. | | |
| ▲ | rubymamis 7 months ago | parent | next [-] | | Probably because you're using a very performant machine (M1-M4 are extremely capable), but other than responsiveness (which even on an M1 isn't perfect), you got 3 more issues with Electron apps: 1. High RAM usage. 2. The bloat will accelerate as more abstractions are added to web frameworks. 3. Battery usage - the most noticeable issue for me. I've yet to empirically test this, but my guess would be that Electron apps use substantially more power than native apps. I will test this theory eventually. | |
| ▲ | pdimitar 7 months ago | parent | prev [-] | | Yeah VSCode is fine, I agree. But as mentioned above, if one can screw up their Electron app to be as laggy as Slack then the tech is not good. I stand by that statement. > The kind of argument you're making would be much more convincing if there were relevant examples of Qt-based apps that provided a superior user experience to the Electron apps you're criticising. That's arguing in circles and it's the chicken-and-egg problem. Toolkits like Qt get less and less mindshare because Electron is desired and is encouraged by employers. I can't speak for Qt in particular btw, just using it as an example here, but my point is that it could be the best UI toolkit ever but since it takes a little more time to spin up an app with it then the business will want you to not use it. Hence, I can't show you those Qt apps. I feel that in these discussions people just blindly trust popularity to be an indicator of quality. I have a huge problem with that mindset and my career has seen the exact opposite, many times. Hence my comments. And if you want to take away just one thing from our discussion, it's this: please don't mistake Electron's popularity with the idea that Electron is the best UI toolkit. | | |
| ▲ | foldr 7 months ago | parent | next [-] | | It's not arguing in circles. It's just asking you for evidence that an app like Slack would be better if it were implemented in Qt or a similar library. If there is literally no example of this having been done successfully, how can you be so confident that it would work great? >Toolkits like Qt get less and less mindshare because Electron is desired and is encouraged by employers. But why is it desired? I've used Qt before (a long time ago) and know enough C++ to be dangerous. I'd still avoid using Qt simply because I already know how to make UI's in HTML+CSS. I can't say that replacing those tools with a manually-constructed C++ object graph – or with an unfamiliar markup language (QML) – strikes me as an appealing option. Most of the people carping about Electron apps on HN don't want to make a UI in Qt either! It is becoming one of these legendary magical technologies (like Lisp) that is much praised and yet too little used for its flaws to be common knowledge. | | |
| ▲ | pdimitar 7 months ago | parent [-] | | > If there is literally no example of this having been done successfully, how can you be so confident that it would work great? Past experiences. I've seen much smoother and faster apps more than 20 years ago. Surely they weren't using black magic. > But why is it desired? Because it is slightly quicker to start an app with it and because people want to have a web variant of it (runnable in the browser) if/when necessary. Those are actual selling points and I agree with them wholeheartedly -- I object to Electron's lagginess however. They can and they should do better. > I'd still avoid using Qt simply because I already know how to make UI's in HTML+CSS. Well yes, that's one of the factors -- people default to what they already know. But zero mention is given to the numerous problems with the DOM model of making UIs as well... a topic way too big for me to have any desire to delve in, again. Inertia. A bad thing starts being used widely because of 2-3 desirable traits, and when it gains enough critical mass nobody wants to criticize it. Well, I do. | | |
| ▲ | foldr 7 months ago | parent [-] | | >I've seen much smoother and faster apps more than 20 years ago Me too, but they didn't have all the whizzbang UI features that you get for free from a web stack. I could live without most of those, but users do expect all that stuff to work these days. | | |
| ▲ | pdimitar 7 months ago | parent | next [-] | | I am one of those users. I do my job as a programmer to the best of my ability and I am not allowing lags for as much as humanly possible (sometimes you can't do anything about a slow 3rd party API though). They should do the same. I have no sympathy for sloppy work, and Slack and Teams are in the top two spots there. | | |
| ▲ | foldr 7 months ago | parent [-] | | Sloppy work and bad code are orthogonal issues to choice of technology. There are some sloppily written Qt apps out there too. If the Slack devs are as sloppy as you say, then we ought to be thankful that they’re writing JS and not C++! Lag is something that some people care about a lot. I actually think that most users don’t notice it or care very much, up to a certain point. | | |
| ▲ | pdimitar 7 months ago | parent [-] | | > There are some sloppily written Qt apps out there too. I specifically asked not to focus on examples but OK, I guess you really had to get it off your chest. ¯\_(ツ)_/¯ The topic was not "Electron vs. Qt" at all. > I actually think that most users don’t notice it or care very much, up to a certain point. Good for them, to me it's a mood and productivity killer. And no I'll not change my mind on this, ever. Broader point is: the people who worked on Electron, Slack etc. should have really done better. But I have witnessed how job security almost always leads to sloppy work. | | |
| ▲ | rubymamis 7 months ago | parent [-] | | Actually, the people who created Electron (and the code editor Atom), themselves abandoned it to create a performant code editor called Zed - with its own GUI toolkit based on Rust. | | |
| ▲ | pdimitar 7 months ago | parent [-] | | Case in point / point proven then. :D I didn't know they were the same. Fascinating actually, thanks for making me aware of it! |
|
|
|
| |
| ▲ | rubymamis 7 months ago | parent | prev [-] | | What kind of UI feature are you speaking of? I would love to see how easy it'd be to do in QML. |
|
|
| |
| ▲ | rubymamis 7 months ago | parent | prev [-] | | One obvious reason why Qt is less popular is the ability for companies to deploy web apps (non Electron, but in the browser). Many end users expect a desktop/mobile app to also be accessible using the browser. I'd argue that QML is an order of magnitude easier to develop than any other web frameworks (yes, you do have to get familiar with it, and if you made some apps before you could re-use some essential, battle-tested components). I hope to maybe share/sell some of mine some day. I'm not sure what to answer regarding the browser experience. WASM isn't really there, isn't it? I haven't had a chance to test it on my own apps yet tho. I recently had a thought that maybe that Qt Company should also target HTML/CSS/JS generation of a QML file. Another, more interesting thought would be for browsers to be able to process and render QML files natively (but that won't happen without substential market share). | | |
| ▲ | pdimitar 7 months ago | parent [-] | | > but that won't happen without substential market share So again: the chicken-and-egg problem. Basically, nothing is going to improve until somebody rolls up their sleeves and does all the hard work for free and do better than Electron -- or a corporation will push for it, it's always one of both. Then everybody else will flock to them. That's what I observed several times during my life and career. | | |
|
|
|
|
|
|
|
| |
| ▲ | pdimitar 7 months ago | parent [-] | | Needlessly provocative. Sounds more like you felt attacked. No reason for me to feel attacked, I pointed out that what you said doesn't make much sense in terms of how long have these languages been around. | | |
| ▲ | pjmlp 7 months ago | parent [-] | | On the contrary, apparently we are in a need of English lesson over here. "Instead of rewriting JavaScript tools in Zig, Rust, Go, whatever cool compiled language of the month, use the said language directly." Meaning use Zig instead of JavaScript, use Rust instead of JavaScript, use Go instead of JavaScript, use "whatever cool compiled language of the month" instead of JavaScript, or if you prefer for the last example, use "whatever compiled language takes your fancy" instead of JavaScript. Clear enough? | | |
| ▲ | pdimitar 7 months ago | parent [-] | | Would be clear if it did not seem to me that you are including three languages that have been around for a while in the "whatever cool compiled language of the month" group. If not -- then clear. If yes, then this is getting even more confusing. | | |
| ▲ | pjmlp 7 months ago | parent [-] | | It is called an enumerations of choices, 3 named ones, followed by a generalisation of whatever else might possible as option. Given that boring languages like Java, C#, OCaml, Haskell are kind behind their times for cool kids to rewrite stuff, that leaves the unamed cool programming language of the month as option, whatever that language may be. | | |
| ▲ | KPGv2 7 months ago | parent | next [-] | | Hello, friend! Professional writer here. An enumeration of three choices followed by a generalization reads like the three choices are examples of the generalization, not disjoint. | |
| ▲ | pdimitar 7 months ago | parent | prev [-] | | Honestly, you are not making this better. This comment also implicitly puts Rust and Zig in the "unnamed cool programming language of the month" group again unless I completely lost the ability to read English. And seeing that a writer commented something similar to my comments upthread, I am not very inclined to assume I can't read English. Still, your point is taken, I just can't help but think I am sensing some slight... shall we call it non-preference... towards a few programming languages. |
|
|
|
|
|
