51–60 of 196 posts
Earlier quoted context omitted.
Once we compile Chromium to webassembly, we can run Qt in Chromium in Chromium in Slack!
See also https://www.destroyallsoftware.com/talks/the-birth-and-death... You jest, but this sort of thing probably is the death of almost all native software, sadly.
Really surprised and saddened by the negative comments here. Qt is an amazing framework that has been around for nearly 30 years. Developing with it is a great experience, probably the most enjoyable coding I've done. I have faith that the Qt project won't spend time shipping this if it doesn't offer advantages. Give them time, and a little benefit of the doubt based on a very long history of excellence.
I would argue that Qt's problem is:
* Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe)
* Getting started with Qt is painful and integrating it into an existing codebase even moreso - get ready to suffer with C++ linker nonsense
* You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)
* The "deploy" bit is completely left to the reader, Qt doesn't help you write apps and ship them end-to-end. Contrast this with Electron which has a pretty strong (albeit a bit mysterious) packaging and auto-update pipeline
Qt experts will argue on all these points, "It's a library, it shouldn't do XYZ", but at the end of the day, Qt is a means to ship Desktop and Mobile Software, and by ignoring the entire Developer Experience from end-to-end, they miss the mark.
Earlier quoted context omitted.
The existing CSS/DOM layer is for rendering documents. It can be used to emulate a native GUI, just like languages can "compile" to javascript, and everyone can pretend it's really bytecode. But that doesn't mean this is a good idea, or that an actual bytecode for the web is just reinventing the wheel. >Webassembly excels when it is minimized around core performance problems. Not when it is the whole app. We don't re…
I think that is a fantasy of qt and c++ developers unfortunately. There will be very few use cases for qt in a browser loaded from the web. Optimized computation kernels yes. Full qt guis I do not see it happening. Qt should create an html/Dom/css front end that binds to the webassembly backend. Would be more efficient and web friendly.
Earlier quoted context omitted.
I think that is a fantasy of qt and c++ developers unfortunately. There will be very few use cases for qt in a browser loaded from the web. Optimized computation kernels yes. Full qt guis I do not see it happening. Qt should create an html/Dom/css front end that binds to the webassembly backend. Would be more efficient and web friendly.
Make Electron-like desktop apps but with Qt or within a browser with navigation/menu etc. bars? Running both over Internet and locally at native speed? Avoiding JavaScript for Web UI? I'd be happy to have that!
Really surprised and saddened by the negative comments here. Qt is an amazing framework that has been around for nearly 30 years. Developing with it is a great experience, probably the most enjoyable coding I've done. I have faith that the Qt project won't spend time shipping this if it doesn't offer advantages. Give them time, and a little benefit of the doubt based on a very long history of excellence.
I'm not sure I buy that, are you saying that the only reason that Qt hasn't completely taken over writing native software on (even desktop! not to mention mobile where Qt also works), is a marketing problem? I would argue that Qt's problem is: * Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe) * Getting started with Qt is pai…
I should look this up because Qt is something I've got my eyes on for small projects that could get big. On that note, are you able to define "large-scale" for me? Would a desktop app' interfacing with a remote API be "large-scale"?
> You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)
I'm looking at the Golang bindings for Qt (to implement my point above.) Have you considered it? Is Go something you'd consider?
Earlier quoted context omitted.
The existing CSS/DOM layer is for rendering documents. It can be used to emulate a native GUI, just like languages can "compile" to javascript, and everyone can pretend it's really bytecode. But that doesn't mean this is a good idea, or that an actual bytecode for the web is just reinventing the wheel. >Webassembly excels when it is minimized around core performance problems. Not when it is the whole app. We don't re…
I think that is a fantasy of qt and c++ developers unfortunately. There will be very few use cases for qt in a browser loaded from the web. Optimized computation kernels yes. Full qt guis I do not see it happening. Qt should create an html/Dom/css front end that binds to the webassembly backend. Would be more efficient and web friendly.
Earlier quoted context omitted.
I'm not sure I buy that, are you saying that the only reason that Qt hasn't completely taken over writing native software on (even desktop! not to mention mobile where Qt also works), is a marketing problem? I would argue that Qt's problem is: * Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe) * Getting started with Qt is pai…
> Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe) I should look this up because Qt is something I've got my eyes on for small projects that could get big. On that note, are you able to define "large-scale" for me? Would a desktop app' interfacing with a remote API be "large-scale"? > You have to write in languages that are n…
I would love to use Qt but their licensing and terms just immediately kill it for me: https://www1.qt.io/faq/#_Toc_2_5
Earlier quoted context omitted.
> Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe) I should look this up because Qt is something I've got my eyes on for small projects that could get big. On that note, are you able to define "large-scale" for me? Would a desktop app' interfacing with a remote API be "large-scale"? > You have to write in languages that are n…
You'll need a license if it's not open source as far as I can tell... I would love to use Qt but their licensing and terms just immediately kill it for me: https://www1.qt.io/faq/#_Toc_2_5
Earlier quoted context omitted.
I'm not sure I buy that, are you saying that the only reason that Qt hasn't completely taken over writing native software on (even desktop! not to mention mobile where Qt also works), is a marketing problem? I would argue that Qt's problem is: * Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe) * Getting started with Qt is pai…
> Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe) I should look this up because Qt is something I've got my eyes on for small projects that could get big. On that note, are you able to define "large-scale" for me? Would a desktop app' interfacing with a remote API be "large-scale"? > You have to write in languages that are n…