4 ms·

It's worth pointing out, there is an escape hatch on the web: Canvas. Canvas isn't the default because most apps don't need that escape hatch -- I will make a

It's worth pointing out, there is an escape hatch on the web: Canvas. Canvas isn't the default because most apps don't need that escape hatch -- I will make a strong claim that the majority of native apps are just interactive documents and could easily represent their states in XML. I will make a stronger claim that the majority of native apps that require pixel-level control workarounds only need them for a couple of sections of the app, and the surrounding interface is just an interactive document. If you're building a drawing app, yes, you need an pixel buffer that you can render to. But the rest of your menus and main interface are probably just XML. This is another hill I'm willing to die on; application UI isn't special. Yes, having some control over stuff like Canvas is important. And there are categories of apps like games that genuinely don't fit into a document model. But for the most part people should be able to represent their state as a plain-text interface, it's kind of weird to me if they can't. For the most part, most application UI state is not that complicated. > I would also argue that HTML doesn’t represent your current state, it represents the state when the page loads. That state is then modified, often in a rather opaque manner, by JavaScript. The Javascript is not important. When that state gets modified, it gets rendered to the DOM. The idea behind the web, even for web-apps, is that if you open the inspector in your browser, that should be the current user-facing state at that specific moment. > Why? I am not convinced there are significant benefits to a text-based format over a binary one other than ease of reverse engineering The only way a screenreader works is by reading your interface out loud. If your interface can't be entirely represented as a series of words, then how are you making it accessible? The browser forcing you to target text (Canvas aside) is important because it means the text interface and visual interface can't be separated. That makes it harder for you to split your app into two separate interfaces that might diverge in features and abilities. By default, the functionality you offer is available to everyone, even users who aren't consuming your app using the visual interface. As a side note, I think ease of reverse engineering is a big deal that shouldn't be discounted. We should be trying to make it easier to reverse engineer native apps. > how long have we had resizable windows where the contents adapt? Then why haven't native developers found out how to do it yet? Why do all of the Linux apps I run have terrible HDPI support? Why has it taken us so long to get something incredibly simple and straightforward like fractional scaling working on the Linux desktop? > But once you start adding modals, popovers, and other controls that the browser doesn’t provide, things get difficult to do right pretty quickly. Well... use a framework for that. Use a React modal, they'll be accessible. The point I've been getting at is that you shouldn't think of HTML as the thing you write your app in, you should think of HTML/DOM as the thing your app renders to. It's fine to use a UI toolkit on top of that, in the same way that it's fine to use a framework that runs on top of something like X11. The browser doesn't provide popovers and modals for the same reason that OpenGL doesn't provide those things. Browser elements are primitives, they just happen to be easy enough to use that you could theoretically target them directly. Junior developers don't need to write advanced popovers, and the goal isn't to force them to do that. It's to provide a common set of user-accessible elements that advanced popovers are built out of, regardless of what UI toolkit you're using.

deergomoo 6y ago
The problem with canvas is that being purely graphical, it's too far in the opposite direction—it's just a bitmap. It's akin to shipping a native app where the UI is just a JPEG that matches clicks on a co-ordinate with actions. The sweet spot is somewhere in between. > The idea behind the web, even for web-apps, is that if you open the inspector in your browser, that should be the current user-facing state at that specific moment. There's absolutely nothing there that requires UI to be delivered as a textual XML tree to work. The browser will end up rendering a tree of nodes regardless of its representation, and there's no reason that can't be inspected. For example, in Xcode I can pause execution of an iOS app and poke around the view stack to see what's going on. > The only way a screenreader works is by reading your interface out loud. If your interface can't be entirely represented as a series of words, then how are you making it accessible? As above. I'm not suggesting we render text by blasting pixels into a bitmap; with this imaginary alternative to HTML we would still tell the browser to render some text, which can then expose the necessary accessibility hooks. Again look to iOS; it has arguably best-in-class accessibility support. > That makes it harder for you to split your app into two separate interfaces that might diverge in features and abilities. By default, the functionality you offer is available to everyone, even users who aren't consuming your app using the visual interface. If I'm honest I'm not sure what you mean here, can you clarify? > As a side note, I think ease of reverse engineering is a big deal that shouldn't be discounted. We should be trying to make it easier to reverse engineer native apps. Agreed. > Then why haven't native developers found out how to do it yet? Why do all of the Linux apps I run have terrible HDPI support? Why has it taken us so long to get something incredibly simple and straightforward like fractional scaling working on the Linux desktop? ¯\_(ツ)_/¯ Lack of interest? Lack of commercial incentive? HiDPI works flawlessly on macOS and has for years. Not to mention that the web doesn't really fix that problem. If the browser was poorly written and had bad HiDPI support, then so would all your web apps. > The point I've been getting at is that you shouldn't think of HTML as the thing you write your app in, you should think of HTML/DOM as the thing your app renders to Okay, I'm really not disagreeing with you here. My argument is that HTML/DOM as a render target is annoyingly limited in many small ways that waste developer time and create a worse overall product. > The browser doesn't provide popovers and modals for the same reason that OpenGL doesn't provide those things. Browser elements are primitives, they just happen to be easy enough to use that you could theoretically target them directly I don't think this argument stands up at all. Does OpenGL provide form inputs? Buttons? Semantic content regions? The crux of my argument is that HTML elements are neither primitive nor flexible enough to be a good basis for UI frameworks, nor rich enough to not require UI toolkits. It's stuck in between, which is why I called it a lame UI toolkit to begin with. I fear you may think I'm arguing in favour of something I'm not. I don't think we should be replacing web apps with a big list of drawing instructions, I'm merely saying there are a lot of things that have been par for the course in GUIs for 20-30 years that are significantly harder than they should be to achieve with HTML+CSS. I mean hell, I don't really care if some alternative platform is text-based or not, I just think text has minimal benefits and binary would be more efficient.

deergomoo 6y ago

The problem with canvas is that being purely graphical, it's too far in the opposite direction—it's just a bitmap. It's akin to shipping a native app where the UI is just a JPEG that matches clicks on a co-ordinate with actions. The sweet spot is somewhere in between. > The idea behind the web, even for web-apps, is that if you open the inspector in your browser, that should be the current user-facing state at that specific moment. There's absolutely nothing there that requires UI to be delivered as a textual XML tree to work. The browser will end up rendering a tree of nodes regardless of its representation, and there's no reason that can't be inspected. For example, in Xcode I can pause execution of an iOS app and poke around the view stack to see what's going on. > The only way a screenreader works is by reading your interface out loud. If your interface can't be entirely represented as a series of words, then how are you making it accessible? As above. I'm not suggesting we render text by blasting pixels into a bitmap; with this imaginary alternative to HTML we would still tell the browser to render some text, which can then expose the necessary accessibility hooks. Again look to iOS; it has arguably best-in-class accessibility support. > That makes it harder for you to split your app into two separate interfaces that might diverge in features and abilities. By default, the functionality you offer is available to everyone, even users who aren't consuming your app using the visual interface. If I'm honest I'm not sure what you mean here, can you clarify? > As a side note, I think ease of reverse engineering is a big deal that shouldn't be discounted. We should be trying to make it easier to reverse engineer native apps. Agreed. > Then why haven't native developers found out how to do it yet? Why do all of the Linux apps I run have terrible HDPI support? Why has it taken us so long to get something incredibly simple and straightforward like fractional scaling working on the Linux desktop? ¯\_(ツ)_/¯ Lack of interest? Lack of commercial incentive? HiDPI works flawlessly on macOS and has for years. Not to mention that the web doesn't really fix that problem. If the browser was poorly written and had bad HiDPI support, then so would all your web apps. > The point I've been getting at is that you shouldn't think of HTML as the thing you write your app in, you should think of HTML/DOM as the thing your app renders to Okay, I'm really not disagreeing with you here. My argument is that HTML/DOM as a render target is annoyingly limited in many small ways that waste developer time and create a worse overall product. > The browser doesn't provide popovers and modals for the same reason that OpenGL doesn't provide those things. Browser elements are primitives, they just happen to be easy enough to use that you could theoretically target them directly I don't think this argument stands up at all. Does OpenGL provide form inputs? Buttons? Semantic content regions? The crux of my argument is that HTML elements are neither primitive nor flexible enough to be a good basis for UI frameworks, nor rich enough to not require UI toolkits. It's stuck in between, which is why I called it a lame UI toolkit to begin with. I fear you may think I'm arguing in favour of something I'm not. I don't think we should be replacing web apps with a big list of drawing instructions, I'm merely saying there are a lot of things that have been par for the course in GUIs for 20-30 years that are significantly harder than they should be to achieve with HTML+CSS. I mean hell, I don't really care if some alternative platform is text-based or not, I just think text has minimal benefits and binary would be more efficient.