5 ms·

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

by alxlaz 8y ago

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

martin_ky 8y ago
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.
- danShumway 8y ago
  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.
danShumway 8y ago
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.

by alxlaz 8y ago

martin_ky 8y ago

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.

danShumway 8y ago
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.

danShumway 8y ago

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.