Technical Vision for Qt 6
These changes are very welcome, but in my opinion are too little too late. Qt has missed the boat with the current developer mindset. While I want Qt to &#x27;win&#x27;, as the end result is superior to say an electron app, most developers are willing to sacrifice usability and add bloat by using electron. Or simply paint them selves into a corner with a native SDK.<p>Qt has a massive uphill battle to try and stay relevant. Like it or not, there&#x27;s a reason why electron apps and native ui sdks become the zeitgeist. While reusability is often cited as the main reason why electron has become the cross platform defacto, there&#x27;s a lot more to it than that.<p>Personally, the difference between using electron and Qt is black and white. Looking at setting up alone, With Qt you have to struggle to compile a massive library which inevitably won&#x27;t work. After sinking hours into compiling it, you&#x27;re confronted with a unknown markup language and toolchain just to get a window displaying. And the documentation is incomplete, and to top it all off the minor versioning differences will cause your app to break in spectacular ways. Compare this to electron, where everything just works out the box, and with npm you have every single library you could ever think of. Microsoft and Apple roll out the red carpet for developers to make ui development super easy, so making two apps with a shared library is often just as tempting.<p>The way I&#x27;d try and save qt would be to make a react-native binding a first class citizen and ditch QML&#x2F;js engines. I&#x27;d also remove the custom tool chains and release extensions for VSCode&#x2F;Atom that outputted jsx that could get interoperated by a virtual dom. developers would kill for that.