What needs to happen is that HTML needs to go back to being a mark-up language, and the web needs to stop trying to deliver an application-level implementation for every single website.
Good article. It kind of makes me question how long we can go down this path though. Like surely we can't keep adding to css and the dom api's for 20 more years? How much bloat will we accumulate before we start over?
I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built with a flexbox-like API and let us bind shaders to elements. We don't need css if we have shaders. And I don't think adding more and more features to current api's is gonna solve problems long term.
> surely we can't keep adding to css and the dom api's for 20 more years?
We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.
It is clear that we need both apps and documents in web browsers. Yes yes "web", "hateoas" and all that, but it didn't materalise in practice and is therefore irrelevant.
So maybe we can have <!DOCTYPE app>, which lets you use a new set of APIs focussed on applications, but is otherwise in the same "shape". JSX type syntax.
This way it's easy for say newspapers to offer both an app format as well as a "lite" document format. Instead of their current offering which is a app shoehorned into a document and then a messy lite version.
Users who use noscript can, instead of blocking scripts wholesale and then whitelisting the good ones, request by default the lite document format. i.e <!DOCTYPE html>.
Uggghhh, the article states correct facts about the DOM but grossly incorrect conclusions. Most developers have always feared working with the DOM. This irrationality is not new. I have no idea why, but tree models scare the shit out of college educated developers. That’s supremely weird because computer science education spends so much energy on data structures and tree models.
It also makes the conversation about WASM even more bizarre. Most college educated developers are scared of the DOM. Yes, it’s fear the emotion and it’s completely irrational. Trust me on this as I have watched it as a prior full time JS dev for over 15 years. Developers are continuously trying to hide from the thing with layers of unnecessary abstractions and often don’t know why because they have invested so much energy in masking their irrational nonsense.
Other developers that have not embraced this nightmare of emotions just simply wish WASM would replace JS so they don’t have touch any of this. This is problematic because you don’t need anything to do with JS or the DOM to deploy WASM, but it’s a sandbox that ignores the containing web page, which is absolutely not a replacement. For WASM to become a replacement it would have to gain full DOM access to the containing page. Browser makers have refused to do that for clear security reasons.
So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions and then other developers that want bypass the nonsense by embracing that thing they don’t know they are yet afraid of it.
That is super fucking weird, but it makes for fun stories to nondevelopers that wonder why software is the way it is.
I feel there's space for brainstorming and creating new ways of making web apps without having to take a stand against the status quo. It's a fun thought exercise, naming all the things you think are wrong with the web, but I had to scroll real far to see that this is a post about Use.GPU: "Use.GPU is a set of declarative, reactive WebGPU legos. Compose live graphs, layouts, meshes and shaders, on the fly." So felt like a missed opportunity to me to highlight that more instead of going through the list of annoyances.
People often lament how DOM, HTML and CSS are becoming more and more complicated: the difficulty with simple and/or common tasks like vertical centering or virtualization, 600+ CSS properties, so many JavaScript methods, leaky abstractions, { contain: size }. I agree on many issues, but equally I struggle to imagine how it could realistically be not complex.
If it was a result of a single very well thought through vision and developers were expected to be committed to conforming to the latest API (think Apple’s iOS runtime or the like), we could maybe expect the <thread> and <comment> tags, we could demand there to be The One Correct Way of doing anything, that the “fat” is trimmed quickly and features go from deprecated to gone in a year. However, it is a product designed by committee (in fact, by multitudes of various committees) that has largely maintained backwards compatibility for decades, it is a free runtime that grew organically from what was supposed to be a basic hyperlinked document layout engine but now powers fully dynamic applications rivaling their native equivalents yet still has a pretty low barrier to entry for new developers, and as such it’s remarkably robust.
Yes, some applications tend to have a large amount of markup for what seems like simple features (the Slack’s input box example). However, the alternative is that browser vendors bake it all in, and then every app is stuck with the opinionated way they think is right. Perhaps some amount of chaos is healthy.
The problem is that DOM is absolutely inadequate for describing page layout, and even less so for Web applications. Incremental changes to DOM were meant to make it more suitable for this goal, but having inherently bad foundation didn't exactly help.
I believe that some sort of a constraints language would've been a lot better at describing page layout. And stuff like Web applications simply shouldn't exist. These should be applications that use native UI toolkits while relying on Internet for moving data, not presentation.
Users are usually unhappy with Web applications because of the way browsers restrict useful functionality and programmers struggle with workarounds and bloat of browsers to accomplish simple things.
Much of this complexity comes down to primitives being too primitive for the use case of web apps. They’re fine for documents, but for web apps it’s like trying to build a building from grains of sand instead of concrete blocks. Rube Goldberg machines are unavoidable when you’re doing that.
The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
> The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS.
Well, I'd prefer if it provided widgets that can't be skinned. :-) The theming should be the user's choice, not the app designer's.
> That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
I don't really care so much about the web dev experience as the web user experience. My experience as a user is greatly degraded by a bunch of web devs full of bright ideas about how to make their apps look, rather than using predefined widgets whose look is determined by me.
> Much of this complexity comes down to primitives being too primitive for the use case of web apps.
I totally agree with this, although I disagree about what the better alternative is. In my view it is partly this issue that's led to the disappointing profusion of "skinning". In desktop app toolkits you use a tree view, or a button, or a dropdown, or whatever. That widget's "identity" is based around functionality and its look and feel are not controllable by you as the app author. Instead, they're determined by the user's platform (color/font settings, window manager, etc.). That's a better model for users.
When look and feel of a widget are not controllable by designer, what ends up being is that people by whom it is controllable—who developed the widget, or the end user—become the de-facto designers. This is further complicated by the fact that “look and feel” can hardly be perfectly decoupled from how it works and its semantic content model (which in an ideal world the data to be skinned would be described in).
Though I can see both sides, there is a belief system in which this type of work is best delegated to professionals.
Yes IMO, the DOM is actually quite good. There are some valid complaints around superficial aspects of the API... For example, the ambiguous boundary between properties and methods being abused... But these are really superficial points.
The DOM cannot assume that it's just for building declarative applications, it needs to support imperative functionality too... IMO, the custom Web Components API solves the declarative problem very neatly, much more neatly than React or any other declarative framework I've come across.
I think it's wonderful how the DOM API has evolved slowly over time to meet user needs and it would be foolish to think we can just redesign it better from the bottom up without sacrificing some gems.
I think the people complaining about it are stuck in some utopian mindset. They have a specific frame of mind and they look at the DOM through the lens of a limited number of use cases which are relevant to them. They hold rigid, blanket beliefs around concepts like "Functional programming, side effects, reactivity" but these beliefs are siloed around each concept; they neglect the fact that the intersection of multiple approaches can transform the problem and radically alter the equation... For example, the modularization of Web Components and associated lifecycle methods, greatly reduce the dangers of imperative programming within component boundaries.
It's good to be aware that both strong acids and strong alkaline solutions are dangerous on their own, but one should recognize that mixing them together could completely change this fact.
The market seems incapable of producing a modern VB like development environment for the web. I have theories, but still unsure why it is like that. However, we do have a bunch of zero code tools companies that locks your logic into their ecosystem and charges quite a bit of money every month.
I often handcode UI layouts and animations in C on embedded devices. I also use HTML and CSS a lot.
Sometimes I prefer the raw simplicity of writing your own layout code. You then basically just need X/Y coordinates, anchor points and dimensions of the screen and the elements on them. The rest can be done using simple arithmetic. The good thing about this is that you can do 95% of what people use CSS for, while using a handful of consistent methods. Wbile this to the uninitiated requires some introduction into how to think in a coordinate system, the simplicity can be refreshing.
Meanwhile in CSS you have a organically grown complexity of features where sometimes things that should be simple are hard, often because the elements that should be styled have default attributes with subtle differences which people aren't aware of. Only the minority could tell you the differences between display: inline, block, inline-block, contents, flex, grid, table, rable-column-group, etc. But elements may have them set per default.
I get that it is hard to simplify CSS for reasons of backwards compatibility, but sometimes I wish that instead of adding on top someone had had a long hard think about how to solve the problems elegantly and with consistency instead.
> However, it is a product designed by committee (in fact, by multitudes of various committees)
Not really. The Web is owned and operated by Google. They can literally do whatever the fuck they want with it. (Any "standardization" process is less then a formality at this point.)
I'm tempted to take the opposite stance to the author. The web as a platform is wildly successful, and it's interesting to think about why.
Surely the "loose" standards encouraged neat hacks that at some point were encoded as best practices and then standardized. Maybe that would tempt us to want to "cut the cruft" but a) people probably thought that many times previously and b) backwards compatibility is probably more valuable than one would think.
To say that web as platform is wildly successful would be an understatement. It's so successful that probably like 95% people doing webdev don't even care about these discussions or have opinions about it.
I think that scale of "silent" users compared to proactive devs would be the most surprising number. Like for anyone who is "Rethinking DOM from first principles" there is probably like 10000s of randos editing ecommerce html templates, exporting results into tables and dataviz or making small uis for some internal system.
It's easy to say "XYZ is dead, time to replace it with something better". Another example is the Win32 APIs are hideous (look up everything SetWindowPos does) and need replacing.
In the real world though, backwards compatibility reigns supreme. Even if you do go and make a better thing, nobody will use it until it can do the vast majority of what the old thing did. Even then, switching is costly, so a huge chunk of people just won't. Now you have two systems to maintain and arguably an even bigger mess. See Win32 vs. WinRT vs. Windows App SDK or however many else there are now.
So if you're serious about improving big mature platforms, you need a very good plan for how you will handle the transition. Perhaps a new API with a compatibility layer on top is a good approach, but the compatibility layer has to have exactly 100% fidelity, and you can never get rid of it. At the scale of these platforms, that is extremely hard. Even at the end of the day, with a huge compatibility layer like that, have you really made a better and less bloated system? This is why we tend to just muddle along - as much as we all like to dream, it's probably actually the best approach.
>Perhaps a new API with a compatibility layer on top is a good approach
The opposite would make more sense. Have a transpiler or something to the 'old' API (very natural, given it can grow with the new API and you don't have to implement the entire 'old' API), while new apps can slowly transition the 'new' API.
I think for a system that can basically do EVERYTHING, HTML is quite well designed. And I think keeping backwards compatibility for SO long is a big achievement and a good thing.
I also think that if we could roll back time and had the knowledge of today, instead of fixed elements with user-agent styling and hard-coded restrictions, I would've crafted a system of arbitrary nodes that can have modifiers stacked on them.
So instead of
<ul> you could use <Features list>. This would minimize the very different but basically same CSS properties as well and trim out A LOT of HTML tags. Think <Comment collapsible link> instead of wrapping a <details> in an <a>.
That's basically how React and Vue started out with the component system, but I'm thinking more of a GameObject & Component system like with Unity.
Technically, you're supposed to add a dash to a custom element to avoid namespace issues with potentially new elements, but that's probably an easy search and replace if it ever happens.
> CSS is at least two different things mashed together: a system for styling rich text based on inheritance... and a layout system for block and inline elements, nested recursively but without inheritance, only containment. They use the same syntax and APIs, but don't really cascade the same way. Combining this under one style-umbrella was a mistake.
This might in fact be a valuable insight, I never thought of it.
Glad the title was changed because this article isn't about HTML at all. Instead it seems to be about corporate/for-profit needs for their web applications that happen to touch HTML in some parts. All about throwing away the good parts of HTML to make laying out applications easier and prettier.
To this I say: go away and leave HTML alone if you want to build some application from first principles. The web's first principle is that HTML should have text. Hyper TEXT MARK-UP language.
Devs have learned not to keep state in the document, because it's inadequate for it.
Web devs have moved the state out of the document into JS variables and have been piling bloated, short-lived crap on top of those variables ever since.
If you actually keep state in the document things become rather simple. Scripts themselves become stateless and do not require direct dependencies on one another. Data can be queried across the page with CSS selectors. Many visual transformations on data can be handled in CSS as well. There is a well-developed system of events to handle interactions, which removes the need to handle user changes, AJAX and WebSockets separately. You gain the ability to dynamically examine and modify the state of your "application" simply by pressing F12 and changing things in the elements tab.
While it's definitely possible to imagine better ways of dealing with documents, layouts and so on, seeing how JS frameworks handle state makes me fear any "improvements" on this front.
All those words, and yet not once did he even mention the entire reason everything is the way it is: to preserve backwards compatibility.
It's like writing an entire diatribe about how it sucks that people can insult you online, and how that should change ... and not even mentioning the benefits of freedom of speech.
I like the DOM. I think people keep forgetting all the small details, like being responsive (working on mobile and desktop) and many other issues related to privacy and usability. IMEs, dictionaries, spelling correction, etc... All of these happen in text areas. If you implement things yourself, say in canvas on a webpage, you can't provide these. For example if I misspel somethng the browser can lookup that word in the user's dictionary but your page can not as looking through a user's dictionary would be a privacy issue.
That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at
Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.
Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
I've been looking at native development for quite some time now (WPF/WinUI/SwiftUI, starting with Win32 and AppKit), and honestly Web technologies are much better than that. The fact that it is cross-compatible is just a cherry on top.
If finally WASM gets a cheap and easy way to manipulate DOM, I think even more stuff will move towards web tech like Electron and hopefully Tauri in the future.
I'm sympathetic. But the problem with trying to get away from something where the base item has "350+ properties" is that it almost certainly has a competing number of stakeholders/usecases that it supports.
That is to say, you aren't necessarily simplifying things. You are throwing away some of the things that somebody needs for what they do.
It may, in fact, be time to do this. I can't say. Odds are very high that you should, instead of throwing out some stakeholders as you try to shift something, you should invite the stakeholders you think you can more effectively serve to a new thing.
I wish the author had compared Flutter to the Web. Would have been nice to know his opinion on the flutter rendering model. Is it the state of art design in UI rendering ?
In an alternative world, something like HTMLayout would have won the UI wars and used a small subset of HTML and CSS with reasonable additions for the UI.
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
Alan Kay Wrote:
Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
DOM per se, as a tree of elements, is not that bad. CSS is also not that bad in general.
Their API is probably the problem. Not modular so makes the mess.
Options to modularize them:
DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for <textarea> we may have separate "textarea" interface:
element.tagName
... and the rest of DOM-as-a-tree methods ...
element.textarea // <textarea> specific interface of its behavior
element.textarea.select(startEnd) // interface method
element.textarea.selectionStart // interface prop
element.textarea.selectionEnd // interface prop
element.textarea.rows // interface prop
element.textarea.columns // interface prop
...
CSS, that huge flat table is a nightmare, not just because of its size, but because of extensibility problems right now and in the future. Example, all CSS grid related properties should rather go to their own namespace:
54 comments
[ 2.9 ms ] story [ 75.8 ms ] threadAnd we need to stop relying on JS so much.
I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built with a flexbox-like API and let us bind shaders to elements. We don't need css if we have shaders. And I don't think adding more and more features to current api's is gonna solve problems long term.
We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.
He probably means will-change.
So maybe we can have <!DOCTYPE app>, which lets you use a new set of APIs focussed on applications, but is otherwise in the same "shape". JSX type syntax.
This way it's easy for say newspapers to offer both an app format as well as a "lite" document format. Instead of their current offering which is a app shoehorned into a document and then a messy lite version.
Users who use noscript can, instead of blocking scripts wholesale and then whitelisting the good ones, request by default the lite document format. i.e <!DOCTYPE html>.
It also makes the conversation about WASM even more bizarre. Most college educated developers are scared of the DOM. Yes, it’s fear the emotion and it’s completely irrational. Trust me on this as I have watched it as a prior full time JS dev for over 15 years. Developers are continuously trying to hide from the thing with layers of unnecessary abstractions and often don’t know why because they have invested so much energy in masking their irrational nonsense.
Other developers that have not embraced this nightmare of emotions just simply wish WASM would replace JS so they don’t have touch any of this. This is problematic because you don’t need anything to do with JS or the DOM to deploy WASM, but it’s a sandbox that ignores the containing web page, which is absolutely not a replacement. For WASM to become a replacement it would have to gain full DOM access to the containing page. Browser makers have refused to do that for clear security reasons.
So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions and then other developers that want bypass the nonsense by embracing that thing they don’t know they are yet afraid of it.
That is super fucking weird, but it makes for fun stories to nondevelopers that wonder why software is the way it is.
If it was a result of a single very well thought through vision and developers were expected to be committed to conforming to the latest API (think Apple’s iOS runtime or the like), we could maybe expect the <thread> and <comment> tags, we could demand there to be The One Correct Way of doing anything, that the “fat” is trimmed quickly and features go from deprecated to gone in a year. However, it is a product designed by committee (in fact, by multitudes of various committees) that has largely maintained backwards compatibility for decades, it is a free runtime that grew organically from what was supposed to be a basic hyperlinked document layout engine but now powers fully dynamic applications rivaling their native equivalents yet still has a pretty low barrier to entry for new developers, and as such it’s remarkably robust.
Yes, some applications tend to have a large amount of markup for what seems like simple features (the Slack’s input box example). However, the alternative is that browser vendors bake it all in, and then every app is stuck with the opinionated way they think is right. Perhaps some amount of chaos is healthy.
I believe that some sort of a constraints language would've been a lot better at describing page layout. And stuff like Web applications simply shouldn't exist. These should be applications that use native UI toolkits while relying on Internet for moving data, not presentation.
Users are usually unhappy with Web applications because of the way browsers restrict useful functionality and programmers struggle with workarounds and bloat of browsers to accomplish simple things.
HTML5 input and form validation are still a broken nightmare that can barely be patched by adding copious amounts of JavaScript.
The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
Well, I'd prefer if it provided widgets that can't be skinned. :-) The theming should be the user's choice, not the app designer's.
> That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
I don't really care so much about the web dev experience as the web user experience. My experience as a user is greatly degraded by a bunch of web devs full of bright ideas about how to make their apps look, rather than using predefined widgets whose look is determined by me.
> Much of this complexity comes down to primitives being too primitive for the use case of web apps.
I totally agree with this, although I disagree about what the better alternative is. In my view it is partly this issue that's led to the disappointing profusion of "skinning". In desktop app toolkits you use a tree view, or a button, or a dropdown, or whatever. That widget's "identity" is based around functionality and its look and feel are not controllable by you as the app author. Instead, they're determined by the user's platform (color/font settings, window manager, etc.). That's a better model for users.
Though I can see both sides, there is a belief system in which this type of work is best delegated to professionals.
The DOM cannot assume that it's just for building declarative applications, it needs to support imperative functionality too... IMO, the custom Web Components API solves the declarative problem very neatly, much more neatly than React or any other declarative framework I've come across.
I think it's wonderful how the DOM API has evolved slowly over time to meet user needs and it would be foolish to think we can just redesign it better from the bottom up without sacrificing some gems.
I think the people complaining about it are stuck in some utopian mindset. They have a specific frame of mind and they look at the DOM through the lens of a limited number of use cases which are relevant to them. They hold rigid, blanket beliefs around concepts like "Functional programming, side effects, reactivity" but these beliefs are siloed around each concept; they neglect the fact that the intersection of multiple approaches can transform the problem and radically alter the equation... For example, the modularization of Web Components and associated lifecycle methods, greatly reduce the dangers of imperative programming within component boundaries.
It's good to be aware that both strong acids and strong alkaline solutions are dangerous on their own, but one should recognize that mixing them together could completely change this fact.
Sometimes I prefer the raw simplicity of writing your own layout code. You then basically just need X/Y coordinates, anchor points and dimensions of the screen and the elements on them. The rest can be done using simple arithmetic. The good thing about this is that you can do 95% of what people use CSS for, while using a handful of consistent methods. Wbile this to the uninitiated requires some introduction into how to think in a coordinate system, the simplicity can be refreshing.
Meanwhile in CSS you have a organically grown complexity of features where sometimes things that should be simple are hard, often because the elements that should be styled have default attributes with subtle differences which people aren't aware of. Only the minority could tell you the differences between display: inline, block, inline-block, contents, flex, grid, table, rable-column-group, etc. But elements may have them set per default.
I get that it is hard to simplify CSS for reasons of backwards compatibility, but sometimes I wish that instead of adding on top someone had had a long hard think about how to solve the problems elegantly and with consistency instead.
Not really. The Web is owned and operated by Google. They can literally do whatever the fuck they want with it. (Any "standardization" process is less then a formality at this point.)
Surely the "loose" standards encouraged neat hacks that at some point were encoded as best practices and then standardized. Maybe that would tempt us to want to "cut the cruft" but a) people probably thought that many times previously and b) backwards compatibility is probably more valuable than one would think.
I think that scale of "silent" users compared to proactive devs would be the most surprising number. Like for anyone who is "Rethinking DOM from first principles" there is probably like 10000s of randos editing ecommerce html templates, exporting results into tables and dataviz or making small uis for some internal system.
Yes it can. clip-path does just that.
In the real world though, backwards compatibility reigns supreme. Even if you do go and make a better thing, nobody will use it until it can do the vast majority of what the old thing did. Even then, switching is costly, so a huge chunk of people just won't. Now you have two systems to maintain and arguably an even bigger mess. See Win32 vs. WinRT vs. Windows App SDK or however many else there are now.
So if you're serious about improving big mature platforms, you need a very good plan for how you will handle the transition. Perhaps a new API with a compatibility layer on top is a good approach, but the compatibility layer has to have exactly 100% fidelity, and you can never get rid of it. At the scale of these platforms, that is extremely hard. Even at the end of the day, with a huge compatibility layer like that, have you really made a better and less bloated system? This is why we tend to just muddle along - as much as we all like to dream, it's probably actually the best approach.
The opposite would make more sense. Have a transpiler or something to the 'old' API (very natural, given it can grow with the new API and you don't have to implement the entire 'old' API), while new apps can slowly transition the 'new' API.
I also think that if we could roll back time and had the knowledge of today, instead of fixed elements with user-agent styling and hard-coded restrictions, I would've crafted a system of arbitrary nodes that can have modifiers stacked on them.
So instead of
<ul> you could use <Features list>. This would minimize the very different but basically same CSS properties as well and trim out A LOT of HTML tags. Think <Comment collapsible link> instead of wrapping a <details> in an <a>.
That's basically how React and Vue started out with the component system, but I'm thinking more of a GameObject & Component system like with Unity.
This comes in very handy with XML.
This might in fact be a valuable insight, I never thought of it.
To this I say: go away and leave HTML alone if you want to build some application from first principles. The web's first principle is that HTML should have text. Hyper TEXT MARK-UP language.
Web devs have moved the state out of the document into JS variables and have been piling bloated, short-lived crap on top of those variables ever since.
If you actually keep state in the document things become rather simple. Scripts themselves become stateless and do not require direct dependencies on one another. Data can be queried across the page with CSS selectors. Many visual transformations on data can be handled in CSS as well. There is a well-developed system of events to handle interactions, which removes the need to handle user changes, AJAX and WebSockets separately. You gain the ability to dynamically examine and modify the state of your "application" simply by pressing F12 and changing things in the elements tab.
While it's definitely possible to imagine better ways of dealing with documents, layouts and so on, seeing how JS frameworks handle state makes me fear any "improvements" on this front.
It's like writing an entire diatribe about how it sucks that people can insult you online, and how that should change ... and not even mentioning the benefits of freedom of speech.
That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at
https://earth.google.com
Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.
Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
If finally WASM gets a cheap and easy way to manipulate DOM, I think even more stuff will move towards web tech like Electron and hopefully Tauri in the future.
That is to say, you aren't necessarily simplifying things. You are throwing away some of the things that somebody needs for what they do.
It may, in fact, be time to do this. I can't say. Odds are very high that you should, instead of throwing out some stakeholders as you try to shift something, you should invite the stakeholders you think you can more effectively serve to a new thing.
Alan Kay on web browsers, document viewers, Smalltalk, NeWS and HyperCard (2021) (donhopkins.medium.com)
234 points by gjvc on Jan 8, 2023 | hide | past | favorite | 272 comments
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
Alan Kay Wrote: Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
[...]
Their API is probably the problem. Not modular so makes the mess.
Options to modularize them:
DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for <textarea> we may have separate "textarea" interface:
CSS, that huge flat table is a nightmare, not just because of its size, but because of extensibility problems right now and in the future. Example, all CSS grid related properties should rather go to their own namespace: So different layouts ( like display:flex(), display:waterfall() ) may have their own rows, columns, etc.As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.