Oof - the point of WebAssembly is not to stick your entire UI in Canvas.
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.
> 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.
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.
> 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.
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.
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.
> 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:
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.
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.
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?
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.
> 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.
If we want to tackle black boxes, the problem isn't so much WebAssembly as it is Canvas itself. As to whether the benefits of that outway the problems it introduces... eh, people can decide that for themselves.
Not to diminish what you're saying because I agree with you, but I'm less upset about malicious site operators (they could always have been doing this even before WebASM) and more concerned about the beginner (or advanced) programmer that's looking at this thinking, "sweet, I can write my app in Qt, hit an export button, and everything will magically just be fine."
Honestly, I'm not even upset at that developer - they should be able to just hit a button and have it magically work.
I'm upset that Qt isn't rendering any of their stuff to the DOM. CSS is good enough to handle this nowadays, it can't possibly be easier to write their own rendering engine from scratch than it would be to just use the tools that are already built into every browser.
They should be using Canvas only as a fallback when nothing else will work.
It probably is easier to write their own rendering engine because, sadly, they've already have done it - for quite some time now, instead of using any native drawing functionality Qt renders the entire window contents in a pixel buffer and dumps that to a native toplevel window (FWIW GTK+ 3 and later do the same thing). In this case all they have to do is dump the pixel buffer to the canvas instead.
If the web had decent components for apps with a consistent look, behavior and data model across browsers, perhaps this is how things could be. Fact is, after 38 (!) years HTML does not have a data list component that works well (what I mean is [1], something that I could put 10.000+ items in and expect to work. Something useful). I don't know about you but I'm not even 38 years old, so given that people are starting talking to me about midlife crisis, implying I'm about halfway to death by natural causes, I think at this point I should conclude I will be dead before the web will have basic usable working components.
Also I hate the totally inconsistent look of the components we do have. I mean anything I make on linux or windows is close to intolerable on mac. Which is, of course, why all designers totally avoid them and instead just totally redesign everything from scrollbars to buttons.
The web is ... decent ... for what are essentially slide handouts ("websites"). Let's start making some real applications now.
> it can't possibly be easier to write their own rendering engine from scratch
Did you know that the original rendering engine of webkit & blink, khtml, was Qt's ? Besides, the platform abstraction that allows to use Qt on top of WASM is less than 3k lines of code - everything else is the same whether you're on windows, mac, whatever.
I'm on macOS and unfortunately it doesn't seem to support many of the native platform's hotkeys, nor does scrolling work with a trackpad. But it's still a really impressive feat, hopefully they can continue improving on it!
The basic ones look fine to me. It even opens the emoji keyboard (although input then doesn't work). Considering it's a cross-platform widget toolkit running in a cross-platform sandbox (the browser, Firefox here), it's actually pretty good.
So the question is can I run the demo Qt browser in webassembly in my browser? Then I could write my html and not have to worry about which end user browser it runs on as long as the end user browser supports webassembly ;)
On macOS safari shows a hint “this webpage is using significant energy. Closing it may improve the responsiveness of your mac”. And the app is using 100% of time on a core, apparently.
One tradeoff of this is that the text smoothing is wrong (or at the very least, inconsistent with everything else on my computer, and does not respect my text smoothing settings). Personally I hope this "screw the OS, I'm rendering everything myself" strategy doesn't take off on account of that.
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.
There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system. Keep in mind though that editor demo is just one of already existing Qt's examples shown working inside the browser. I don't think any author of Qt based text editor will get excited that it will now be able to run inside the browser. However, there are plenty of other use cases that can actually get one very excited - for me personally the biggest deal is having Qt Quick working in the browser.
> There is no way for any toolkit that's doing its rendering in WebAssembly to match font rendering with your operating system.
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?
Then it wouldn't be "doing its rendering in WebAssembly". Even if you use that term very broadly, at the moment WebAssembly can't even interact with the DOM without going through JavaScript.
WebAssembly is pretty orthogonal to rendering. The way this would be "fixed" is for WASM to have its own DOM APIs; then, WASM apps could render to the DOM like any other web app, so they would inherit all of its benefits (like native font rendering, OS-native input elements, accessibility, etc).
This would only work if DOM rendering is compatible with Qt's internal API. For example, if rendering in Qt is like drawing on a canvas, where you can later read out pixel-values, then this isn't going to work through the DOM. And it could require a lot of tricks to bring the two APIs together.
Electron uses platform-native font rendering. It's just Chromium, and Chromium uses Uniscribe on Windows and CoreText on Mac. Compare Chrome on Windows and Mac, you'll see the difference in text rendering.
Nobody cares. Developers use Electron because it gives consistent results across platforms, not because it looks native. If Chromium were to switch to a custom font renderer that looks exactly the same on all platforms, no developer using Electron would care - in fact, they would probably like it even more.
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.
Yes and no. My biggest gripe with Electron is that it tends to murder battery life. It still gives you native text rendering, and it gives you native menubars which have some options if not always as many as I'd like. At least there's not a fake menubar at the top of the window.
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.
It's a lot less responsive than something like WordPad, which has a comparable feature set. All those extra text features that most WYSIWYG editors add do actually add up, especially common programmer features like syntax highlighting.
VS Code also uses canvas elements for their terminal. I suspect we'll see VS Code (and perhaps Atom as they mentioned it somewhere) moving the main editor window to canvas as well.
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.
Really?
HTML/JS editors based on the standard contentEditable attribute seem as responsive to me (and they don't break basic browser features like scrolling)
I think the plan would be to eventually render a QML based interface on a webgl canvas, which in theory would have a better performance than a DOM based interface.
I'm not an expert but maybe a case can be made that a lightweight rendering engine on WebAssembly can be faster than C++ DOM rendering engine which needs to support lots of legacy stuff.
There's also https://qmlweb.github.io/, which renders QML into a DOM tree. Which will probably never be a full-featured an implementation as QML as one painting onto canvas, but is a lot more web-native.
Initial prototype aside, I wonder how married the Qt team is to the canvas approach.
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).
After 5 seconds of looking at it, I'm noticing that my scroll wheel doesn't work and that typing in Hebrew results in Unicode boxes. Meaning, it is acting different enough from my browser that I'm noticing it.
People argue that we will just block ads at the transport level, but I don't see why the site won't just add an extra hop and serve the ads from their server.
There has always been a steady stream of innovations on the web that have pushed the edge of what was possible.
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.
At one time Java, Flash, Silverlight, etc. would all run without user confirmation/interaction. User confirmation was only introduced when security problems became an issue.
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.
> 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.
That's true... but my point was that WebAssembly (including asm.js) now provides what Flash and Java provided previously -- a portal to run non-JS code at near-native speeds.
This has been tried, and it failed. The primary problem was that startup time of embedded Java applets was abysmally slow. You'd watch the "java loading..." progress bar in the browser window and wait for several seconds before it would finally start. Flash may have gotten its name because it had an incredibly faster startup time than Java.
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.
By default, both Firefox and Chrome use the ANGLE layer to render WebGL draw calls under Windows. ANGLE is an implementation of the OpenGL ES 2.0 specification that is hardware-accelerated via Direct3D 9. So native OpenGL is not even used on Windows. I'm sure that it's possible to achieve something similar with Metal.
It seems like writing one OpenGL to Vulkan converter to rule them all would be the best solution. It would allow GPU vendors to focus on optimizing the much smaller and performant Vulkan
engine and would probably reduce driver size by a couple orders of magnitude.
WebGL (which is what QT's OpenGL targets) will continue to be supported for the foreseeable future, whether in Safari, or via custom implementations in Chrome or Firefox.
Nothing, WebGL doesn't require OpenGL as implementation, in fact browsers on Windows and game consoles use other 3D APIs.
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.
I have no experience with either of these. I read this as "that framework which makes native applications for most major platforms now targets the web browser".
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?
People who think that just because it's in C++ it's harder than the average web app to write, and lack of ability to deploy e.g. on macos without owning a mac or windows without having a windows partition (though there are solutions, but nothing as easy as what electron proposes).
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.
C++ is arguably one of the most complex popular programming languages out there. With Qt you get a lot of conveniences and built-in magic, but I'd say at that point it's not really regular C++. A good comparison could be writing plain Ruby vs writing a Rails app.
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.
> With Qt you get a lot of conveniences and built-in magic, but I'd say at that point it's not really regular C++.
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.
Probably neither -- I'd wager that Electron's popularity among web-centric companies is due to the prevalence of JavaScript programmers in these shops. With Electron there is no need to hire anyone new (or eat the cost of programmers retooling) to roll out a desktop app.
I have no idea about other platforms, but on Linux it's extremely easy to set up a cross-compilling environment for building macOS, Windows and Android applications. I'm not exactly sure if I want to have the applications I use be written by people who can't even bother to do one-time setup of their compiler toolchains if there's no ready-made script on GitHub that does it automatically, like there are for Electron.
I have a Qt app and don't have a mac. Can you point me to where I can create the self-contained dmg or app file w/ all the icons and such on Linux that works on mac? I am familiar w/ Qt's mac tooling that is only shipped with the mac install, but if "it's extremely easy" on Linux, I'd really like to know.
https://github.com/tpoechtrager/osxcross for the compiler and libraries. You might be even able to simply install Qt there using MacPorts, so no manual compiling or unpacking the SDKs into osxcross's rootfs should be needed. A properly configured CMake project will make an .app file for you automatically (although if you'll want to bundle dependencies as dynamic libraries instead of using frameworks, you might have to fix linking paths with a script like https://gist.github.com/artm/3668431 - that was the hardest thing to figure out for me)
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"
It's likely enough that such a statement will be considered void when tested in EU court (as you can safely reverse engineer software for interoperability purposes) that I don't care.
> (as you can safely reverse engineer software for interoperability purposes)
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'm afraid this doesn't replicate macdeployqt. There are many quirks that are not being taken into account here. My Qt app does not use cmake, it uses qmake. I have certain static compilation needs. Also, I said I didn't have a mac, so how do I get the OSX SDK? Your original statement about "extremely easy" is clearly false (you even mentioned a "hardest thing" which is custom per-OS scripting). I hope it's clear that this is why Electron is popular. I don't see how this can be seen as extremely easy from anyone's perspective and it's the mindset that drives people towards Electron.
That's exactly what I mentioned in my first comment. There are some hops to take, but nothing that could actually stop any competent developer.
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.
cross-compiling isn't the major issue. It's the toolkit. Yeah a cross-compiling C/C++ environment is fairly straightforward to do especially if you just want to do a commandline utility that can be done with the C or C++ standard library. But having any sort of GUI toolkit (such as Qt).
how would it work on macos ? If you have graphical apps you have to link against the various Cocoa frameworks, and those are (legally) only available on mac machines
How fundamentally different would that be from what Flash or Java were doing? You lose HTML/CSS as your universal, open GUI on the web with all it's built-in advantages (SEO, hyperlinking, accessibility) in favor of some byte-compiled GUI using canvas to draw itself.
In theory it is more secure than Flash and "more open". Flash was bad because it was a security nightmare even "sandboxed" and the player was closed source. Nothing prevents either ActionScript or Java from compiling to web assembly though. Flash API are close to Web API so Flash could absolutely export to WASM. Now is Adobe interested in this is the question.
Webasm is not limited to a contained program that only draws to the canvas. It is meant to be able to do computations at near native speeds and be called from javascript.
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.
> 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.
The parent question was about how webasm is different from Flash and Java. The answer is that it is fully integrated with javascript and only does what javascript already does, but with faster execution, faster parsing, and smaller file sizes.
'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.
> what stops QT from taking over all multi-platform targeted applications
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.
Having recently made a website with a non-trivial layout that required lots of ugly JS to implement adequate scaling and bevavior, boy, I can't disagree more. I do UI in QML in $dayJob and gained a whole new appreciation for how much simpler and faster it is to achieve similar results in a more consciously crafted language.
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 ... :-)
Are you really comparing your professional expertise with something you've just started to learn for your wedding website?
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 ?
I see your point, but no. I've made websites semi-regularly since the late 90s and have contributed to a browser engine, so it's not lack of familiarity. This was just the first site in a few years. I think my argument takes rustyness/routine into account.
Now QML has its warts for sure, but it benefits from being designed with well-known use cases in mind, so it has lots of features suitable to them.
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.
> 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.
Try writing something as simple as a dialog in Qt. It all makes sense, you subclass a QDialog, instantiate it and show it.
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.
I'm so sorry that a little bit of HTML and JavaScript reminds you and other commenters under my post of web developer's Old Browser nightmares and brave endeavors of satisfying 100% of Web users at any the cost, but we're talking about Electron which ships a quite recent version of Chromium :-)
`confirm()`, `alert()`, `prompt()` and similar are widely regarded as mistakes. Including them on your new Electron app isn't something you should be doing in the first place.
Your Electron version is old; if you're shipping it, you're probably putting your users at risk due to security issues in them. Check the latest versions here: https://electronjs.org/releases
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 …
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.
Orders of magnitude easier than C++? Please. C++ at least done Qt style really isn't that bad, it took me a few hours to get up and running with a reasonable Qt setup at work and start a project, when I had to do the same for electron I spent nearly a week mucking with gulp, babel, react and reading about which packing solution I should use, if I want to use TypeScript or Flow and if I can integrate them with the libraries I need to work with...
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.
C++ is used by most games and widely used in embedded computing, often with Qt. All major HTML engines are written in C++, too. You seem to be confusing your immediate environment with the world.
> 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.
> 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++
if you're having a hard time doing modals and layouts with html and css you should perhaps start over and try grasping the core concepts. this system, unlike qt, is about separation of concerns, so structure and presentation are defined separately. far from a clusterfuck, it's actually a very good idea. if you are having a hard time finding non-crap libraries, then build your own pile of shit library. at least there are plenty of choices to pick from. it's called an ecosystem and it, unfortunately, is what you people don't have.
No... Leaving aside your opinion that Electron is easier, Electron forces an unsolvable problem on you - the performance of the app is horrible. A bare bones nothing Electron app idles using 150mb ram and has a huge binary size, all 25 million lines of chromium and nodejs. And Javascript is slow and not designed for application programming.
You're not responding to my point though? I have a slow laptop, and I cant run Electron apps. If I run a Qt app, it runs beautifully. Would people use VLC if it was made in Electron? No.
Not everybody has a slow laptop. And while people wax how computers from 80s were booting in 2 seconds and everything was lightning fast compared to the bloated software of today, there doesn't seem to be much of a movement towards ditching todays computers and going back to Windows 95 and Mac OS 9.
Hackery*, and I'm not sure why the hate towards CSS3. With a few lines of code I can build a pretty good looking responsive UI that doesn't take hours to polish.
I'd give my left toe to learn to do this in a few lines of code in HTML/CSS3.
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.
Is pixel perfect UI really what you even want these days? With high-DPI screens and screen scaling being a thing, not everyone's pixels are the same. And that's not even talking about accessibility for people with low vision who want text to be big and readable.
«native frameworks» => if you want a true native framework, you need one specific development per platform. Or more realistically, you end up developing for Windows only, unless you target a specific niche where MacOS is somewhat relevant, and never Linux.
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.
> Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers […], than experienced C++ developers
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?
I think, this goes way beyond just companies preferring to hire cheaper developers and beyond software engineering as such. There is a larger, universal force at play here. Examples of poorly designed, engineered and built things are everywhere in the world. It is seemingly cheaper to do it this way. But what may be saved upfront on production quality, is usually spent many times over on usage, maintenance and subsequent rebuilding, making the total cost higher.
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.
I can also go to craigslist and get someone that does repairs on the side, or pay for someone that costs twice as much but actually does the job only once.
C++ is not C, but is still weakly typed. I think even Rust is weakly typed in unsafe mode (I'm open to correction about that). This makes sense when you think about the CPU which is weakly typed and dynamically typed (it's also dynamically scoped unlike all the modern lexically scoped languages running on top of it).
"weakly typed" is not well-defined, however, I don't think that Rust is, even in unsafe. If you can provide a C or C++ example, I can tell you what that looks like in Rust.
Qt has bindings for many languages, including JavaScript. It's capable of delivering experiences much closer to native than any Electron app I've ever seen. The catch is that a minimum-effort Electron app feels like a web page but a minimum-effort Qt app feels like a bad native app. There are also frameworks like wxWidgets that use actual native controls.
In the year where not all deployment targets are using the latest Chrome and Safari.
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.
So not familiar with the fact that not everyone runs the very latest Chrome or Safari on their desktop computers, and there are other kind of devices on the field?
That's too generous. Even the things that work properly on every browser are usually hacks because HTML and CSS were made for documents rather than applications.
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.
The ultimate irony of course being that Electron was originally a Qt app. KHTML written against Qt by the KDE folks (some of whom turned into Qt folks) -> forked into WebKit by Apple when they needed a browser, using a shim layer to work on Cocoa, which grew into a platform abstraction framework -> forked into Blink, used in Electron. Qt begat its own competitor.
That is a completely different thing. broadwayd is only a display server. Qt for WebAssembly runs in the browser in the same secure javascript sandbox.
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.