Qt Creator 4.10: What does it mean "WebAssembly"?
bogong last edited by aha_1980
Just download Qt Creator 4.10. There are new kits "Web Assembly".
What does it mean? Is there any info about it?
bogong last edited by
JonB last edited by
Yeah, wow!!! if this is your thing :)
It's brand new in Qt 5.12+ now, and I've already said in this forum that there should be a new sub-forum opened for it. I've already seen a lot of Qt WASM questions in General. I think I'll go suggest it now....
lorn.potter last edited by
Qt for WebAssembly is a new platform for Qt - running in a web browser served from a webserver.
@bogong WOW too, this is an amazing technique, but there are limitations
- The app is running in the sandbox of browser, which mean things cannot be done by js, will not be able to do by the Qt for wasm too.
- Qt for wasm do not support ssl yet(Qt5.13.1)
- QFile, QSettings do not work yet(Qt5.13.1)
- QSql may never work for mysql, mariadb since this is the limitation of the sandbox
- Size of the binary is very big compare with html, css and js, even a simple hello world could be a few megaBytes
- Multi-thread is partially work
- Cannot open a new process
Whatever, I am happy to be able to use Qt to develop web app, but the lack of ssl support become a big issue for me(A web app without ssl is a little bit pointless).
bogong last edited by bogong
Just made a little research of it.
I might be not so experienced in Qt but previously I've been handling web-projects for high-load and big-data (+50K connections per second in one server) based on PHP and Erlang since 1999 (created first web-site by me) and still doing it in parallel to Qt Applications. Qt Applications for me like additional to servers.
This techniques isn't fitted for real web-projects right now. It's for enterprise level maximum only, when you do not care about server performance and server load. It’s might be theirs goal when they been projecting this feature. There are a lot of things about optimisation and browser compatibility that should be done, it's might kill everything about next-level of cross-platform ... For me it looks's very-very questionable. Look below for only my own points of view if interested in it.
They trying to unify UI developing for Web and other versions of application. The idea is GREATE, but there are conflicts:
- The mobile proportion is vertical mostly - portrait, for web - it’s landscape (here the example developed by me in 2012, there are version of UI for different devices and web, the ability to do it was one of the reasons to choose Qt in 2011). The very often situation when it’s not possible or very complicated to create good design for both. For now we are split it into 3 parts Web - one, mobile - second, desktop - third. But all of them based on one library (BTW that’s why I’ve been asking about project architecture on this forum for splitting up the application onto backend and ui instead of using it like mono-block)
- If they going to unify server issues and device issues - It’s very questionable because of the nature of server issues and device issues and the server side operation system for example FreeBSD/Solaris instead of Windows.
It’s might be looking strange for someone who hasn’t been connected to server issue, but it’s OOP (Object Oriented Paradigm) that is point zero for Qt. Yes it’s OOP - it’s always slower then plain procedural solutions. Sometimes 40-50 times (based on real experience from Python usage on embedded devices, for now all of data parsing rewritten on pure C). But if the performance isn’t so critical - it’s might be written on Qt. In every web-project the main question - maintain. When you project that might be ran on 2 servers will require 4-5 it’s mean every month at least 4 * 300USD = 1200USD more, at the ear 1200USD * 12 month = 14400USD. For big project 5-10%% of performance mean thousands of dollars.
The web-application it’s not only application servers. It’s HUGE list of other services: firewall, balancer, monitoring, logging and etc. How about connection to this systems.
How about connection to DB Engines? - every web project means HUGE amount of data that should be stored and the Microsoft SQL Server the less used in web projects. How about NoSQL DB??? (BTW - from my experience it's the FIRST bottleneck that slowing down performance is connector between application and DB, one of reasons that been chosen Erlang and Mnesia that is Mnesia inside of Erlang from begin and therefore as result huge performance). The current way of Qt Db handling isn’t fitted for server’s solution at all. It’s super slow.
How about scaling application? - for now most of web-projects is 3-10 servers that means scaling. Is there mechanism for scaling it?
Beside all of it the most dangerous point is THE SERVER that is handling requests - What about it and security??? The Apache has +30 years of history and a lot of security issues, Nginx - +20 years, Node.js - 10 years and just became a little stable, Yaws (Erlang web server from begin developed for high-load) +10 years. If it will be requiring for guarding it anything else - then why would I use Qt if there well developed and secured solution?
Point … And other-other-other …
I understand that all of it dictated by marketing, but never the less.
The right way in this situation, only by my opinion, split up server side and web-ui. Server should be like service, might be additional type of project in Qt Creator for example "Server Backend" and web-ui for example "Web Application". The nature of server side might be described like "collector" or "aggregator" but the web-ui is "actor" or "agent". It's very different nature of each. About 8 years ago we've been developing application based on Chromium Embedded and then moved onto Qt WebUI - and it has been working perfectly. The application UI examples published here. But all of application been written on pure JS/HTML/CSS (the last version was on React.JS) and the same sources been published on Website. In this case you already have everything you need - Qt WebUI, and you looking on you application only like private web-browser that contain website inside. The Qt responsibility is finished on wrapping this JS application out. This approach has huge disadvantages - performance and huge memory usage.
This schema is the schema from real web project that has been handling +250K connections per seconds. The full schema might be taken here.
Based on this schema right way for this feature might be looking like:
- Split the project onto web-ui and server side, do not mix it. The global architecture is mono-block - for modern web it's might be very critical because load and traffic. The solution is 2-parts application that is using HTTP request through REST API between each of parts. The web-ui HTML+JS (kind of web-application like based on Rect.JS) and the server Qt Application. The server side need to able to be implemented into other technology stack, at least other well known and reliable web servers (Apache, Nginx, Yaws and etc).
- start looking on procedural approach from different languages for server side, there are a lot of solutions around that is very good.
This discussion might be prolonged further in case of necessity … And one question - why cross-platform for server solution??? Is it using in many servers of different OS at once??? I am in doubt of it. The server solution is always one for project. If they want to cover different operation system - it's OK. But they will always deliver in following ONE protocol HTTP/HTTPS - Hyper Text Transfer Protocol (in very custom situations might be another but it's VERY rare ). I repeat ONE PROTOCOL and it's the same for browsers many versions but they always handling DOM/HTML/CSS/JS or wrapped images/video into DOM/HTML/CSS/JS.
tham last edited by
@bogong thanks for sharing, l believe most of the users will not use Qt for webassembly to implement server backend but frontend. Whatever, l agree with you this project is not yet mature, but it got lots of potential.
If you asked me l would say create front end with QWidget and qml are easier to maintain,but l cannot use it before it become mature
bogong last edited by
front end with QWidget and qml are easier to maintain
@tham I am in very doubt of it, if you mean for Web using. Based on my own experience of developing UI for web and mobile. QML for Web is redundant because of absence of variety of abilities to demonstrate content in Web itself - there are ONLY HTML/CSS/JS everything else wrapped like text into HTML and in browser unwrapped for images, video, etc
I came to QML from developing UI (my first education - designer, artist) and it's GREATE solution for covering mobile and desktop. I repeat GREATE. I've got a lot of experience in native developing on iOS and UI on Android. For now I am handling alone application that is for mobile and desktop. And it's possible for being alone only if it Qt/QML, native is very difficult to maintain for one person both native platforms and additionally Web-UI.
The Web UI - is Web UI. There are no any different platforms. There are ONLY one platform - DOM model that is interpreting text from HTTP protocol, and nothing more. Yes - there are different browsers, but if you will look on it there are ONLY one Web Engine (the same in QtWebView). And there are only ONE standard of HTML/CSS. The time of various web engines (Safari, Netscape, MS Explorer) passed away. Qt developers need to reconsider theirs philosophy for this feature, especially in compare of well developed JS libraries. But if they will - the FIRST point THE f-wording Qt Creator. It's better to improve comfort and stability of developing in Qt Creator in compare of other IDEs.
All of it only my own opinion, based on my own experience ...
@bogong Qt for webassembly use another solution to draw the UI, you do not need to manipulate DOM to create your UI, everything could be done by QWidget and qml, no html, css or js are needed to build the UI.
Some examples of the UI created by Qt for webassembly
Try out slate, this example is stunning.
Since wasm still a young, immature tech, we can't find lots of libraries design for it, but you could call the js library with emscripten, I may do this recently, will write down what do I find out in this post after that.
bogong last edited by bogong
you do not need to manipulate DOM
I am talking about WHAT WILL BE ON USER SIDE. And on user side inside of browser ALWAYS DOM from HTML/CSS/JS and it's doesn't matter by which tech you delivering to browser. This is the POINT Zero. If you think that you will not - this is first mistake in understanding what is going inside of browser and what you should be delivering from server side to your users. In following Hyper Text Transfer Protocol (HTTP) you delivering TEXT (Hyper Text Markup Language HTML) that interpreting by browser into DOM model by inheriting XML.
I am not against Qt for Web, I am against the tendency that Qt developers trying to be followed. This tendency is strictly opposite to global web tendency - to minimise the size of data that is sending from server. And it's always not so comfortable for developers. The amount of data that sending through web - increasing tremendously year-by-year and there are real fight for every reduced bite. The Qt Developers following by wrong direction write now - to make Developers comfort life by adding this tech by any possible means. Sometimes when the soup has a lot of ingredients, it's loosing the good taste.
For me QML for web it's - overkill, it's better to create developers Qt solution for backend that might be used by SUPER-FAST-C-CPP-ORIENTED CGI/BIN that might be automatically implemented into Apache web-server (or any other that is supporting cgi-bin) and compiled for any platform/OS (Linux/FreeBSD/Solaris) and leave the WebUI for well developed JS libraries by making stable and well UI/UX experience in Qt Creator and improve the ability to have comfort live in Qt Creator. And there cross-platform philosophy a little transformed into cross-web-services that using CGI-BIN and might be used in any. When you developing for CGI - there are always HUGE amount of work by hand. If there are for example Qt Framework, that is developed for making CGI developers life better - it might be way for it. The same approach already using in Yaws - you writing application modules on Erlang/C/CPP that is automatically became like part of web-server that is very well developed btw. And there are stabilised solution for handling requests from client side.
Here the GLOBAL advantage of QT that hasn't presented in any other modern cross-platform solutions - ability to develop super fast and reliable backend on C/CPP!!! Why it's not used - for me the real question.
If Qt Developers reading it and interested in my experience - contact me. I've already been trying to use C/CPP(Qt) modules with Erlang for scaling, here the small example of connecting Erlang and C.
lorn.potter last edited by
Qt for WebAssembly is more about ease of deployment. Imagine having to maintain enterprise apps to be used on many different platforms/versions. So build/test infrastructure for 10 - 20 different builds. Compare that to deploying your binary ONCE over http that runs on all the different platforms and different versions of those platforms.
Qt Company did not create webassembly or emscripten that allows building all this. They merely jumped on the bandwagon early.
It isn't about creating web sites using Qt (although one of the tasks in the back of my mind is about creating a web site using Qt/Qml), but rather about being a universal platform for Qt apps to run on - compile once, deploy anywhere.
Direct access to the DOM is on the todo list for webasesmbly/emscripten.
@lorn-potter Any chances to release a prebuild version of Qt for wasm optimize for space(compiled by Oz) but not speed?