4 ms·

Even layout aside (I'm hoping Houdini will eventually bring some form of constraint-based layout to browsers), HTML is the lamest UI toolkit going. We've got a

Even layout aside (I'm hoping Houdini will eventually bring some form of constraint-based layout to browsers), HTML is the lamest UI toolkit going. We've got a handful of basic form inputs, incredibly inflexible tables, and some semantic rectangles. That's basically it. Even the form inputs can be a pain. It's insane to me that the only way to change the background colour of a checkbox is to hide it and build your own with CSS hacks (pseudo-elements etc.). I guess the fact that any element needs to function purely from markup without any code severely hampers them, but I can't believe how much time we're all wasting having to build things as basic as pop-out menus by hand.

danShumway 6y ago
> HTML is the lamest UI toolkit going I will die on this hill. HTML is not a UI toolkit or an SDK. It is a user-facing interface. I know it gets presented as a toolkit, I know that on some level it overlaps with a toolkit/layout language. But the most important thing HTML does is it provides a plain-text user-facing interface for an app. Complaints like this are kind of like arguing that the terminal is a bad layout tool. I guess? But many of the things that would make the terminal into a better layout tool would get in the way of forcing developers to provide a pure-text interface for their apps. In the same way, many of the features people want to pull into HTML (data-bindings for tables, content reflow between arbitrary elements, arguably a lot of the custom element/template work that Google is doing) are kind of counterproductive once you start looking at HTML as an interface instead of as a programming tool.
- deergomoo 6y ago
  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.
Vrondi 6y ago
Somebody is showing their ignorance of what HTML is.
- deergomoo 6y ago
  I know exactly what HTML is, I’m just not happy that we have to use it for something it’s very obviously not suitable for.

danShumway 6y ago

> HTML is the lamest UI toolkit going I will die on this hill. HTML is not a UI toolkit or an SDK. It is a user-facing interface. I know it gets presented as a toolkit, I know that on some level it overlaps with a toolkit/layout language. But the most important thing HTML does is it provides a plain-text user-facing interface for an app. Complaints like this are kind of like arguing that the terminal is a bad layout tool. I guess? But many of the things that would make the terminal into a better layout tool would get in the way of forcing developers to provide a pure-text interface for their apps. In the same way, many of the features people want to pull into HTML (data-bindings for tables, content reflow between arbitrary elements, arguably a lot of the custom element/template work that Google is doing) are kind of counterproductive once you start looking at HTML as an interface instead of as a programming tool.

deergomoo 6y ago
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.

Vrondi 6y ago

Somebody is showing their ignorance of what HTML is.

deergomoo 6y ago
I know exactly what HTML is, I’m just not happy that we have to use it for something it’s very obviously not suitable for.