181–190 of 196 posts
Earlier quoted context omitted.
I can see where web assembly could take us, but I am confused about why people seem to want to go there.
Because Flash, Applets, .NET, Silverlight, ActiveX, NaCL,.... Difference being that WASM is kind of blessed format.
Earlier quoted context omitted.
Because Flash, Applets, .NET, Silverlight, ActiveX, NaCL,.... Difference being that WASM is kind of blessed format.
The problems with the alternatives you listed wouldn't have been reduced with more blessing.
Earlier quoted context omitted.
WebAssembly is binary packed bytecode and generally takes much less space than UTF-8 JavaScript source files.
Hello world in Qt is 25MB as a demonstration of 'lightweight' Qt.
#include
#include
int main(int argc, char** argv)
{
QApplication app{argc, argv};
QLabel label{"hello world!"};
label.show();
return app.exec();
}
$ g++ -O2 -g0 -fPIC hello.cpp -I/usr/include/qt -I/usr/include/qt/QtWidgets -lQt5Widgets -lQt5Core
$ du -csh a.out
16K a.out
Earlier quoted context omitted.
Qt does focus very much on embedded targets: http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-pr... Embedded is the biggest market for Qt right now.
A few notes: 1) Qt Widgets development stopped with 5.0. I had bugs filed on the embedded Linux targets and was told "sorry, these will never be fixed". 2) #1 means that Qt wants you to use QML. I need to run a Javascript engine on my target? Note in the comments of that blog post that they hope to run on an A7 (or really fast M7)...someday. 2b) ...And if they do run on a lower end platform, you still need a POSIX O/…
http://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/
> So, quite many new things for Qt Quick users, but not to worry – we have not forgotten users of Qt Widgets. On the contrary, already during the past year we have been increasingly addressing open bugs of Qt Widgets and intend to continue doing so during 2018 and beyond. Both Widgets and Qt Quick have their strong points and they complement each other nicely as fully supported parts of the Qt offering.
Earlier quoted context omitted.
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.
As long as performance is important, native software will always have an edge. Depends on the application.
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…
Qt with Rust is progressing well.
Earlier quoted context omitted.
They should port the rendering of the qt components to Dom/css with a web assembly backend. That would seem like a web app but allow for c++ code reuse.
I think that would be more feasible with something like wxWidgets or libui [0], which already use each platform's native widgets. [0] https://github.com/andlabs/libui
Earlier quoted context omitted.
As long as performance is important, native software will always have an edge. Depends on the application.
I’m a big fan of native UI, but I doubt this particular claim. The web stack is almost certainly more performance than GTK, for example.
Earlier quoted context omitted.
I used to care about the native feel, but now as long as something has a good UI I don't really care that much. Case in point, visual studio code. The file menu is native and that's about it. The rest is html / JavaScript and it's a great interface. I don't care that the buttons don't match whatever OS theme I'm using. The web never has.
> Case in point, visual studio code. I think most people consider visual studio to be an exception, not the norm. Whether or not visual studio's performance success represents what the typical developer should be expected to get when writing idiomatic JavaScript in Electron has probably not been fairly evaluated in the face of popular performance slugs like slack.