2 ms·
Every time this argument comes up, I see the same tired comments, and they're typically from people that don't have to build a modern UI. There is an insane amo
by Klonoar 9y ago
Every time this argument comes up, I see the same tired comments, and they're typically from people that don't have to build a modern UI. There is an insane amount that you get for free in HTML/CSS/JS, and it's very clear why things like Qt & co don't stack up.
Here's a small list (which could easily be a much bigger list) of things that are much easier in web dev land than their native counterparts.
- Want to chart some data with nice animations? The chart library in Qt is good... until you need to make it look sexy. If you're in HTML/CSS/JS, you can just reach for an unlimited number of alternative libraries to pull from. (No, saying "go without the animations" isn't an answer.)
- Universal stylesheets are a godsend for quickly iterating on UI. Qt's stylesheets do not come close to the abilities that modern CSS provides you (and frameworks beyond Qt often lack something even close to this). Saying "CSS shouldn't be doing this stuff" isn't an answer, because the alternatives are simply less productive. It's absolutely amazing to be able to target an arbitrary node in a nested structure and tell it to behave differently, and have the entire thing render appropriately.
- You want smooth scrolling (that matches the OS behavior...) at 60fps? There is an untold amount of work that each browser vendor has put in to this effort, and the benefit is greatly undersold. Ever looked into wxWidgets? You have to go out of your way to make a scroll view bounce on macOS. That is utterly insane in 2018 - and no, saying "why does Mac need to be different?" isn't a solution. The entire point of cross platform development is that it should handle this.
- Have you ever tried to optimize scrolling on a TableView in Qt/wxWidgets/Cocoa/etc? Give me HTML/CSS/JS any day of the week.
- This point is slightly separate, but... I've written Python for over 10 years now, and I would not want to write a UI in Python. The language is one of my favorite and works well for most things, but UIs are often just kind of hacky - Python isn't a language that's ideal to write hacky code in. I'd sooner do it in Ruby or something.
Want the tl;dr? There is no other frontend community that even comes close* to the wide range of documentation, available libraries, built-in/free benefits, approachability, and general "it'll just work" feeling across platforms.
I write native UI code daily, and the writing is on the walls for it. Tangentially, this is very much why I suspect Apple is looking to merge Cocoa and UIKit more - it's the only way native Mac apps survive (oh, and even Apple renders significant chunks of some of their apps with Webkit... three finger swipe right on your trackpad if you wanna see some ancient Webkit app history).
* - _maybe_ UIKit for iOS comes close, due to Apple's vendor lock in factor and focus on UI, but that's something that a) rarely extends back to macOS apps and b) usually winds up splintered between Objective-C/Swift implementations.
- nabla9 9y agoHere is an example of modern UI build with Qt: https://www.youtube.com/watch?v=f7en65HkjeQ&t=39 https://www.youtube.com/watch?v=f7en65HkjeQ&t=39
- Klonoar 9y agoThat's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm. I would honestly pay money to see how much effort it took to get it to this. There's also the point I forgot to mention in my original post, which is that... if your entire app starts as a webapp, there's no sense in maintaining an entire separate Qt codebase when you could just wrap it. Standalone products like this (embedded, etc) might have an easier time justifying it, but I really don't think it hits the ease of use metric (not even touching on the fact that you then need to handle product changes across multiple codebases/teams - money doesn't absolve your, your team or your company of the inherent difficulty here). Also, hell, the simple act of refactoring native level UI code is often more of a PITA than the HTML/CSS/JS counterpart. Native APIs need to make themselves more accessible and sexy if they want to have a chance here. Alsoooo to just end this rant of mine, I'll point out that the OP's project shouldn't charge money for this. It's not that they're not allowed to or anything like that, but you're in no way making PyQT a viable Electron alternative if you require licensing. There's little money in building UI frameworks for this reason; the web kind of requires you to compete on free to use. There are people (regardless of your take on the matter) that don't use Qt for licensing reasons and that is a hard blocker.
- jcelerier 9y ago> That's a killer UI, and I'm happy to admit it's incredibly good for what I've seen/used of Qt apps over the years... but it's not the norm. It's the norm for Qt apps since 2011 - 2012 when qml was introduced (of course, older apps use the older tech - and honestly, sometimes it makes more sense : at least all the colors, fonts, etc... will respect your desktop theme unlike "modern" toolkits). Here's how some QML code looks: https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qml https://github.com/jcelerier/TodoMVC-QML/blob/master/Main.qm... ; as you can see, it's far from bloated (mostly due to the language being based on reactive semantics). For instance a consequent part of KDE has been rewritten in QML and more is underway with Kirigami : https://dot.kde.org/2017/01/12/kde-releases-kirigami-ui-20 https://dot.kde.org/2017/01/12/kde-releases-kirigami-ui-20