> 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.

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.

I think, it's time to start to perceive content publishing and application authoring as two distinct disciplines. The problems you describe arise from mixing them freely and without much thought.

I've posted this elsewhere as well, but I don't think they are two separate disciplines. I think that application authors in many cases should be restructuring their apps to fit content publishing paradigms.

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 don't agree with people who say the web is a failed platform.

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.

If web-Qt goes widespread you'll be editing QML scripts (which is much more pleasant for applications than CSS scripts) and installing WebGL/WebVulkan hooks/shaders.

So that's probably a question of familiarity.

Yes, this. The HTML language and DOM model is inadequate for implementing interactive user interfaces. It's a text document markup language after all. QML has its own DOM structure and a library of primitive visual elements called QtQuick. QML and HTML are very similar in fact. The main difference though is, that the QML language and its library of primitive elements was designed from the ground up as the language for building interactive, fluid, animated user interfaces.

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
    }

Now I don't say HTML can be replaced by this. I am advocating, that both technologies have their relevant use cases. They could coexist in a browser. I can imagine even mixing them together: QML for the layout, user controls and interactions with chunks of inline HTML for text formatting and document embedding, or vice-versa.

There is some discussion on this from last year - https://news.ycombinator.com/item?id=14894937

> 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.

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 :)

The web today rebuilds the scrollbar in javascript (overriding Browser UI), reimplements the DOM in js (I doubt this abstraction is more lightwight than rendering into a convas) and builds single page applications (making URL way less usefull, breaking back and forward, and open in new tab buttons). This doesn't look any different.

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.

> The web today rebuilds the scrollbar in javascript

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.

What pjmlp and hajile said. Besides:

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.

> 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?

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.

Thank you for helping make people aware of all the things canvas throws away, usually.

Webkit browsers have the (somewhat limited) ability to manipulate the scrollbars with pseudo-selectors. For everything else, it's JS or deal with whatever horribleness that browser gives you.

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.

> > The web today rebuilds the scrollbar in javascript

> Who does that?

Google in some of their developer docs for example.

Let's be real. The defining thing of the web was the distribution model: you install a VM (the browser), and all the software just loads.

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.

I mostly agree, but:

> 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:

https://github.com/extensibleweb/manifesto

Consider Electron if it shipped with only v8, wasm, and a builtin canvas-style buffer without the rest of the HTML trappings. You now have a UI platform that is safe, performant, and (most importantly) runs everywhere the same way.

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....

Ah The Wheel of Time. It turns and Ages come and go, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth returns again.

Or you can just implement required accessibility features somehow.

> somehow

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?

... But it is possible to write bridge code that uses browser APIs to provide custom user fonts to Qt for use in a <canvas>.

Oh crud, you are completely right about that. I forgot that canvas allows you to pass in a font family when it draws text.

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?

This release of Qt for WebAssembly is the first officially released prototype of this technology. Qt comes from the native desktop world where it relies and builds on top of the whole rich world of native OS APIs. There's nowhere near that API support on the web platform at the moment. Also Qt might not be using the full capabilities of the web platform in this first release. Naturally, the first results are crude. But Qt has a great platform abstraction mechanism, so I'm sure it will only improve over time, either making better use of existing web APIs or support new ones as they become available.

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.

> there's no way for Qt to leverage user fonts if it keeps on using that strategy.

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.

No disrespect intended, but not all worlds are the same.

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.

Many of those native developers are actually full stack developers that have seen both sides of the fence across several jobs.

> Oof - the point of WebAssembly is not to stick your entire UI in Canvas.

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.

> Accessibility has really nothing to do with Canvas, i.e. with the API used to draw your pixels.

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.

HTML is not an accessibility API, it's a document mark up language.

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.