Rethinking DOM from first principles
acko.net
acko.net
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.
Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days.
Java and Flash (although very problematic from a security point of view) were probably better bases on which to build "Web for applications" than HTML5+/CSS3+/JS/WASM will ever be, but it was intolerable for Google/Microsoft/Mozilla to hand the keys to Oracle/Adobe for that. It's all politics, and it's all worse and more complicated and more inefficient as a result.
Contrary to what was stated in the suggestion, it’s hardly a solved problem—improvements are being made at a steady pace (grids or { text-wrap: pretty } come to mind)—but it is interesting to imagine, especially if there were extra compelling reasons for engineers to restrict themselves to purer hypertext document API if possible (for example, it could be much more stable, while the app part could be unlocked to evolve more quickly but would be more demanding to developers keeping their webapps up-to-date; search engines could prioritize it; there could be hosting services specializing in it; and so on).
One counter-argument is that you can’t neatly separate the two and engineers will definitely want to use both; one way around it I can see is if hypertext document functionality was possible to use from within the webapp somehow, but I haven’t given it that much thought obviously.
That's essentially where the web was at before the HTML5 days: you could already go as fancy as you wanted, at the cost of pushing your users into a java/flash applet (and through longer loading times, high CPU/Memory requirements, …), and that clearly wasn't the norm.
Was Java any worse from a security point of view than what we have now?
The browser is really just a cross-platform platform for building applications.
There should be a singlular framework for creating desktop apps.
You'd never design from the start the bonkers HTML/CSS, box model, and other junk we are stuck with, but browsers have a number of good aspects that you'd probably end up with in a complete redesign.
The problem is multifaceted. UI toolkits are very hard to do well (I have a lot of opinions on this, and my own crossplatform toolkit), even on a single platform. Just that alone is huge. There are basically no overall great UI toolkits, even if some have good parts. Even a theoretical great UI toolkit will have quite a task to achieve parity with what browser UIs can do.
If we could get past that (spoiler: we can't, no way in hell) then we'd also have to be willing to ditch all the legacy browser stuff to switch billions of users and devices to something new AND we'd still have many other big problems to deal with: getting the committee/everyone to agree without ruining it, security, privacy, etc.
We've accepted we can't really fix it, so the only thing we can do is keep extending it. That's how we got here.
WPF was an amazing UI toolkit. Heck Silverlight was a great UI toolkit.
Even Swing was nice to code in, it just ran horrible on machines of the time.
Eg Swing has all those problems, in addition to ugly themes. The uncanny valley resulting from trying to mimic native UI was bad. At least nowadays users don't necessarily expect native looking UI, even browsers don't do it.
It's not a question of can you make a nice UI with it. You can drive a nail with a rock. The high pain needed to be productive with bad tools leads to Stockholm syndrome. People would rather stick with what they know than go through such pain again to learn something new, and rightly so when the new one is likely just as bad in new ways.
Also now nothing resembles native platform UIs, so that isn't a big deal. Swing was very theme-able, which is all anyone cares about now days.
Swing was themeable but good luck if you ever try to do it. Customizing an existing theme is too hard. All components have opaque theme objects that are part of the complexity problem I mentioned and often hide functionality and parts you want to customize.
It's easy to shit on everything, but I really think UI could be done much better and that most or all toolkits make big mistakes that hurt productivity and cause a lot of suffering.
Regardling difficulty: HTML/CSS is essentially already cross platform UI toolkit. Yes its hard, but Im saying if one were to make it, I dont see why the same UI framework shouldnt work for a desktop application.
Building the web toolkit took enormous effort and it sucks in many ways (see article). Theoretically a new one could be created and could also work for desktop, but there are lots of reasons why that won't happen.
Why?
We have seen all these framework claimed to be cross platforms and none of them are not able to make it to the top framework being used.
Web is the only "platforms" with some kind of success by abstract everything away so most of the browser display roughly the same things to all users on all OS.
Implement the UI framework at an OS level. The default OS-specific design should live on top of that. If you were to build an OS of the future, there shouldn't be this need for this distinction between web and desktop.
I’m sure the person you were referring to doesn’t want to make the web shit for the blind. Calm down
We already have similar sofware development patterns, but I wonder what a Web API surface would look like when fully embracing a similar modular mindset.
The web platform has just done exceedingly fantastically well with incredibly respectable people working really hard to steer things forwards. Having multiple layers of security and technical architecture groups to review, having other browsers review proposals: it's inconceivable to me to imagine spending 1/20th as much effort building an alternative of any even modest caliber. They sure tried with Dart, Flutter, Fuschia, but it's just not a significant enough lift, it's just another app dev platform, and it's desire for pixel perfect graphics made it absolutely ass and terrible at being a good reactive malleable platform. And it being Flash 2.0 made it vastly inferior to what users got from the web.
The web is big and dense. Even ignoring the sprawling amazing magical web platform and focusing on the robust DOM. And that pisses a lot of people off. There is much clutching for certainty, wanting to be steered. Devs crave having the validation of Modernism, of solutions that when written fit expected shape and parameters. 'Another fine Cathedral!'; you know it when you see it. But the web doesn't give us that certainty at all. There's many ways to get there, there's overlapping options and tools, dozens of paradigms to pick from for how you want to organize your css rules, different layout models to swizzle together. The dirty rough open possibility of the web Bazaar drives people frelling off the wall.
I can't help but see those people clutching for certainty as hopelessly out of touch with the universe, obsessed with a narrow engineering paradigm of control & missing the organic beauty of life the universe & everything. Wittens here at least has some core points (amid lots of buckshot, much that various tensions are unresolved).
It's fantastic that we have so many different ways to do web apps. The basics have proven so malleable, such endless ability to be interpreted and governed into forms of whatever we might imagine. The layout of the DOM has gotten so so much better, had so many wonderful additions and fixed in the past decade. The Web Platform Tests have put to the sword so much uncertainty, become a massive way for the web to remain one thing even across many browsers. New browsers like Ladybird and Servo show promise of new engines, new life. Web Components will or won't they questions dog us us still, we all consult our team leaves to guess their future, but meanwhile a similar structuring of custom comments is endemic to React. Invoker/commands are spreading id-ref dogma, for the page linking to other parts of the page declaratively. It's all incredibly exciting. I'd be very happy to have anything else that shows life, that can compete as an equally radiant open question we can continue to improve. But that's not what the DOM haters are after. And the narrow vision view: I think it bereft & sad, and the lack of material they have to point to to steer us, to offer spiritual council upwards rather than just condemning downwards, throwing faint "bloat" condemnations: it makes me sad we critics so obviously up to no good, who just standby and have such vacuous aspersions to cast, on endless repeat.
We have <!doctype html> but why not add other doc types as time goes on? Instead of shoehorning features you could have a <!doctype new-html> which would opt a web page into the ability to use newer features like newer elements or cleaner APIs
There is also the “use strict” directive in JS (which any script tag with type=“module” runs in now, slowly eliminating this need) that would opt your script into a stricter form of JS. You could even do it on a per function basis. We could have something like that for other features or stricter qualifiers etc.
We have done this before successfully and broadly, I think it’s time we revisit the usefulness of doing this again
Javascript has "use strict" to disable the parts that fundamentally cause problems even if you don't use them.
What exactly is in html you want to disable here? There are features that maybe dont make sense but they are largely self-contained. Unlike in js you can simply not use them and its fine.
We do have older ones!
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Have we collectively learned the lesson? If so maybe we could have a new doctype for [X]HTML 6. I won't be holding my breath for it.
Or, you know, provide a set of usable controls that provide useful functionality out of the box and provide a set of useful APIs so that people can either extend those controls or create their own.
Web Platform provides neither. Compare that to literally every other UI toolkit under the sun. Turbo Vision from 1990s was a better toolkit than anything the web has to offer.
...hell, native apps are still more likely to be crap than not. Good UIs are hard and programmers are lazy; the big advantage of web apps remains the difficulty of an app completely crashing the browser due to sheer developer apathy.
I’m not at all a frontend person, I just think flex is one of the best systems I have ever used. It usually gets the job done in a way that I expected to work (and that bar is pretty low lol)
<table width="100%" height="100%">
<tr>
<td colspan="2" height="50"> header </td>
</tr>
<tr>
<td width="200" valign="top"> sidebar </td>
<td valign="middle"> content </td>
</tr>
</table>And ~15 years ago a consensus formed that making separate sites for phones and other devices was not the way forward and tables are ill suited for responsiveness.
We've had CSS Grid for 7-8 years and Flexbox for longer, tables can be left for what they're good at, tabular data, not layout.
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.
I AM SOLD
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.
Still, it's quite sad how long we had to wait for stylable checkboxes.
The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re still extremely primitive relative to something like AppKit or win32.
My guess is that would put the burden of keeping up with evolving APIs on web developers and web companies. And there is a huge and very diverse ecosystem out there.
Native app developers seem to be burning resources trying to stay in stores and working on modern devices.
Staying in app stores in my experience has not been particularly difficult or resource intensive. If you stick to first party toolkits and don’t go nuts with custom widgets, maintenance is minimal and often you only need to compile against a newer SDK every few years. The horror stories are generally coming from projects with severe NIH syndrome and sometimes of users of cross platform frameworks.
As it is, the vast majority of consumers want platform parity because nobody wants to feel left out of features on a second-class platform missing an API.
It already does literally that. Have you heard about <form>? These common widget libraries seldom last, and that's because people want to differentiate on style in ways that go beyond a CSS skin.
> people want to differentiate on style in ways that go beyond a CSS skin.
And the reason this is a problem is due to shortcomings in current widgets, which is part of what I was getting at. There’s no technical reason why everything can’t be skinned with CSS, as we’ve seen with modern versions of GTK+ which rely on it entirely for styling. It’s fixable, but there’s little work being done to actually fix it.
I cry at the ways we are doing and defining column tables.
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.)
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.
It's probably safe to say that the majority of the dev workforce in the last 2 decades started their career with learning HTML/JS/CSS stack, and it's understandable why they like it. It doesn't make this stack any better for creating apps, no matter how many abstractions on top we place.
It's true, what people think of as native on the web are merely incidental from its history, not some ironclad law of how to make interfaces.
It is so bad that one of the most impressive operating system features to be added in recent years is the ability to select and copy arbitrary text from app UIs, using either accessibility APIs or (more recently) straight-up OCR (because of course accessibility is another thing UI designers forget).
It's not like adding text selection in native apps is even hard; it's just not on the radar, and never has been. The number of old-school apps that added some form of "open log file" to either support instructions or as an actual function in the UI instead of making error messages selectable / copyable is depressing; I've seen programmers spend more time mocking end users for not knowing how to take proper screenshots than it would have taken to implement selectable UIs.
...and by historical accident, this problem is now solved in the vast majority of new applications. A small mercy!
In Chrome, open DevTools, Shift+Ctrl+P > Disable JavaScript
It's far from the only thing it has issues with; I've found obviously broken UI patterns within a couple clicks of opening Earth's map view:
- right click doesn't appear to work anywhere (except input boxes), even on elements that have direct equivalents in other Google sites (like the account switcher),
- when you click the account switcher, as long as its open, the rest of the site ignores the mouse events; attempting to drag the map screen doesn't close the switcher, hovering over buttons doesn't change the cursor etc.
> right click doesn't appear to work anywhere
I hate this and it's the default for a canvas app since the app would have to implement doing something on right click where as in the browser it's the default. Unfortunately, an HTML app can disable right click too :(
In fact, I hate that issue on all native apps. Things I want to select/copy/lookup are not selectable/copyable/lookup-able. As an example, Sublime Merge, a native app, quite often I want to copy a path but there is no option to do so. Every place that displays a path would need custom code (or a shared control) to make the path copyable. HTML doesn't generally have this issue as it's opt-out not opt-in for being copyable.
I'm not a fan of Flutter or other canvas bases sites. Emoji didn't work for like 3 years in google docs after their canvas change. It works now but not always.
It's worse too in that it doesn't matter if flutter eventually fixes these issues. Every app needs to be update. That's not true with HTML where the browser updates to support "insert password into input type=password" and it just works. Even better, an extension (1 password) can insert the password but it can't on a canvas based app.
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.
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.
Because only javascript should be allowed to screw up that badly.
The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you.
It's not irrational; quite the contrary.
Storing the diffs to local storage is an interesting idea though.
I think it had/has the perfect balance of utility without being overly opinionated. State was also much easier to deal with.
I haven't used it in a while, but still look back on that project fondly.
Another issue is people basing their fears of things in the past. Yes, the web was more difficult to do fancy things but often they're trying to push the web to do things it just couldn't do back then. Now you can using basic, built-in functionality and it's often easier that way.
My favorite part of web dev is working directly with the DOM, vanilla JS, and using minimal dependencies (if any).
I feel like the web equivalent of an assembly programmer these days, but apparently nobody is interested in hiring for this sort of thing anymore.
To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around.
Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance.
> Browser makers have refused to do that for clear security reasons.
Actually, they’re a long way down the path of doing it. They’ve just been taking their time to make sure it’s done right—they’ve headed in at least three different directions so far. But it’s been clear from just about the start that it was an eventual goal.
What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.
The idea is that any application can be compiled to WASM and delivered via webpage instead needing to be installed to an OS desktop. Developers see something radically different because they want it to solve a different problem, but let’s remember it’s not about developers but portability and user experience for end users.
Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.
These distinctions are crucial when hardware performance really matters, like gaming or scientific data analysis. Otherwise these performance differences just aren’t noticeable to a common user.
Before WASM was a thing 3D gaming engines were ported into Emscripten demos to show case the potential. The output was too slow to play heavy 3D games in a portable browser container but far beyond what you could get away with using JS alone. All that misses the point that you could now run this giant game engine in a web page without installing anything.
They’ve made a solution looking for a problem while the problem is staring them right in the face. It is a frankly ridiculous situation.
There’s not any particularly meaningful change in its traction. It has specialised situations where it’s very desirable, and it has been used in those specialised situations extensively for quite a few years; and for more general use, it’s trudging along as it ever has been, because it’s not compelling.
> Until it has DOM access nobody working on the front end will be particularly enthused about its utility.
This is also false. Shipping WebAssembly or shipping Web Workers each add complexity, compared with just using main-thread JavaScript, and most people simply can’t justify that—that’s why they’re not interested. But as for DOM access transforming things, I’ll say that Rust is one of the main languages used for targeting WebAssembly (because most languages aren’t suitable), and native DOM bindings is going to change approximately nothing. It will allow/require a slight change in the build process, and slightly change the way you write your own bindings, but that’s all.
I don’t entirely understand why people keep on thinking giving WASM direct access to DOM objects will be transformative. In truth, it’s very minor.
Very few people are "scared" of tree models.
The problem of working with the DOM is that it's:
- 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things
- Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you need out of existing building blocks
- An API that is completely non-composable
- A rendering system that is actively getting in the way of doing things, and where you have to be acutely aware of all the hundreds of pitfalls and corner cases when you so much as change an element border (which may trigger a full re-layout of the entire page)
- A rendering system which is extremely non-performant for anything more complex than a static web page (and it barely manages to do even that). Any "amazing feats of performance" that people may demonstrate are either very carefully coded, use the exact same techniques as other toolkits (e.g. canvas or webgl), or are absolute table stakes for anything else under the sun. I mean, an frontpage article last week was how it needed 60% CPU and 25% GPU to animate three rectangles: https://www.granola.ai/blog/dont-animate-height
> So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions
The abstractions of the past 15 or so years have been trying to hide from the DOM only because the DOM is both extremely non-performant and has an API even a mother wouldn't love.
DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow.
Chrome has always been much slower. Back then I was getting closer to a max of 50 million ops/second perf testing the DOM. Now Chrome is about half that fast, but their string interpolation of query strings is about 10x faster.
The only real performance problem is the JS developer doing stupid shit.
1. These are not excuses, these are facts of life
2. No idea where you got vanity from
> DOM access is not quite as fast now as it was 10 years ago. I was getting just under a billion operations per second
Who said anything about DOM access?
> The only real performance problem is the JS developer doing stupid shit.
Ah yes. I didn't know that "animating a simple rectangle requires 60% CPU" is "developers doing stupid shit" and not DOM being slow because you could do meaningless "DOM access" billions time a second.
Please re-read what I wrote and make a good faith attempt to understand it. Overcome your bias and foregone conclusions.
When you profile something and you get "a billion per second" what you've got there is a loop where the body has been entirely optimized away. Presumably the JIT noticed you were doing nothing and making no changes and optimized it away. I don't think there's a single real DOM operation you can do in an amortized 3-ish CPU cycles per operation (2015 3GHz-ish CPU, but even at 5GHz it wouldn't matter).
That's not a real performance number and you won't be seeing any real DOM operations being done at a billion per second anytime soon.
I mention this and underline it because this is really an honorary "latency value every programmer should know"; I've encountered this multiple times online where someone thought they were benchmarking something but they didn't think about the fact that .6 nanoseconds per iteration comes out to about 2-3 cycles (depending on CPU speed) and there's no way what they thought was benchmarking could be done that quickly, and I've now encountered it twice at work. It's a think worth knowing.
That is not correct in practice. Some operations are primarily CPU bound, some are primarily GPU bound, and some are primarily memory bound. You can absolutely see the difference when benchmarking things on different hardware. It provides real insight into how these operations actually work.
When you conduct your own measurements we can have an adult conversation about this later. Until then it’s all just wild guessing from your imagination.
The whole topic of this conversation is a measurement in which it was claimed that "a billion DOM operations per second" were being done in 2015. That's a concrete number. Show me the actual DOM operation that can be done a billion times per second, in 2015.
The burden of proof here is on you, not me. I'm making the perfectly sensible claim that all you can do in a low-single-digit number of cycles is run a loop. I have, in fact, shown in other languages down at the assembler level that things that claim to be running in .6ns are in fact just empty loops, so I'm as satisfied on that front as I need to be. It's not exactly hard to see that when you look at the assembler. You don't even need to know assembler to know that you aren't doing any real work with just 3 or 4 opcodes.
I don't know how you expect to just Measure Harder and get a billion operations per second done on any DOM structure but I expect you're going to be disappointed. Heck, I won't even make you find a 2015 machine. Show it to me in 2025, that's fine. Raw GHz haven't improved much and pipelining won't be the difference.
https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
I cannot go back in time to 2015 conditions, but you can run the tests yourself and get your own numbers. Try running that in different browser and on different hardware. Another interesting thing is experimenting with is HTTP roundtrip speed and WebSocket send versus receive speed on different hardware.
This is interesting because many assumptions are immediately destroyed once the numbers come in. Many of these operations can execute dramatically faster on hardware with slower CPUs so long as the bus and memory speeds are greater.
What's also interesting is that many developers cannot measure things. It seems as if the very idea of independently measuring things is repulsive. Many developers just expect people to give them numbers of something and then don't know what to do with it, especially if the numbers challenge their assumptions, like cognitive conservatism.
This is easily avoided: use 'outline' instead of 'border', or just keep the border width fixed and change the border color to/from transparent.
Yup. And DOM is full of footguns like this. "Oh, you can't do this primitive thing no UI kit has a problem with, you have to use this workaround".
Secondly, there are two kinds of visual operations that can occur from a DOM change: a screen repaint or a local change. A repaint occurs because the configuration of an element is modified relative to its dimensions, which includes: size, shape, or location. Everything else is really just a color change and is very fast regardless of the DOM size.
Even still modern visual rendering is pretty fast. I have a personal project that is an OS GUI, including file system display, written in TypeScript that displays in a browser. It took close to 10000 DOM visual on the page at one for drag and drop to become slower and laggy. I wouldn’t build a AAA 3D game engine in that, but it’s also not the intended use case.
There's:
- reflow (most expensive)
- repaint (second most expensive)
- composition (least expensive)
The footguns in HTML and CSS are randomly scattered all over the place.
Oh? You changed a single value that wouldn't even register on any performance monitoring tool anywhere else? Oops, the browser now has to reflow the page, re-paint it, and re-compose leading to noticeable CPU and GPU spikes.
Or maybe it won't, you'll never know. Because none of these are documented anywhere and randomly change as browser internals change.
E.g. why would focusing an element reflow the entire document? https://gist.github.com/paulirish/5d52fb081b3570c81e3a Who knows.
Again, a recent article on HN's front page dealt with 60% CPU and 25% GPU while doing the most primitive of all animations on just three rectangles.
> I wouldn’t build a AAA 3D game engine in that, but it’s also not the intended use case.
Yes. Because the use case is displaying static pages.
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.
People often overlook some of the functional UX the web brings to the table. For example: on the web I get consistent search and text highlighting behavior, consistent notifications, consistent navigation behavior (back buttons, history), I can tab to focus (usually), and I can use plugins to customize the content. Even the idea that you can reset the application state with a refresh is something I wish I had on some native apps.
Some widget will be rendered wrong, they'll use the wrong font (or even hinting!), right click may not work as expected, they won't use multiple windows correctly, etc.
Even React Native gets some of this wrong, although few use that on desktop.
If you're a user that appreciates consistency on your OS, all of this will stick out and annoy you. And you'll end up using Apple's Mail.app over GMail's UI.
While the web can be great for RAD, the native side gives you raw control when you want it. And actual desktop UI widgets, like table, list, and windows.
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
...
section {
color: red;
// ... and other basic CSS 2.1 props
display: grid(
rows: ...;
columns: ...;
align-items: center;
justify-items: start
);
}
As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.
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.
Features {
display: block;
padding-left: 1.5em;
list-style-type: disc;
}
Feature {
display: list-item;
}
This comes in very handy with XML.
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.
<button i-was-clicked="false">
<button i-count-clicks>
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.
This might in fact be a valuable insight, I never thought of it.
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).
[...]
But you can’t fix that by adding new APIs with plenty of new concepts. You’re just making things larger and more complex. A few things may be able to live entirely inside the new, clean, modern API, but everything else (including practically everything that came before), will either need to ignore the new thing, or incorporate it (and pay the costs of bridging/composing things that weren’t necessarily designed to work together.
I say figure out how to actually remove old, bad stuff before adding a bunch of new stuff.
I like html/dom/svg/css. There are a couple rough edges. Half of them are from the last time someone tried to rewrite the whole thing (all the namespace aware dom methods)
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.
They'll make you a minister in the UK for that.
I don't think what the author is talking about is necessarily against either. HTML5 can continue its evolutions while "HTML6" (or something completely separate) exists alongside the traditional DOM, like the <canvas> example they reference or like WASM exists alongside JS. From this perspective, the article is about why it's a worthwhile time to make the new thing rather than why the new thing won't also have baggage in 20 years or why we should just throw everything current out the window as part of supporting the new thing.
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 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.
Flexbox also isn't great at all for many, many use cases - its performance absolutely tanks outside of the use case it was designed for, specifically a 1D flow of blocks along an axis. If you want a grid layout, choose the grid layout algorithm.
Any system here must accommodate extremely heterogeneous requirements, so it will inevitably become "bloat". One alternative future you could envision is based on WASM and WebGPU, where each site is essentially an app that pulls in whatever libraries and frameworks it needs to do its work, but that's also pretty far off, since there is not sufficient standardization of the protocols used by WASM UI frameworks.
Not only that, a new system will get completely coopted by the likes of Google for their own purposes. The result of what is built is in large parts a function of the culture that builds it. And I for one have zero interest in the current tech culture building a DOM 2.
Yes, I am generally weary of rewrites.
In all seriousness, isnt this what Java is for? Why would you need to treat a web browser like a virtual machine?
There are many reasons. Performance, ability to bring concepts from other domains, ability to do things browser has no api for, ability to provide controlled experience and behaviour that goes beyond common browser usage.
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.
The author critiques a ~50-year-old set of tech that has been developed piecemeal over those ~50 years to cope with a vast array of different goals and priorities. And proposes their own toy tech as a replacement, with apparently no sense of irony.
HTML was never designed for web apps, but it powers billions of them. CSS was never designed for complex dynamic UIs, but it does the job. If you seriously think "hmm, well this is shit, I can do better" then I invite you to take a seat and actually look at what this shit tech is doing, and maybe step down the arrogance a bit.
The problem is, as always with tech that survives a few years, backwards compatibility combined with mission creep. The author ponders HTML6 removing some redundant stuff. The problem is that you can't remove or change anything because doing that would break 348574793 websites and the people who rely on that stuff working exactly as it does now will complain. Meanwhile people are demanding that they can build 3D models using the same stuff that was originally designed to serve static written documents.
And, just while we're there, the answer to replacing the DOM is not to implement it in shiny new browsers. The browsers aren't the problem, or a route to change. You'd need to get every single website to change. Even the ones written by the company owner's nephew, who then moved country and doesn't talk to his uncle any more, so the website is a bit outdated but no-one knows how to fix it any more. There are approximately 3498573495645 of those.
HTML, CSS, JS, SVG, the DOM, WASM, all of that is miracle tech. Learn from it, study it as an exercise in longevity. Instead of complaining about CSS, learn why it was designed that way, why that particular set of ugly compromises came about. I promise that every single part [0] of all of this tech was debated for weeks by a large room full of very, very, smart people who came up with this solution because it was the only way forward at the time.
And mate, have some humility.
[0] OK, the original first version of HTML was probably not this, and was hammered together by Tim Berners-Lee, who probably never imagined that this would happen to it.
I bet that room never smelled of sunk cost fallacy
This is why "referer" is still mis-spelled in HTTP. To correct it without causing problems, you'd need to alter the code on every router on the planet, simultaneously. It would literally be easier to change the dictionary and every document with the word "referrer" in it.
So, yeah, there's no sunk cost here. It's more like sunk foundations - you're building on top of what has gone before, and you can only build up.
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.
Yes it can. clip-path does just that.
He probably means will-change.
Also, didn’t they effectively invent rendering in canvas (for sheets) about 10 years ago? If they did that, but they still didn’t abandon the DOM, they might have their reasons.
And we need to stop relying on JS so much.
> We spent a decade rebuilding the browser by hijacking routing, manually syncing state, rebuilding forms and transitions in JavaScript to match native app expectations. Now the browser has caught up. It's time to stop the hacks and build on the web again, but properly.
We've been "holding the browser wrong" for the past 10 years.
Unless you're arguing that we should stop cramming app-like behaviour into a system that doesn't support it. Then I'm with you.
Given that even newspaper websites are now built as applications, we should accept that the web is an application platform (with one of those applications being displaying articles) and rework HTML as an application display language. And we need to start relying on JS more.
(Specifically, we should reimplement most traditional HTML elements and CSS as web components on top of a basic core web runtime. Then we could have a small standard for the core web that was practical to implement - just a very minimal layout engine and a JS interpreter - and everything else could be in the "component library" rather than something browser makers had to implement by hand. And then pages that want to use their own components or some other third-party components - which is most pages these days - could skip all that cruft)
The users want to get a document, not an app. That's what the web was made for, documents.
Admittedly even with .war format and other attempts, this was possible only for a brief time. Now we have a crop of readability converters because even print to pdf is useless most of the time.
The apps are mire likely used to hinder ad blockers than benefit the reader.
What feature of an article needs an app?
This could be what we want, but I can't help but think about what we've lost.
Just as it was with Java and Flash.
The web is getting smaller and smaller, being dominated by the bigger players (Google, Microsoft, Apple, et. al) for whom pushing opaque web standards and "applications" benefit only them as gatekeepers.
While it's still entirely possible for people to still build websites, search engines like Google don't prioritize them - leading them to never being discovered. 90% of the web is still the 'small' web and we can't ever discover them because they're not being indexed by Google (why should they? Most of them don't include Google's tracking js scripts ['analytics']).
The web was never supposed to be like this. It's turned into a massive surveillance engine for the big corporations.
I'll leave this here: https://wiby.me
I’m still not entirely sure what this is, but I visited, hit “Surprise Me”, and then spent a couple hours listening to/enjoying the retro-looking pirate radio site I got sent to, so, thanks
It's a completely valid view, and none of it is backwards.
What's backwards is trying to bend a system barely capable of displaying static content to create apps.
So because some websites do shitty things, we should all throw out the standard way of displaying information on the web? Guide me through that line of reasoning. Why are newspaper websites, out of all the websites, the ones which should determine how we do things?
My point is that if there was any category of websites for which a "document" model would work, it would be newspaper websites. When even those take an "application" approach, it's time to admit that the "document" model is a failure.
News sites are meant to be read, therefore they are "documents." They are also applications, because all websites, even static ones, are also applications. Once you add hyperlinks and external resources, it ceases to be purely a document.
Adding a script tag to an HTML page doesn't transform it from one to the other.
I remember the older days (2005-8) when we would dump a load of HTML from the server-side and kept javascript (for the most part) managing the layout and, not to mention, coding the painful differences between browsers.. even IE6 to IE7.
As Javascript (likely thanks to jQuery for starters) got better with AJAX and supporting different browsers with less code, it seems Javascript transitioned to be a owner of data with events and triggers. As for the serverside, transitioned away from returning HTML but XML or the common Json data.
Away from jQuery (or alongside it) we ended up with Javascript frameworks leading to bindings or automated refresh of data with template views, etc. Things like mustache.js to knockoutjs to angularjs.
Now - its React, with node package managers, even grunt... to name a few... appear to be needed tools for web development these days. Its like we are just HIDING web development to an application. Underneath it all still remains the basics of HTML, CSS, Javascript -- and its relationship with the serverside language.
I will admit. In the early days of HTML development.. I hated it! Its not the HTML side of things, but the tools I had to use like Classic ASP or supporting different browsers. If we do web development today like its 2005... with modern programming languages and web browsers, "old school" web development is a joy.
In the last few years, I jumped back to the serverside generating the HTML again. I can still do "simple page" applications with AJAX returning a portion of HTML, etc.
When I explain this reasoning with other developers, I get a confused look on their face. I try to explain to them that the backend code has not changed. Its just an extra layer of returning the data back as HTML, rather than Json. It sounds like more but all it does it organise your HTML templates on the serverside, rather than just having it all done on the clientside.
Since then I have added htmx to the mix, which IMO compliments this original approach. I have made successful projects with it though I dont think I have won the co-workers. I dont think its because its the old school way or htmx -- its just they are so accustomed to the modern approach of web development.
This is what I always bring up to web devs who think theyve captured the "write once, run anywhere" dragon
I was on the mobile app side, as possible way to turn the balance around, but then everyone started shipping Cordova and Ionic apps.
We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.
This is the way I lean too. So much of what web apps do is just reinventing the wheel of desktop GUI toolkits, only worse, because each one does it in its own way, rather than all having a consistent look and feel.
And now leave a comment for when I inevitably forget again.
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>.
We don't have to force a round peg into the square hole <!DOCTYPE html>. Let's make a new round hole <!DOCTYPE app> but keep using the amazing deployment platform.
edit: if you can program