7 ms·

This is exactly my point though. It’s not a UI toolkit, but if you want to write applications for the web you have to awkwardly shoehorn it into one. There is n

This is exactly my point though. It’s not a UI toolkit, but if you want to write applications for the web you have to awkwardly shoehorn it into one. There is no alternative. It’s not fit for the purpose of building applications. I strongly support the idea of an alternative.

danShumway 6y ago
> but if you want to write applications for the web you have to awkwardly shoehorn it into one. No, you have to treat it like a render target. You can write your applications with another UI toolkit, you just have to be able to render to DOM. To go back to the terminal analogy, the terminal is the end-user interface. It's not a framework or a toolkit. What you're complaining about isn't that the terminal is a bad UI toolkit, you're just complaining about supporting the terminal in general. > I strongly support the idea of an alternative. The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI. But getting rid of that requirement would be bad for the end user. It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state. It's a user feature, not a developer feature. I mean, I can think of a lot of ways to make web programming easier if we don't care about the format of the end-user UI. It would simplify things dramatically if we didn't need to care about stuff like responsive design or resizable text. But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc... HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first, before they're allowed to think about what the pixels on the screen will look like.
- deergomoo 6y ago
  > To go back to the terminal analogy, the terminal is the end-user interface. It's not a framework or a toolkit. What you're complaining about isn't that the terminal is a bad UI toolkit, you're just complaining about supporting the terminal in general. If I wanted to write something like a high quality drawing tool and my only option was to use the terminal, you’re damn right I would be complaining about it. Now I understand saying “my only option” is somewhat facetious, as if I care about it so deeply, obviously I should just write native software. But we are clearly moving to a web-first future, and I just don’t think the platform is a good foundation for application UI. You’re implying that there’s ultimately no difference between a UI library that renders to HTML and one that renders to a grid of pixels in a native app; I am making the argument that HTML is sufficiently poorly suited for non-document purposes that it drags the overall quality of software down. > The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI That is exactly what I’m suggesting. > It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state Why? I am not convinced there are significant benefits to a text-based format over a binary one, other than ease of reverse engineering. 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. If we’re going to stick with something text based, clear data binding as part of the markup would be much more beneficial imo. Again: I feel the principle holds just fine for documents, but not application UI. > But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc It’s the easiest way to build a web app because it’s the only way to build a web app. And while I will grant you that scraping and adblocking is fairly unique to the web, any “native” UI target worth its salt has great accessibility support. As for responsive layout, how long have we had resizable windows where the contents adapt? This is not something the web pioneered. > HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first I guarantee you that junior developers are not writing accessible web apps without significant effort. Maybe if they start off with something fairly document-like, sure. But once you start adding modals, popovers, and other controls that the browser doesn’t provide, things get difficult to do right pretty quickly.
  - danShumway 6y ago
    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.
- filleduchaos 6y ago
  > It would simplify things dramatically if we didn't need to care about stuff like responsive design or resizable text. ...sincere question, have you ever actually used a native UI SDK?
  - danShumway 6y ago
    Yes. Now, I have not used Flutter in specific, but from what I can see from its documentation, it doesn't support `em` units, so I can't base widths off of the current font size. The recommendations I'm seeing online for doing responsive design are to do device queries for the layout or to do percentage-based box sizes. Again, I haven't used Flutter, so maybe it's better than the online tutorials I'm looking at give the impression of. But I'm having a real hard time imagining how I would recreate the functionality of CSS Grids or Flexbox using that kind of system. Some native frameworks do a much better job. I think GTK is pretty good (although, suspiciously, GTK has ended up copying a lot of CSS features, so take from that what you will). But even there, it's worth noting that the developers behind most of the apps I'm familiar with aren't really taking advantage of modern GTK features. I have an Arch install with the desktop split between a 4K monitor and a normal 1920x1080. I also maintain a Manjaro install on an HDPI Surface laptop with an odd aspect ratio. By and large, the native apps I use are mostly terrible at handling these scenarios. In comparison, most websites I visit are handling weird aspect ratios and 2x scaling pretty well. I'll also give a shoutout to Mac, which I'm not familiar with a developer platform because heck that, but I assume has decent UI frameworks because more of the apps I use on Mac actually handle resizing nicely. In any case, the point I was making was not just that the web is uniquely good at responsive design. Responsive design is one of the easiest problems that the web is solving. Now show me a native toolkit that can match the web at allowing users to override styles or block/replace UI elements. The significant problem that the web is solving is forcing state to be represented in an XML tree. That's the important part, responsive design is just one of the advantages that come from that.
    - dragonwriter 6y ago
      > Now, I have not used Flutter in specific, but from what I can see from its documentation, it doesn't support `em` units, so I can't base widths off of the current font size Can't you just use the fontSize property and multiply it by whatever number you were going to use for ems (or maybe multiply fontSize by textScaleFactor first, depending on how rigorously you want to lock to text.)

danShumway 6y ago

> but if you want to write applications for the web you have to awkwardly shoehorn it into one. No, you have to treat it like a render target. You can write your applications with another UI toolkit, you just have to be able to render to DOM. To go back to the terminal analogy, the terminal is the end-user interface. It's not a framework or a toolkit. What you're complaining about isn't that the terminal is a bad UI toolkit, you're just complaining about supporting the terminal in general. > I strongly support the idea of an alternative. The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI. But getting rid of that requirement would be bad for the end user. It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state. It's a user feature, not a developer feature. I mean, I can think of a lot of ways to make web programming easier if we don't care about the format of the end-user UI. It would simplify things dramatically if we didn't need to care about stuff like responsive design or resizable text. But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc... HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first, before they're allowed to think about what the pixels on the screen will look like.

deergomoo 6y ago
> To go back to the terminal analogy, the terminal is the end-user interface. It's not a framework or a toolkit. What you're complaining about isn't that the terminal is a bad UI toolkit, you're just complaining about supporting the terminal in general. If I wanted to write something like a high quality drawing tool and my only option was to use the terminal, you’re damn right I would be complaining about it. Now I understand saying “my only option” is somewhat facetious, as if I care about it so deeply, obviously I should just write native software. But we are clearly moving to a web-first future, and I just don’t think the platform is a good foundation for application UI. You’re implying that there’s ultimately no difference between a UI library that renders to HTML and one that renders to a grid of pixels in a native app; I am making the argument that HTML is sufficiently poorly suited for non-document purposes that it drags the overall quality of software down. > The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI That is exactly what I’m suggesting. > It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state Why? I am not convinced there are significant benefits to a text-based format over a binary one, other than ease of reverse engineering. 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. If we’re going to stick with something text based, clear data binding as part of the markup would be much more beneficial imo. Again: I feel the principle holds just fine for documents, but not application UI. > But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc It’s the easiest way to build a web app because it’s the only way to build a web app. And while I will grant you that scraping and adblocking is fairly unique to the web, any “native” UI target worth its salt has great accessibility support. As for responsive layout, how long have we had resizable windows where the contents adapt? This is not something the web pioneered. > HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first I guarantee you that junior developers are not writing accessible web apps without significant effort. Maybe if they start off with something fairly document-like, sure. But once you start adding modals, popovers, and other controls that the browser doesn’t provide, things get difficult to do right pretty quickly.
- danShumway 6y ago
  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.
filleduchaos 6y ago
> It would simplify things dramatically if we didn't need to care about stuff like responsive design or resizable text. ...sincere question, have you ever actually used a native UI SDK?
- danShumway 6y ago
  Yes. Now, I have not used Flutter in specific, but from what I can see from its documentation, it doesn't support `em` units, so I can't base widths off of the current font size. The recommendations I'm seeing online for doing responsive design are to do device queries for the layout or to do percentage-based box sizes. Again, I haven't used Flutter, so maybe it's better than the online tutorials I'm looking at give the impression of. But I'm having a real hard time imagining how I would recreate the functionality of CSS Grids or Flexbox using that kind of system. Some native frameworks do a much better job. I think GTK is pretty good (although, suspiciously, GTK has ended up copying a lot of CSS features, so take from that what you will). But even there, it's worth noting that the developers behind most of the apps I'm familiar with aren't really taking advantage of modern GTK features. I have an Arch install with the desktop split between a 4K monitor and a normal 1920x1080. I also maintain a Manjaro install on an HDPI Surface laptop with an odd aspect ratio. By and large, the native apps I use are mostly terrible at handling these scenarios. In comparison, most websites I visit are handling weird aspect ratios and 2x scaling pretty well. I'll also give a shoutout to Mac, which I'm not familiar with a developer platform because heck that, but I assume has decent UI frameworks because more of the apps I use on Mac actually handle resizing nicely. In any case, the point I was making was not just that the web is uniquely good at responsive design. Responsive design is one of the easiest problems that the web is solving. Now show me a native toolkit that can match the web at allowing users to override styles or block/replace UI elements. The significant problem that the web is solving is forcing state to be represented in an XML tree. That's the important part, responsive design is just one of the advantages that come from that.
  - dragonwriter 6y ago
    > Now, I have not used Flutter in specific, but from what I can see from its documentation, it doesn't support `em` units, so I can't base widths off of the current font size Can't you just use the fontSize property and multiply it by whatever number you were going to use for ems (or maybe multiply fontSize by textScaleFactor first, depending on how rigorously you want to lock to text.)