4 ms·

The point is that you didn't need DOM. You had a canvas to draw things on and to handle clicks in. Now you need the DOM either way and it's cumbersome. It feels

The point is that you didn't need DOM. You had a canvas to draw things on and to handle clicks in. Now you need the DOM either way and it's cumbersome. It feels like trying to build a UI in a word processor. Text nodes are such a terrible idea...

discreteevent 4y ago
Exactly. When I first did a web front end it felt exactly like customising MS Word with VBA. No matter what you put on top of it the roots poke their heads through and it feels like a mess.
- grishka 4y ago
  Yes, yes. Flash (with AS3) was a first-class web application platform. There were buttons and views and "movie clips" and other stuff for you to place on a blank canvas, all very customizable. Then there was Flex, a full-fledged yet relatively lightweight application framework built on that foundation. You created your layouts with XML, with live preview. There were Android-like layout containers (emulating Android's LinearLayout with HTML+CSS is still not quite trivial in 2022 — the defaults on flexbox are bonkers) and there were ListView/(UI|NS)CollectionView-style lists with reusable cells, among other things. This was 15 years ago! I can't even begin to imagine how many workarounds one would need to implement a list with reusable cells with HTML+JS even if targeting only the latest Chrome and Firefox. HTML is a document format at its heart and there's no getting around that, but <object> is/was a nice escape hatch.
rektide 4y ago
Having a hypermedia standard is universes more interesting & powerful & enriching than what boils dowm to a way to generate gifs. Computers have dozens of ways to throw pixels at peoplecs faces and none of them are remarkable or particularly noteable. Having a DOM, having structure, having a hypermedium is a source of immense potential & power. For both developer, but also, capitally & uniquely, for users too. This longer top-commemt talks some to why documents, why hypermedia is enriching: https://news.ycombinator.com/item?id=31373988 https://news.ycombinator.com/item?id=31373988
- DeathArrow 4y ago
  >Having a DOM, having structure, having a hypermedium is a source of immense potential & power. For documents, yes. For apps those are obstacles. Apps just need something to draw on.
  - rektide 4y ago
    Your statement doesnt resemble any gui toolkits Im familiar with. Not Flutter, not Swift, not Gnome, nothing. The DOM closely resembles other ui construction systems & has similar ideas lile event handling. And then the pretense that developers are the only thing that matter. The web is vastly better than apps because of the dom, because our systems are in a malleable hypermedia that ysers can modify eith userscripts, userstyles, extensions, eith whatever manner of accessible browser/user agent they please. It's such sad thing to hear people advocating so strongly for the winnowing od possibility. Leaving all responsibility & all power with the app developer sounds perverse to me, sick, unworthy of being called a part of the internet. Not only does "just need something to draw on" not reflect the needs of developers, it represents an mortal threat to user agency.
    - grishka 4y ago
      The very big difference between the web and a proper GUI toolkit is that in GUI toolkits, inline elements aren't a thing, period. Text nodes also aren't a thing and don't mess up your layout when you least expect it (argh). You need to explicitly create a "text view" or label of some sort to display text. GUI toolkits also usually offer layout algorithms that make sense for GUIs. Oh and did I mention that they have sane defaults like not insisting on using the intrinsic sizes of things unless you explicitly tell them to? Another property GUI toolkits have that the web lacks is that the GUI toolkit is usually made of the exact same kind of code you're writing your app in. There's a much tighter integration between the app and the toolkit. The app can extend it much more sensibly by, for example, implementing custom layout algorithms. With the web, there's this issue of the browser implementing all the layout and drawing and doing all the work and you can only provide input parameters to these hard-wired algorithms — you can't build your own. Yes, I'm aware of those layout and paint worklets being worked on. Yes, they solve some of these problems and thankfully move the web platform closer to feature-completeness. It's still a mess though.
MrJohz 4y ago
You still have the canvas, and it's perfectly easy to draw on that and handle events in JavaScript. There are a number of applications that work that way. That said I disagree with the idea that using the DOM is bad - I suspect it's cumbersome to you mainly because you're not used to it. The number one benefit of the DOM is that user-facing controls are largely consistent. If I want the user to type text into a text box, I can just use a browser-defined element, and the user will be able to interact with that exactly as they expect. I don't need to reimplement the whole text input and display process, because it already exists in the platform. The same goes for all sorts of controls and interactions, from zooming to select boxes. Moreover, assuming this DOM is built up in a way where the semantics are embedded in the elements themselves, then it can also be used in different ways. One user might use their browser to render the DOM into something that can see on their screen, while another might use their browser to read the element contents aloud. One person might use their mouse to interact with the system while another might use their keyboard. Accessibility is built into every application built using the DOM - it may not be ideally presented in some situations, and it's still possible to get things wrong, but by default a blind user will at least have a chance of using the system. In contrast, a canvas-based application will need to reimplement accessibility from the ground up (usually in the form of a secondary hidden DOM tree).

discreteevent 4y ago

Exactly. When I first did a web front end it felt exactly like customising MS Word with VBA. No matter what you put on top of it the roots poke their heads through and it feels like a mess.

grishka 4y ago
Yes, yes. Flash (with AS3) was a first-class web application platform. There were buttons and views and "movie clips" and other stuff for you to place on a blank canvas, all very customizable. Then there was Flex, a full-fledged yet relatively lightweight application framework built on that foundation. You created your layouts with XML, with live preview. There were Android-like layout containers (emulating Android's LinearLayout with HTML+CSS is still not quite trivial in 2022 — the defaults on flexbox are bonkers) and there were ListView/(UI|NS)CollectionView-style lists with reusable cells, among other things. This was 15 years ago! I can't even begin to imagine how many workarounds one would need to implement a list with reusable cells with HTML+JS even if targeting only the latest Chrome and Firefox. HTML is a document format at its heart and there's no getting around that, but <object> is/was a nice escape hatch.

rektide 4y ago

Having a hypermedia standard is universes more interesting & powerful & enriching than what boils dowm to a way to generate gifs. Computers have dozens of ways to throw pixels at peoplecs faces and none of them are remarkable or particularly noteable. Having a DOM, having structure, having a hypermedium is a source of immense potential & power. For both developer, but also, capitally & uniquely, for users too. This longer top-commemt talks some to why documents, why hypermedia is enriching: https://news.ycombinator.com/item?id=31373988 https://news.ycombinator.com/item?id=31373988

DeathArrow 4y ago
>Having a DOM, having structure, having a hypermedium is a source of immense potential & power. For documents, yes. For apps those are obstacles. Apps just need something to draw on.
- rektide 4y ago
  Your statement doesnt resemble any gui toolkits Im familiar with. Not Flutter, not Swift, not Gnome, nothing. The DOM closely resembles other ui construction systems & has similar ideas lile event handling. And then the pretense that developers are the only thing that matter. The web is vastly better than apps because of the dom, because our systems are in a malleable hypermedia that ysers can modify eith userscripts, userstyles, extensions, eith whatever manner of accessible browser/user agent they please. It's such sad thing to hear people advocating so strongly for the winnowing od possibility. Leaving all responsibility & all power with the app developer sounds perverse to me, sick, unworthy of being called a part of the internet. Not only does "just need something to draw on" not reflect the needs of developers, it represents an mortal threat to user agency.
  - grishka 4y ago
    The very big difference between the web and a proper GUI toolkit is that in GUI toolkits, inline elements aren't a thing, period. Text nodes also aren't a thing and don't mess up your layout when you least expect it (argh). You need to explicitly create a "text view" or label of some sort to display text. GUI toolkits also usually offer layout algorithms that make sense for GUIs. Oh and did I mention that they have sane defaults like not insisting on using the intrinsic sizes of things unless you explicitly tell them to? Another property GUI toolkits have that the web lacks is that the GUI toolkit is usually made of the exact same kind of code you're writing your app in. There's a much tighter integration between the app and the toolkit. The app can extend it much more sensibly by, for example, implementing custom layout algorithms. With the web, there's this issue of the browser implementing all the layout and drawing and doing all the work and you can only provide input parameters to these hard-wired algorithms — you can't build your own. Yes, I'm aware of those layout and paint worklets being worked on. Yes, they solve some of these problems and thankfully move the web platform closer to feature-completeness. It's still a mess though.

MrJohz 4y ago

You still have the canvas, and it's perfectly easy to draw on that and handle events in JavaScript. There are a number of applications that work that way. That said I disagree with the idea that using the DOM is bad - I suspect it's cumbersome to you mainly because you're not used to it. The number one benefit of the DOM is that user-facing controls are largely consistent. If I want the user to type text into a text box, I can just use a browser-defined element, and the user will be able to interact with that exactly as they expect. I don't need to reimplement the whole text input and display process, because it already exists in the platform. The same goes for all sorts of controls and interactions, from zooming to select boxes. Moreover, assuming this DOM is built up in a way where the semantics are embedded in the elements themselves, then it can also be used in different ways. One user might use their browser to render the DOM into something that can see on their screen, while another might use their browser to read the element contents aloud. One person might use their mouse to interact with the system while another might use their keyboard. Accessibility is built into every application built using the DOM - it may not be ideally presented in some situations, and it's still possible to get things wrong, but by default a blind user will at least have a chance of using the system. In contrast, a canvas-based application will need to reimplement accessibility from the ground up (usually in the form of a secondary hidden DOM tree).