Qt for WebAssembly
blog.qt.io
blog.qt.io
This really rubs me the wrong way, it's a major step backwards for accessibility and user control.
WebAssembly lets you bypass Javascript - it should not be viewed as a license to build web apps that ignore user-defined shortcuts, don't work with screenreaders, aren't responsive on mobile, can't be customized with user-defined CSS, and that can't be scraped or automated in the browser.
Honestly, at the risk of sounding dismissive, I am increasingly suspecting that native developers just don't understand what the web is trying to do. The web is different from native because it's solving problems that native developers don't even realize they have.
Sometimes APIs on the web are difficult because they're poorly designed. But sometimes APIs are difficult because they're solving really hard problems that developers aren't aware of. Before those APIs are thrown in the trash, we should take a step back and think about why they were built in the first place.
It will be a large blow to the software industry if the result of WebAssembly is that everyone ignores large portions of what made the web great in the first place.
That being the required word. If Qt does all of its own rendering and ignores browser APIs, there's no way for it (just as an example) to defer to custom system fonts if a user is dyslexic.
Even assuming that the browser did expose everything necessary to re-implement its accessibility stack, screen readers and translators on the web are all using CSS and the DOM to figure out what to say. The only way to get real integration with browser accessibility tools and extensions would be for Qt to put wrappers around all of the entry points like DOM selectors.
And if that's the plan, why not save everyone a bunch of trouble and just use the DOM correctly to begin with?
Fair enough, Qt could theoretically read a font from the body CSS and then use it for internal text rendering. Although, correct me if I'm wrong, but Qt probably isn't using `fillText` to render it's font. A few other people here have mentioned that they're doing their own rendering and spitting out raw pixels.
(As far as I know) there's no way for Qt to leverage user fonts if it keeps on using that strategy. And again, if they're already planning on abstracting text out to use native browser APIs, why not go all the way and put the text in a DOM element?
Also it is worth to point out, that there are really 2 GUI toolkits in Qt:
Qt Widgets - the more classical, desktop UI paradigm. Yes, this renders everything into a bitmap and therefore translates better to the Canvas model on the web.
QML / Qt Quick - more DOM like, declarative UI with modern animation, scripting and data binding features. This maps better to the HTML DOM model. In theory at least, however, the similarity is only superficial. Under the hood, the QML visual elements are rendered with WebGL.
One possible approach would be to create an invisible <canvas> (i.e. display:none or position:absolute;left:-15000), use fillText at the desired font size for the subset of characters that will be used, read the pixel data back in, and use the (now bitmapped) font to render text internally. Using bitmapped font data could require patching Qt's render pipeline at a low level -- I don't know enough to say.
At the risk of sounding dismissive of web technology, this describes virtually every web application I've seen. Many years ago (early 00s), I dreamed of a web that was exactly as you describe it, but what we have today is far from it.
If applications that don't overload user-defined key events (apparently, this year it's trendy to ignore Page Up and Page Down events because they break custom scrolling...), respond well to being customized with user-defined CSS, are easy to scrape and automate, and don't have entirely foreign and weird UI metaphors were a thing on the web, we certainly wouldn't have people clinging to native applications. But this really isn't the web we have.
What's left as an advantage for this model of running native UI code in a canvas is that at least you get native looks, as opposed to whatever the cheapest UX designer the company managed to hire cranked out on his sixth sleepless night in a row, and get to skip the boring installation, and get some free sandboxing with it.
It's definitely not great and it's far from what I hoped we'd have but I'm willing to take it over what we have now.
The majority of native apps that I use basically boil down to fancy ways to display or edit document-like data. Music players, maps, terminals, text editors, file browsers, etc...
I think these interfaces would all be more elegantly expressed via an HTML-like model; and the insistence of application developers that they need pixel-perfect control over these kinds of interfaces is just a relic of a world when everyone used desktop computers with a single resolution monitor.
There are of course a ton of smart people who disagree with me on that, so take it with a grain of salt.
I have custom CSS and Javascript I load onto sites like Youtube and, back when I still used it, Facebook as well. And to be clear, neither of those are good web apps by my definition; Youtube is a SPA that forces me to use mutation observers to tell when new DOM is added. Facebook does some really weird stuff with iframes. But, I can customize both of them, right now, without the developers' permission.
I'm also using the web to automate Twitter right now for a side project. Twitter's API is a mess, so it was far easier for me to just load up Headless Chrome and do my automation through it. Generally speaking, even if a site is outright hostile to bots, it's not terrifically difficult to build undetectable automation tools for it that work anyway.
I completely agree that people do crummy things on the web - the web should be better than it is right now. I don't dismiss that you've had bad experiences on the web, but at the same I wonder if I just frequent better sites than you do or something. On the whole, even sites that I think are fairly badly designed are usually more responsive, more customizable, and frankly better designed than most native apps that I use.
I use Linux pretty much universally. Most Linux apps don't work well with touchscreens (even the native apps bundled with Gnome are a problem). Most Linux apps can't handle fractional scaling or zooming. Most Linux apps are not user configurable in any way whatsoever. None of them are easily scraped or automated unless they expose a CLI interface. There are definitely exceptions, but... that's the experience I run into daily. Same as above, it's possible that I just use different apps than you do.
When a GUI element is bothering me on a website, it usually takes me less than a minute to fix without restarting or refreshing the page. Maybe 10 or 12 minutes to code a permanent solution. If a GUI element on a native app is bothering me, I usually need to recompile it from source.
I almost feel like we're coming at this from different perspectives and with different concerns. It's obvious to me that with my concerns moving to a Qt style approach would be a step backwards. For users like me, even the crappy, SPA infested, poorly optimized load of dung that the web is right now is still miles ahead of native platforms when it comes to giving me, the user, control over the code I run.
I don't know, I may just be optimizing for different things than you are.
What I will say is that if you build a web app right now and you utilize CSS and the DOM, you at least have the option of making a user friendly experience. If you compile with Qt and publish to the web with the implementation they have right now, you don't get that option. Your app will, objectively, be worse than even the Facebooks and Grubhubs and Twitters and whatever of the web, at least by the metrics I care about. And nobody will be able to fix it without recompiling and self-hosting your app.
I think that's a step backwards, but maybe you like Qt enough as a dev environment that it's something you're willing to tolerate.
So that's probably a question of familiarity.
Consider something trivial as centering a user control within a parent control. Good luck getting it right with HTML and CSS in a way that works across browsers. With QML you just write:
Rectangle {
anchors.centerIn: parent
}
There is some discussion on this from last year - https://news.ycombinator.com/item?id=14894937
That's hardly a fair comparison though. CSS and DOM are, by now, established technologies (with which I still cannot reliably center something -- which I can achieve on Qt by dragging and dropping things in a UI builder -- but I digress...), whereas Qt's support for this stuff is basically at PoC level.
As for everything else... I think we definitely use different web applications and different Linux applications :-). Ease of scraping aside -- which is a valid concern in general, but hardly so much of a problem with FOSS software, where, if I need the data that the application uses, I can usually hack it to dump its data in far less time than I can write a reasonably reliable web scraper) -- my experience with web applications has been slowly declining over the years, to a point where I've dumped almost every web application I've used.
Case in point: the World Cup is big these days. Google's "dashboard" or whatever they call it for this event -- which I find very representative for today's web -- drives me nuts:
- I can't scroll with Page Up/Page Down
- Clicking the big "X" in the match view page takes you back to the search page, not the dashboard, even though you reached the page from the dashboard so "closing" that "window" should just give you back the damn dashboard!
- You cannot select anything, not even stuff like statistics, which really can't be under copyright protection
- If I click the name of a player, I get to a Google search about him (awesome). If I click the "back" button from that page, I get back to the dashboard homepage? If I click a team in the Tables view, I get to a team-specific view; if I click "back" now, I'm back to the Tables view, not the dashboard homepage. I have no plausible description of the logic behind this.
- And, due to CSS being CSS, some of the table headers overlap
And don't get me started about the latest design innovations, like oversized, nondescript widgets, huge empty spaces that make you scroll umpteen screens for fifty lines of data, infinite scrolling (dear God...) or, worse, that thing which "scrolls" one screen at a time with animation effects so that it looks kindda like powerpoint slides.
I also appreciate how easy it is to "fix" a bad widget in a web app's UI, but I can't remember the last time I needed to fix one in a native application (well... except for some of the more questionable choices in GTK3, again).
I think we just want really different things here :)
This web application does not have to pretend to be a hypertext, but otherwise this looks very familiar.
And there is something to gain: A proper language, less resource wasted at run time, the vision of "Compile once, run anywhere", but this time for real and sandboxed.
Who does that?
> reimplements the DOM in js
I am assuming you are referring to the Virtual DOM? In which case: no it doesn't. It's an abstraction for working _with_ the DOM, but it doesn't do away with all the advantages of the DOM - like canvas does.
> (making URL way less usefull, breaking back and forward, and open in new tab buttons).
This indeed used to be done, but with the History API having been usable for years, you hardly ever encounter that any more nowadays.
> Who does that?
Google in some of their developer docs for example.
History API is standard, but not usable for a lot of things. I'm on a project that has to play nicely with server-side routing, so we are forced to use hash routing like it's 2001. Likewise, the ability to save state in the builtin History API forces some workarounds and doesn't play too nicely with things like testing.
Yes, I meant virtual DOM. And yes it does. It's another (complex) layer of indirection encapsulating already extremely high level API, that is already looks like the most elaborate API to navigate a tree.
And what advantage does using the dom bring me? Respect my font settings? My system Theme and accessibility settings? In theory zooming should be easier, but in partice it isn't. My keyboard settings more than a canvas? Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it?
Text reflow on mobile is better. But AFAIK Chrome removed this feature because it broke to many websites anyway. Opera is the only brower to do it. Market share ~5%.
Even with the History API you completely break all assumptions about url. You can share a link with a single page app just like you can with this example; it doesn't make much sense, tho.
Yes, specifying shortcuts and fonts at the browser level is better than doing it application by application. Browser zoom is usually vastly preferable to just magnifying the screen in my experience. Handling gestures, intercepting all keyboard events (including right click menus), and reimplementing settings like smooth scrolling on canvas is much more difficult and will give you much worse performance than just letting the browser do it for you, because you'll have to reinvent the wheel for every input.
A good example of this is multitouch. Many websites were written before touchscreens were common. Most of those websites work with touch scrolling on my tablet, even though they haven't been updated. If you bundle an application with Qt and 2 or 3 years from now a new input format becomes commonplace, your site won't work with it unless you recompile and re-ship because it's up to you to interpret every piece of raw input that you get.
Add to that the fact that many browsers handle input differently because different devices call for different behaviors. On sites that aren't optimized for mobile, your phone browser uses extra logic to make sure that your clicks are intentional. If you're manually handling everything yourself via canvas, you can't do that without trying to guess what device a user is using - an increasingly difficult task.
> Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it?
It's way easier. You're talking about using some kind of Machine Learning system or algorithm to take the place of explicit accessibility controls.
Programs like Jaws do so much more than just read text off a page. They allow you to jump and scroll to specific headings. They allow you to get a list of every link on a page. They allow you to fill out an item on a form and jump to the submit button with a key stroke that you define (not the webapp) - or select an input field and read off the associated label or help box attached to it.
There's a huge list of Aria labels and tricks that are used to make the DOM accessible, and none of them work with OCR - hidden icon labels, alt tags for images, etc...
Accessibility is not just about reading off random text on a page. It's about context. The reason why a blob of pixels isn't accessible is because anyone who's blind loses all of the context. You lose the ability to take a hunk of content in your application and say in a universal language that every screen reader will understand, "This is the navigation. Bring the user here if they want to go somewhere."
That stuff doesn't stop being important just because you made an application - arguably, it's much more important for an application than it is for a blog post or document. For a blog post you could make the argument that as long as your screen reader reads the text in order, you're still getting the gist of everything.
For an application, a blind user needs much more context and much better structure than would otherwise be required for just reading.
I've built enterprise level web applications - for us to say that we were compliant with accessibility standards, we had to do a heck of a lot more than just allow people to read text. The DOM helps with that.
Well, the way your operating system works with UI is that it gives each application one or more pixelbuffers, where the apps draw their pixels however they want (2D drawing API, 3D gpu-accelerated API, a widget toolkit, a HTML DOM renderer, etc). At the end of the day, you could say that any application interface is just a metaphorical Canvas - a memory buffer that is composited with other apps and eventually copied over to the screen buffer by the OS. Web browsers are becoming more and more like operating systems in this regard. Is it a good thing? That would be a good discussion.
> This really rubs me the wrong way, it's a major step backwards for accessibility and user control.
Accessibility has really nothing to do with Canvas, when you look at it simply as the API for drawing pixels. Accessibility is a way of providing the OS (or in this case the Browser, which in turn provides this info to the OS) with a parallel stream of information that describes the scene (text content, navigation controls, etc.) The OS then makes this info available to accessibility tools such as screen readers or data scrapers. Accessibility is a completely orthogonal concept and should not be tied to rendering. For example, you are probably not going to need to support a Braille screen reader in a 3D zombie shooter game, yet you can use Canvas 3D to render it. After all, accessibility in games is a different topic entirely. What you want, is an accessibility API that you can use or ignore, depending on your use case. If you don't want to deal with an accessibility API manually, use a widget toolkit that does it for you. Coincidentally, the Qt Widgets library has accessibility features implemented when the underlying platform provides an accessibility API.
> Sometimes APIs on the web are difficult because they're poorly designed.
I agree that most of the issues described in the parent post is a direct consequence of bad or non-existent API. After all, a runtime is nothing without powerful APIs.
> I am increasingly suspecting that native developers just don't understand what the web is trying to do. The web is different from native because it's solving problems that native developers don't even realize they have.
In all honesty, I believe if web developers took some lessons from the native world, they would realize that many of the problems of the web platform arise from its poor design and application of wrong paradigms on the wrong problems. Take the whole web UI thing for example. Even most trivial things, like trying to center something on the screen in HTML+CSS is a horrendously difficult chore with many possible and no right way of doing it. The whole idea, that a simple markup language that was designed for publishing and linking of text documents, can be used as the basis of a general-purpose application platform, is ridiculous.
This is what I mean when I question whether native developers understand the web.
Accessibility has everything to do with semantic HTML. You're complaining that the browser doesn't give you an accessibility API. It does, it's called HTML. You're also allowed to separately style it, that's called CSS.
Heck, you don't even have to use it for your visuals. Qt could spit out a separate transparent HTML stream that never gets shown to users and that alone would help with a huge portion of the problems I listed above.
Or, much better, Qt could then apply styles to that separate stream of content and fall back to canvas only when CSS wasn't powerful enough to style a given widget, because accessibility is also about giving users access to that raw content so that they can override the look and feel of your application.
Of course, there are rare exceptions to this rule - for example, 3D games. They may use canvas and may not even expose an accessible view of the canvas contents (although to be clear, they could still do so via additional elements on the DOM). Again, this is the exception.
If an app is using Qt Widgets, of course they should be leveraging the browser's built in accessibility API, otherwise known as HTML.
> Even most trivial things, like trying to center something on the screen in HTML+CSS is a horrendously difficult chore with many possible and no right way of doing it.
What? Give your element a width and then set margin left/right to auto. If you want to do something very complicated, use flexbox or CSS grid. If all else fails and you're OK with using Javascript/WebAssembly (which Qt is) then you can even do polling and absolute positioning. CSS has plenty of dumb API decisions, but do people still actually struggle with centering elements?
This is the other thing that makes me suspect that native developers sometimes don't really understand what they're criticizing. It kind drives me crazy when native developers complain about stuff like this, given that the majority of the apps on my Linux box don't support fractional scaling for HDPI displays, can't handle multitouch, aren't built to use em units for margins and width when I customize my font size, and don't have any breakpoints for when they're resized or snapped to the side of a screen.
These are problems that we solved on the web over a decade ago. On native Linux platforms, we're still debating whether fractional scaling should happen within an app, or whether the window manager should handle it.
Some of CSS's complexity is there for good reason, because the extra tools and interactions are necessarily to style content in a way that works well with a platform as broad and diverse as the web. Some. That's a very qualified 'some', CSS does admittedly have some really dumb decisions in it.
But in general, I find it difficult to believe that native APIs have solved all of these problems, because otherwise I wouldn't want to swear every time I booted into Linux on a tablet.
> Web browsers are becoming more and more like operating systems in this regard. Is it a good thing?
It's a bad thing. We went through this with Flash and Java already. It wasn't just bad because of security vulnerabilities, it was also bad because people built their entire websites in Flash and Java and they were unresponsive, inaccessible, and broke common web paradigms like browser navigation and URLs.
What Qt is doing now is better in the sense that at least the code is now properly sandboxed, but it still falls into all of the other Flash and Java traps.
A properly designed document or web site will be easily accessible, but this falls apart for web applications, where it's no longer enough to have mark up, because HTML has no knowledge of UI elements like menus, windows, views, buttons and their roles (links are sort of close), control groups etc.
But the rendering/interaction web tech was designed for documents, not applications.
That browser VM is an OS in disguise. We should be able to use application development tools on it.
> Sometimes APIs on the web are difficult because they're poorly designed.
> But sometimes APIs are difficult because they're solving really hard
> problems that developers aren't aware of. Before those APIs are thrown
> in the trash, we should take a step back and think about why they were
> built in the first place.
I think the reality is much simpler. Most Web APIs are bad because they have been designed to solve an overly specific problem, with the assumption that Javascript is too slow, and finally messed up by too many cooks.
The worst examples are WebAudio and WebRTC. A good Web API (unfortunately about the only one) is WebGL.
Most Web APIs deserve to be thrown into the trash TBH.
Browser makers and web standard makers need to read the extensible web manifesto again and again and again:
The web is creeping closer to becoming a Java that actually works. In another decade, we will have come full-circle. Someone will have the "new" idea of adding a declarative layer (maybe with some XML-like syntax) that can be translated to canvas. While the few remaining old devs will remember, all the new devs will jump on this "emerging technology" and we'll start re-inventing anew.
And so the wheel turns....
A lot (maybe most?) of software is written for explicit purposes to targeted audiences. I am not going to hire a blind person to label signs, a deaf person to review music, or an illiterate person to review books.
Sometimes you have a bunch of C++ code that works, but the difficulty of application distribution upgrade is high... okay, to the web we go!
FLASH was bad in many of the same ways; but it played a valuable role in people's lives.
http://example.qt.io/qt-webassembly/widgets/richtext/textedi...
It's like the web version of godawful cross platform Java apps from the 90's where they stick the Mac version's menubar inside the window because it looks right on their machine.
I wonder if screenreaders work for reading and navigating this.
EDIT: This comment comes across as totally negative, so I'd like to amend that I think there are good use-cases for it. Games or more visual things, sure, I don't care if the text isn't a pixel perfect match to everything else on my computer.
But for things where reading or writing text is the primary purpose, having the same font face at the same size render differently from the rest of my computer is not something I want to see becoming common.
Dude, that battle was lost when Electron gained traction. I hate it with all my heart, but it's a sad reality.
Good font rendering makes SO much difference in how stuff looks. No joke: font rendering is the number one reason I prefer the look of macOS over Windows (especially now since WSL exists). I realize I'm a weirdo font nerd and probably alone in that stance, but working with computers mean staring at text on a screen for hours and hours every day. It fucking better be rendered right.
There are other issues like contextual menus, in VS Code they're handled well and give you all the actions you'd expect. But in Slack it gives you the bare minimum OS included items and has their own "..." button on each message for things that ought to be in the contextual menu.
It can also do multiple windows (again, see VS Code which is a good example), but Slack stuffs everything into one window (preferences overlay is a good example of what should be separate) because it's a much simpler wrapping of a webpage instead of being designed as a native app would be.
Unless Webassembly provides a common type rendering system or links to the Browser's host renderer, I'm not sure this can be fixed.
It's just pixels. Barring patents a wasm program can text any goddamn way it wants to.
Sure there is - put the text in the DOM.
WebAssembly is just a runtime, it has nothing to do with whether you display your stuff in Canvas or via the DOM.
If you were writing an app in Javascript, you wouldn't bundle a text engine into it and then bypass the DOM for all of your rendering. Why is WebAssembly different?
Sounds like a good proposal for the WHATWG.
For reference: http://jakiestfu.github.io/Medium.js/docs/#invoke
Overall, I think that's a decent trade-off. Most of the UI is quick, easy, and (potentially) extensible using HTML while the performance-sensitive parts move to what's basically a raw buffer.
https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
Speaking of which, the linked page is no longer up, so here's a Wayback Machine impression: https://web.archive.org/web/20100304101843/http://labs.troll...
... and ofc the Google Video link in my comment https://news.ycombinator.com/item?id=1056393
> 1 point by leoc on Jan 16, 2010 | parent | favorite | on: QT on Google Native Client
> 1997^H^H^H^H1961 is calling; someone just picked up the rotary phone. http://video.google.com/videoplay?docid=-2950949730059754521....
is now broken too, so here's a link into a YouTube upload: https://www.youtube.com/watch?v=oKg1hTOQXoY&t=612s
but it is really cool
because ad networks don't trust their own clients to not spoof the traffic numbers.
Improved performance is great, but not very helpful if it means the solution gets considered a nonstarter by almost everyone evaluating it. As long as the responsiveness is acceptable, I'd rather have a DOM-based approach that supports accessibility and generally behaves like other web pages; users who need better performance can always switch to the native app.
Maybe some kind of hypothetical hybrid approach could somehow get the best of both worlds, or maybe both render targets could be supported (with DOM default/preferred and canvas recommended for use cases like games that need the performance gain).
Guess what? At one time, you could do just about anything imaginable using Java applets. Then browsers caught up and soon after, Flash appeared; rinse and repeat many times...
Qt on WebAssembly is just another leap forward in what is possible, and it’s good because it raises the bar in some fundamental ways. But as /be says, “always bet on the web.” It will catch up and this too shall pass.
So my point still stands — Qt on WebAssembly is analogous to the plugins of yore like Flash and Java applets. WebAssembly is kind of like a new plugin container for native code.
No it’s not. With WebAssembly, it is a matter of trust in your browser vendor and its ability to properly sandbox WASM/JS content. With plugins, you basically gave up full control of your machine also to whichever plugin vendor. The number of trusted relationships is different - it’s fewer with builtin WebAssembly. That is a noteworthy distinction, I think.
I think, it could have been Java (or the JVM at least) in place of WebAssembly in browsers already a long time ago, were it a more open standard.
Java itself is a very open standard (OpenJDK, Java language standard, etc.). Openness of the standard wasn't the problem. In fact, it offered a much stronger uniformity of experience no matter what browser you used, unlike web technologies of the time.
The security issues with Java and Flash were the final nail in the coffin, but they had already been fading -- Java due to UX issues and startup lag, Flash due to it simply being a divergent technology from the web itself.
What OpenGL supporter always forget to mention is that all middleware that matters already has Metal support, even some ML frameworks have better Metal Compute support than OpenCL.
If the above is even 2/3rds what happens, what stops QT from taking over all multi-platform targeted applications "one <toolkit> to rule them all" style?
I for one am excited to see Electron to get ported to wasm so we can complete the circle
I also noticed that a lot of people tend to choose electron arguing that unlike Qt (which is under LGPL), Electron is under MIT, but it seems that they are not aware that it's only the electron scaffolding part which is MIT, not the whole electron framework which includes chromium, ffmpeg which are also LGPL.
Though overall I'd wager that there's an order magnitude more cross-platform single-toolkit apps built with Qt than with other frameworks.
macOS icon file can be created with png2icns, Windows one with icotool.
Overall, the whole process is easily scriptable. I'm making small games in C with Allegro 5 and I'm using only GNU/Linux. It wasn't hard to make scripts to automate the whole process of making builds for Windows, Linux and macOS. Android was a bit more tough, but manageable - I wanted to have it all done with CMake instead of Android Studio though, so that probably made it harder. The hardest was "HTML5" build with Emscripten, but it works now. It's a pity that iOS is off limits for that though...
yes, I know osxcrooss but it is not legal to use if you aren't developing on apple hardware which makes it a bit cumbersome. Grep for "Authorized Test Units" in the xcode license linked in the repo.
It literally says (section 2.2, Permitted Uses and Restrictions):
"Install a reasonable number of copies of the Apple Software on Apple-branded computers"
but here you're not reverse engineering, you're copying proprietary software for which you don't have a license. Reverse engineering is allowed if you have the right to use the original software ; you certainly don't have the right to reverse-engineer e.g. a software that you would find on a CD somewhere in a park without a license attached.
I probably wouldn't care anyway, sorry Apple.
Sure, you can use Electron right away, you don't even need to understand what you're doing. That has probably a great value for people who want to learn or for scrappy hobby projects, but shouldn't matter for anything serious.
I'll admit my experiences with Qt have been fairly limited relative to my web work, but picking up QtWidget seemed like it had a much higher barrier of entry than a web tech stack. Although I'll also recognize that QtQuick and QML greatly seemed to streamline the whole thing, especially for getting started. Based on my experiences performance with QtQuick still left a bit to be desired, but it was still an improvement over most Electron equivalents.
It's also worth noting that these comments mostly apply for people going for a mostly-native look and feel. If you want to completely customize the look and feel of widgets, as many modern apps have recently begun to do, I think it might be easier to get started doing that with the web stack. Then again, I recognize that this just might be my inexperience talking.
It also depends on the kind of app you're trying to build. I've written lots of personal apps using server-side rendering and a tiny bit of JS and I love how easily I can deploy and access it from all devices. That's a kind of versatility you just don't get with native.
IMO, most web developers could probably learn a lot from giving Qt and other native toolkits a try.
This is a common misconception of beginner Qt users or people who just looked at Qt superficially and decided not to use it, because it's not "regular C++".
You use Qt with 100% pure C++. Qt itself is written in 100% pure C++. The part that confuses people is the metaobject compiler (or MOC). This is a simple code generator tool that provides additional features like runtime type information and reflection. It does not modify your source code, only generates some additiona, 100% legal C++. Granted, this requires an extra build step before invoking the C++ compiler. But Qt's build system handles this automatically, and it's not really difficult to integrate into any other build system.
Starting with Qt 5, you don't even need to invoke the MOC compiler, because in many cases, the features provided with generated code were replaced by new C++11 functionality.
If/when C++ gets proper metaclasses and programmable compile-time code generation, there will be no more need for MOC, because all of its functions can then run in a single compilation step.
There's a great blog post debunking the myths about the QT metaobject compiler - https://woboq.com/blog/moc-myths.html
The browser is destined to become a general purpose VM, only if our benevolent overloads don't want to fully pursuit this road.
Flash and Java were not the same thing, they weren't meant to augment slow parts of java script.
There is nothing you are seeing here that could not be done with javascript already, it would just run slower.
Yeah, but there isn't much temptation to make QT-like widgets on Canvas with JS, since JS is fully integrated with the DOM. While the temptation for web assembly is to do exactly that, and thus the parent question.
'Temptation' has nothing to do with the lack of java and flash similarities, and the lack of being contained to a single component within the page that doesn't interact with the rest of it.
The fact that Electron is much better. I know this in a highly unpopular opinion here. I've programmed in them all (MFC/wxWidgets/QT/WinForms/WPF) and HTML/CSS/JS is just so much easier.
Maybe when I get to see Blend implemented with WebComponents.
Moreover, it's unfair to insist on portability when comparing native vs. Web without doing the same on the native side.
There plenty of deployment scenarios with other kinds of browsers.
Of course it is fair, using something like Qt, wxWidgets, or even roll our own was never as complicated to get pixel perfect UI across OSes.
Desktop centric UI toolkits provide a set of widgets which lets me build up a UI in a predictable way that respects my sanity.
Windows Forms, WPF, Qt, vxWidgets, tkinter, Java AWT, SWT etc they all have warts but ALL of them feel faster than building UI for the web.
The problem with web is that there are no consistent set of widgets.
Let's take a stupid date picker. A year ago for a project I thought I'd use the HTML5 <input type="date"/> way no Javascript needed!
Sadly I couldn't figure out a way to keep the calendar in an always on state so had to resort to jQuery datepicker. So jQuery widgets was an attempt to do what desktop UI does but now that is no longer in vogue.
Today on the web there is no consistency, there is no agreed upon toolkit. How many different approaches to widgets does React have?
Ideally you would be able to import a web component into your project and use it without worrying about any abstractions leaking.
Look at the support for (flexbox)[https://caniuse.com/#search=flexbox] for instance.
Where there are devices beyond computers and smart phones with browsers on them, the majority of them without any kind of update system in place and based in some kind of browser implementation.
Or you use a cross-plateform (not so native then) UI toolkit, like Qt. You have a sub-part UI experience and you still need to write C++. Why would you do that ? (And that's why the vast majority of software isn't developed this way).
CSS and JavaScript have quirks, but I mean, we're talking about C++ as an alternative …
Either do a new one for platform, which was the case when Assembly ruled.
Or make a proper application architecture suited to the applications being done in-house, that wraps the native APIs into general ones.
C++ is strongly typed and compiles to native code, a much saner alternative than "anything goes JS".
And CSS + JS are miles away what something like VB, Delphi or Smalltalk allowed in the early 90's.
Yes I know they weren't responsive and whatever.
There were layout managers already available, it was just a matter of actually using them.
Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers that are re-inventing the idioms of the 90's desktop UIs[0], than experienced C++ developers aware of what actually takes to make a good UI/UX.
I think you just nailed the essential point: in 2010+, the young and cheap developers are JavaScript ones, and not C++ ones. Maybe that tells something about which one is the most accessible, don't you think?
For example, a road built with cheaper materials will break and need to be patched more often. A poorly engineered application will be slower, consume more CPU power, more data bandwidth and require more storage space, will be buggier and waste more users' time.
With only a very basic understanding of economic theory, I would imagine that market forces at scale would optimize these inefficiencies and ultimately work to reduce total costs. Perhaps this unconscious, natural process would even work, were we not consciously optimizing against it on the wrong variables, such as the next quarter's profits.
C++ (though statically typed) is weakly typed.
Unfortunately it was our wedding website and I didn't think "let's hold off until I can use Qt/WASM" would go over too well ... :-)
LOL
HTML was designed for structured, flowing text documents and everything else got bolted on top with only partial awareness of where the journey was headed (reading up on the origins of stylesheets and the relevant discussions is interesting in this respect). As a result it's just a mess for what it's used for now, pain-alleviating salves like flexbox notwithstanding.
When I do any non-trivial UI in the web stack, I can feel I am in continuous workaround territory. I'm trying to bend something ill-suited to my will. I don't get that feeling with QML.
That has been my experience as well.
I think the web dev crowd advocating HTML/CSS originates in a) limited knowledge beyond the web tech field, and/or b) thinking that web is the state-of-the-art of computing.
The trouble with modern web is, that it was not so much designed as it evolved. But evolution in general is doggone slow and produces mistakes and mutations. I think the evolution of the web platform is still in a very early phase.
If all you know is C, writing an “Hello world” in C will be easier than doing the same in Python, but is that really a good insight of which language is easier to write ?
Try doing that in pure HTML/CSS/JS, you're basically left with a clusterfuck. There's piles and piles of libraries built to workaround this clusterfuck from Bootstrap to react-modal and even the best of them have worse APIs for this than Qt does.
Ultimately, drawing widgets just makes more sense for desktop applications than trying to hack document-oriented HTML to be a usable UI framework.
Don't get me started on layouts...
<dialog>
<p>Hello world</p>
<button>OK</button>
</dialog>
<script>
let dialog = document.querySelector('dialog');
dialog.querySelector('button').addEventListener('click', () => dialog.close());
dialog.showModal();
</script> Electron v2.0.2
Chromium v61.0.3163.100
Node v8.9.3v8 v6.1.534.41On the flip side Electron explicitly does not impliment confirm() and prompt() which made me furious.
So there is definitely truth in the general js=cluster-fuck sentiment.
Electron has native dialog APIs: https://electronjs.org/docs/api/dialog
- learn C++
- install a C++ compiler
- learn Qt
- install Qt
For the web, you just need a browser, and JavaScript & CSS is way simpler and with way more documentation (especially for beginners). And for a simple modal dialog, you'll end up with 20 lines of code with no need for any framework …
- learn html
- learn css
- learn javascript
- learn ui framework whatever
- learn what a transpiler is
- install node.js just to process your files
- learn how a client-server architecture works
- learn how to setup a web server
...
dude, you just don't know how deep this rabbit hole is
You need to learn HTML, CSS and JS, but that are orders of magnitude easier than C++. Many people using it doesn't even have any computer science training.
Everything else you said (transpiling, framework, webserver) is totally optional and context dependent. And absolutely not needed to write a modal … I wrote a personal website this year, and I didn't need a single of this. Of course they are useful if you want to write a professional web app, but so is unit testing, a CI server, or a build system. But this isn't necessary to do simple stuff on the web.
Writing a website has a incredibly low barrier to entry, that why so many people complain about web developers not being real devs.
If you think the web is harder to grasp that the C++ ecosystem, you're being delusional to say the least.
Learning Qt is much easier than the JS ecosystem. It's one intergrated package with no messing around and a very clear suggested structure to applications.
My coworkers still seem to want to hack everything in to main.js, can't understand react and one of the main libraries we are required to work with just doesn't integrate well with it at all. On the Qt side of things everything flows smoothly, the class architecture makes sense.
You need to realize the world you live in: while still useful for some specific applications, C++ is not a mainstream language anymore.
It still does nowadays, in 2018, and like any good CS degree it teaches lots of other programming languages and paradigms as well.
There is lot of room for learning during 5 years.
If a computer science class in 2018 only does language X or Y, it is indeed quite poor.
If a university wants to teach object-oriented programming, they can teach Java or C++. Guess which wins the decision in the majority of cases …
C++ isn't mainstream anymore, get used to it.
Python: 1991
JavaScript: 1995
> If a university wants to teach object-oriented programming, they can teach Java or C++
Or Python. Or Smalltalk. Or Ruby. Or...
IMHO you both go off the opposite ends: No, a generic "developer" isn't badly educated if they don't know C++, but that doesn't mean C++ is some irrelevant language. It's critical for some domains of computing, and widely used.
I never said it was irrelevant, I said it wasn't the mainstream it was in the early 90s. See my post above:
> while still useful for some specific applications, C++ is not a mainstream language anymore.
So are on the same line you and I :
> a generic "developer" isn't badly educated if they don't know C++
In 2018 C++ is the programming language driving Machine Learning, VR/AR, HPC, Fintech, GPGPU, WebAssembly, compiler research, OS research.
Which are all CS degree relevant subjects.
If you want to learn a specific language for whatever is currently cool on the job market there are vocational schools for that.
I like Python too.
https://insights.stackoverflow.com/survey/2018/#development-...
> Not everybody has a slow laptop
You still havent responded to my point..
DOM is very good for laying out webpages, but seriously falls over when trying to do layout for applications. The layout of the frameworks you mention are all designed around making application layout as efficient as possible.
Although WPF stands out, it's layout is for more DOM like than the others, and suffers for it.
Huh. I thought the point of WASM was for there to be precompiled binaries.
[0] - https://developer.gnome.org/gtk3/stable/gtk-broadway.html