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.
While the web has grown complex in line with increasingly complex applications, the platform is also undeniably bloated, precisely because every new feature (like HTML in Canvas proposal) has to be shoehorned into an already very fragmented puzzle. Backwards compatibility has become an idealistic badge of honor rather than a technical feat. I believe the article does a good job at getting into the technical parts that are in fact not so remarkably robust, despite the web's organic growth. Even a bonsai tree needs to be pruned every once in a while. And while there will never be One Correct Way the way we engineer interfaces have converged a lot since the days of Flash meaning we can at least move the conversation forward in the Mostly Agreed Upon Way.
It’s frustrating to me that we don’t have more directives. I’m simply spitballing however, here’s some examples:
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
> We have <!doctype html> but why not add other doc types as time goes on
We do have older ones!
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
and
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Unfortunately the "be liberal in what you accept" principle, in combination with general incompetence and anti-competitive practices by certain browser vendors, meant that all the browsers kind of ignored it and treated everything as quasi-structured tag soup regardless of the doctype, which is why WHATWG tried to codify what the browsers were already doing and decided we should all just <!doctype html>.
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.
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.
I wouldn’t say that it’s not bloated or that it does not deserve to shed some legacy functionality, but I’m impressed at how it’s not more bloated and dysfunctional, given circumstances.
I'm reminded of how in the modular synthesis world Eurorack has standard 4U sizes but still allows other unit sizes to be fitted (e.g. 1U, 5U). Similarly, voltages and connections can be tweaked to your own content, as long as there exist appropriate adapters and converters in between.
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.
> I struggle to imagine how it could realistically be not complex.
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.
And how about blind people, bots, accessibility in general? I don't remember java and flash handling different screen resolutions like desktop, tablets, and phones.
Yes, because the author of the comment didn’t explicitly carve out a moment to comment that Java/Flash were not great for accessibility, it must mean that in their hypothetical world where web applications that needed rich interaction and client side processing where based on Java/Flash type runtimes, it would have stayed shit for accessibility.
I’m sure the person you were referring to doesn’t want to make the web shit for the blind. Calm down
I think it's a reasonable take after 15 years of seeing CSS/HTML/JS being abused for everything and more (when all you have is a hammer…), with the result being that many simple static pages are nowadays monstrous JS apps. My conviction is that, had those technologies stayed simple and focused on delivering the "Document" use-case, turning everything into an app would be a much bigger bridge to cross.
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.
I would argue that a good layout engine for pages could see good use. See Gemini/Gopher—people like minimalism, but having to use a separate browser makes it probably too niche.
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.
Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned.
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.
Regarding security: I think this is already managed in the iOS/Android ecosystem. It shouldn't be too difficult to restrict permissions from sites, and has the advantage of possibly allowing accesses for sites you trust.
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.
True those platforms have security controls, better than what we've ever seen on desktop. Desktop also needs controls like that: to use the system tray, filesystem, hardware, etc. There's at least a work multiplier of 3 for Windows, Mac, Linux. It's just one of many things needed.
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.
Hard disagree. Lots exist but none are great. Usually layout isn't sane. Another blunder is components are too complex with too many layers. Customization and creating your own components becomes difficult. Often the event system is terrible.
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.
Swing layout was bad then (gridbaglayout!) and is bad now. The framework's approach is bad. Components provide min, pref, max sizes that are very often just ignored. Components need a layout mystery object in order to participate. The mechanisms to measure and constrain components sizes and positions is bad. None of the layouts are sane and it's difficult to add your own. 95% of layouts are nonoverlapping components arranged in row and columns, but provided layouts do other things.
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.
But we have more than one OS in the world, how would you think your one framework approach is going to fit in all platform?
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.
We had multiple implementations of Java, but if still failed for that reason. Even if the concerns had been completely addressed MS did not only want to stop Oracle taking control, it wanted to establish control itself.
Was Java any worse from a security point of view than what we have now?
Yes, significantly. The JVM just flat out does not provide a sandbox. Remember the bad old days of clicking on a suspicious link and getting pwnd? That's what we'd have if it weren't for modern JavaScript engines
I suppose it had, but as a large codebase written in a memory-unsafe language with unrestricted system access, in an era where browser plugins weren't sandboxed by design, it was a cat and mouse game.
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.
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.
For the record, I’d prefer native unstyled widgets in sites too, but that ship has already sailed so I figure it’s best if web devs can do things like have a custom styled popup menu with proper keyboard navigation, accessibility, etc without having to pull in a mountain of wheel reinventing JS.
I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose.
Still, it's quite sad how long we had to wait for stylable checkboxes.
Personally, for something like this I’m not sure that getting consensus really matters or is even desirable (death by design by committee is real). Just pick a direction and go. If it’s sufficiently good it’ll catch on and blossom from there, if it doesn’t go back to drawing board and try again.
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.
> ...if it doesn’t go back to drawing board and try again.
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.
The new APIs wouldn’t be for everybody in the early stages and that’s fine. It’s impossible to build something that everybody can get on board with from day one. There will be early adopters who are willing to pay the price of admission.
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.
I mean, experimental APIs do get built this way, and some get adopted and some do not.
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.
> a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS.
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.
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.
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.
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.
Text layout and typography (text-wrap: pretty comes to mind), for example. Sure, a lot might be possible if you call out of VB and embed another runtime, but out of the box Web is pretty damn batteries includes relative to VB, I think.
OK fair enough. I meant really functionality of crud apps where there usually isn't a lot of text and if there is vb is good enough. Of course you can always put a browser control in your form for what browsers do best.
> 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.
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.
TBF, Turbo Vision was also a better toolkit than most of what was available for '90s GUI systems. Or a lot of '00 GUI systems.
...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.
As for the vertical centering, trying this 20 years ago, it was a pain in the ass. These and layouting in general got massively simplified in the past 20 years. Remember that back then, everything was cramped into tables? I do. So if someone tells me, "DOM, HTML and CSS is becoming more and more difficult" just tells me to ignore their amateurish and unfounded opinion... Hah!
Even if using { display: grid }, or a combination of flex rules, hardly seems like an ideal solution, considering there does exist { text-align: center } (which, incidentally, doesn’t only align the text!), I do agree with the general point. Today it is reasonably easy to make quite complex grid-driven layouts; not easy—often, if not always, making a complex thing easy requires also making it restrictive and opinionated—but perhaps easy enough considering the end result.
20 years ago it was much easier, you could ethically use tables for layouts which semantically did not make much sense, but in terms of code structure it was very simple: this table is the full size of the page, this cell is the header with this height, this cell is the sidebar with this width, this cell occupies the rest of the space with content positioned in the middle, all expressible without any styling at all.
This sounds crazy to me, the flex system is exactly this but also semantically correct. You can’t possibly be telling me that table hacks of yore are easier than this, a clearly designed system for the actual problem you want to solve https://css-tricks.com/wp-content/uploads/2022/02/css-flexbo...
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)
No, tables are the right solution: nonoverlapping elements arranged in a sane way that is easy to reason about. The arguments about semantics so everything can be a div are hilarious -- it really doesn't matter.
Flex is great but tables are also a natural solution for anything grid-based, which of course layouts almost always are. The whole internet used to do stuff like this before the structural flow of content became important:
GP is also wrong anyway, CSS Flex is the wrong thing for creating layouts like this. We now have CSS Grid, which is the actual replacement for table-based layouts (which were used more recently than people like to admit because of Flex not working for two-dimensional layouts).
Sorry, I often conflate flex and grid, they occupy the same spot in my mind as “1 dimensional” and “2 dimensional” versions of the same underlying thing. I am wrong.
Not 20 years ago and not now because it makes no sense to blind people using screen readers.
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 really wish this was true. Sadly the caniemail website - https://www.caniemail.com/ - says that Gmail still doesn't support CSS grid or flex, which leaves nested tables for layout as the only viable solution for HTML emails (which, however many times you plead with your marketing colleagues, is still their preferred way for contacting/stalking customers).
> 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 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.
Flutter is amazing exactly because it was a response to the problem of creating modern cross-platform apps for the modern zoo of hardware. The text typesetting engine from the 80s is clearly not a good foundation for it.
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.
Text selection is such a great example precisely because it is incredibly useful to have in many unexpected situations (and a great many more that should be expected), but UI designers as a rule do not think about these situations!
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!
> Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
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.
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.
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.
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 have no idea why, but tree models scare the shit out of college educated developers.
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.
This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors.
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.
"In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory."
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.
Or, more likely, it’s a traversal of a data structure already in memory. If so, then it is a very real operation executing as fast as reported, at near memory speed.
You can't even "traverse" a data structure at that speed. We're talking low-single-digit cycles here. A compiled for loop tends to require two cycles just to loop (you need to increment, compare, and jump back but the CPU can speculate the loop will in fact jump back so the three operations can take two cycles), and I don't know what the minimum for a JS-engine JIT'd loop is but needing 4 or 5 wouldn't stun me. That's literally the "compiled loop do-nothing speed".
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.
I have experienced numerous conversations about performance with people who invent theories while never actually measuring things. Typically this comes from students.
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.
Sure, go ahead and show me your "data structure traversal", in Javascript (JIT'd is fine, since clearly non-JIT is just out of the question), that works in 3-5 cycles.
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.
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.
> All these excuses, especially about vanity, are masking behaviors.
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.
Well, no. First of all visual rendering is an aside not directly relevant to the DOM, a data structure.
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 are two kinds of visual operations that can occur from a DOM change: a screen repaint or a local change.
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.
I closed my web dev business just three years ago. I found that many people who work with the web don't want to do the work to understand how it all works. They think there must be a library somewhere to do "that" while doing "that" is simple enough using standard components and features.
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.
The reason WASM does not have dom access is that many recent DOM APIs return and expect javascript objects and classes like iterators, so you would still need some thin js glue wrapper between the dom and wasm. Security has nothing to do with it as (performace aside) wasm+minimal js glue can already do anything js can do
> For WASM to become a replacement it would have to gain full DOM access to the containing page.
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.
> 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.
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 point of WASM is a universal compile target that executes a sandbox. That is all.
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.
I always think of WASM as being like a C FFI. Something you reach out when your module is too slow by being JavaScript. Kinda how Python bind to almost every library in C and C++.
Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.
Modern JS executes at about the same speed as Java or about 25% C language speed. A JavaScript application is often faster to initialize into memory than a C language application, largely because less overhead is required for application initialization, but otherwise slower because JS is garbage collected.
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.
And that’s why it’s ten years old and just getting traction now. Until it has DOM access nobody working on the front end will be particularly enthused about its utility.
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.
> And that’s why it’s ten years old and just getting traction now.
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.
Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.
State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.
What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.
Reactivity is just one pattern to help manage state. We have observable (which is just reactivity in another cloth), Entity-Component, View-Model (also Presenter), etc,…
React isn’t about persistence between page loads. React is about declaratively declaring two different page states and “diffing” them so that only the diffs are applied to the DOM.
Storing the diffs to local storage is an interesting idea though.
Svelte seems to do this just fine. It's much simpler to work with, doesn't introduce too much proprietary code, and is both lightweight and incredibly fast.
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 totally agree. I don't get why people feel so strongly that native apps are better. The web technologies we have are great both from a developer experience perspective and a UX perspective. People hate on electron apps but I think this is mostly due to bloat from electron. I hope Tauri closes the gap it's been great for me so far.
There are some great native apps out there and a lot of them do things you couldn't do on the web, but nowhere near close seems like a stretch to me. There are some great web apps out there. And while there are great native apps made with love there are also perfunctory, rushed, clunky ones that could have just been a website.
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.
They never look and feel exactly like native apps, even the ones that try a bit.
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.
Things.app, Bear.app, and a few others from the macOS side are nice example of UX.
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.
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:
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.
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.
First Ajax/jquery app I worked on got a lot simpler and a lot less buggy when we started storing state in the DOM. It’s way too easy to miss a state shift in a toggle operation and have the UI be in exactly the opposite state from the api.
Agreed. The idea that moving state out of the document is a touch frustrating to me. Seemed to me that the entire point of a tree of data was to store the state as data?
Yes, but not in the sense of dumping serialized JSON into HTML. It ends up being represented by custom HTML attributes and their values. For example, if you need to keep track if the user clicked on some button, you might represent it as follows:
<button i-was-clicked="false">
or
<button i-count-clicks>
The content of the attribute becomes "1" after the first click and keeps increasing. The job of the corresponding JS code would be purely to keep track of clicks, so it would be very simple. Meanwhile, the value could be used for a variety of different tasks (including in CSS) and the exact same library could be applied to any element without any modification or writing "glue code".
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.
> 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.
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).
The DOM is too large and complex, with so many APIs and concepts.
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 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.
This feels like one of those rewrites where the moment you actually tried to do it, it would became very clear why the status quo is the way it is.
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)
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.
> 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.
Backwards compatibility is given in HTML by the doctype. I think you might also really be talking to forwards compatibility in addition - "what I would write in an HTML 4 document will (almost) always work the same in an HTML 5 document".
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.
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.
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.
kinda the point - if you've got a bajillion users who are using the thing you're hoping to change, you have a strong limitation that you can't change anything that they're currently using. You have to maintain backward compatibility.
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.
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.
I don't know exact what system you have in mind, but writing a performant shader is hard. Requiring that designers attach arbitrary shader code to HTML elements is an easy way to absolutely tank the performance of the web.
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.
I wouldn't expect devs to be writing their own shaders all the time - the browser could have standard shaders, and no doubt libraries would crop up that offer more.
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.
> 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.
> 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.
The article isn't complete/correct.
Something did change with HTML.
Since 2018 every browser interprets ANY <tag-name> with a dash as a valid HTMLElement, not HTMLUnknownElement.
Absolutly NO JavaScript required to turn the DIV-soup into
<semantic-html> and CSS
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.
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.
anyone had experience where assembly is not actually faster than optimized js when it’s clean like for example when working on preallocated memory in buffer because v8 optimizer is that good?
They’re possibly the most significant web-app developer, so if things were really that broken you’d think they’d be the first to fix it.
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.
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.
This view is completely backwards and I'm baffled by its popularity.
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)
I get this viewpoint from a software architecture level, but that is also effectively the death of the open web. When every website is an opaque app, even often requiring a client-side optimizing compiler that builds an arbitrary binary in order to load (WASM), we can say goodbye to things like search engines and typically also hyperlinks. The rise of social media has already balkanized the web a lot, where almost all content is locked behind a login screen.
This could be what we want, but I can't help but think about what we've lost.
Search engines already run JavaScript to understand the pages they're indexing. Android apps manage to deep-link into each other effectively despite being applications. Designing tools and standards that work well with what we have is far better than trying to hold back the tide.
That's because you're looking at it from the perspective of what the developers of those news websites want, rather than what the users of those news websites want.
The users want to get a document, not an app. That's what the web was made for, documents.
As a user I want to be able to save the page and read it later.
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.
> Given that even newspaper websites are now built as applications, we should accept that [...]
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?
> 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.
There is no "document" or "application" model, the distinction is mostly just vibes.
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.
Agree that it's all vibes-based, but look at how the newspapers understand their own sites - in particular, what they consider to be an "article", how they edit those articles, and the pipeline from that to the article being rendered in the end user's browser.
Many websites have no business being a full-blown application.
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’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
at that point just learn a programming language man. the inception like dreams within dreams within virtual machines running other virtual machines will never stop because CPU power will always increase
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.
> 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.
"Web apps" should have been standard desktop apps with a network connection. You don't need a browser to use network protocols (and protocols died when HTTP stopped sending hypertext and started to send JSONs) or call APIs. Your OS manages the network stack.
We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.
> "Web apps" should have been standard desktop apps with a network connection.
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.
As someone coding since 1986, and since 1999 has done more Web related projects than native ones, that is my point of view exactly, unfortunely we kind of are in the minority.
I was on the mobile app side, as possible way to turn the balance around, but then everyone started shipping Cordova and Ionic apps.
Every big tech company is too afraid to fundamentally rewrite the front-end of the internet even though they’ve all produced wonderful alternatives to varying degrees (TypeScript, Dart, Silverlight, etc). Most likely because they don’t want to be targeted as antitrust like MS back in the day.
Ugh I love this website and a year ago I was desperately trying to remember the name - trying to describe the concept to chatbots trying to get a lead. I just had to wait around to run into it on HN again.
And now leave a comment for when I inevitably forget again.
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>.
or maybe just stop trying to force the round peg in a square hole. an application is surely not a document. they open documents. its conceptual, but it would make your life so much easier if you stopped trying to make a fully fledged platform out of what was essentially a rich text document viewer. java has since come along and given you pretty much write once, run anywhere and close to instant deployment with its applets
Web as a deployment platform has too many advantages for it to be ignored for distributing _anything_.
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.
If it was, it would reflect in reality. But the web wins the "where shall we deploy this" fight every single time. For good reason. You mentioned java, People preferred literally electron over java.
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.
While the web has grown complex in line with increasingly complex applications, the platform is also undeniably bloated, precisely because every new feature (like HTML in Canvas proposal) has to be shoehorned into an already very fragmented puzzle. Backwards compatibility has become an idealistic badge of honor rather than a technical feat. I believe the article does a good job at getting into the technical parts that are in fact not so remarkably robust, despite the web's organic growth. Even a bonsai tree needs to be pruned every once in a while. And while there will never be One Correct Way the way we engineer interfaces have converged a lot since the days of Flash meaning we can at least move the conversation forward in the Mostly Agreed Upon Way.
It’s frustrating to me that we don’t have more directives. I’m simply spitballing however, here’s some examples:
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
> We have <!doctype html> but why not add other doc types as time goes on
We do have older ones!
and Unfortunately the "be liberal in what you accept" principle, in combination with general incompetence and anti-competitive practices by certain browser vendors, meant that all the browsers kind of ignored it and treated everything as quasi-structured tag soup regardless of the doctype, which is why WHATWG tried to codify what the browsers were already doing and decided we should all just <!doctype html>.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.
But umm, why would you want that?
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.
I wouldn’t say that it’s not bloated or that it does not deserve to shed some legacy functionality, but I’m impressed at how it’s not more bloated and dysfunctional, given circumstances.
I'm reminded of how in the modular synthesis world Eurorack has standard 4U sizes but still allows other unit sizes to be fitted (e.g. 1U, 5U). Similarly, voltages and connections can be tweaked to your own content, as long as there exist appropriate adapters and converters in between.
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.
> I struggle to imagine how it could realistically be not complex.
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.
You'd still have all the same backwards compatibility problems with the "Web for applications" stdlib and UI framework as we do now.
You just use the novel solution of downloading the whole thing as an applet.
And how about blind people, bots, accessibility in general? I don't remember java and flash handling different screen resolutions like desktop, tablets, and phones.
Yes, because the author of the comment didn’t explicitly carve out a moment to comment that Java/Flash were not great for accessibility, it must mean that in their hypothetical world where web applications that needed rich interaction and client side processing where based on Java/Flash type runtimes, it would have stayed shit for accessibility.
I’m sure the person you were referring to doesn’t want to make the web shit for the blind. Calm down
To them the web probably isn't much more than doomscrolling video content.
Nobody would be using webpages version and everybody would be using app version.
I think it's a reasonable take after 15 years of seeing CSS/HTML/JS being abused for everything and more (when all you have is a hammer…), with the result being that many simple static pages are nowadays monstrous JS apps. My conviction is that, had those technologies stayed simple and focused on delivering the "Document" use-case, turning everything into an app would be a much bigger bridge to cross.
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.
I would argue that a good layout engine for pages could see good use. See Gemini/Gopher—people like minimalism, but having to use a separate browser makes it probably too niche.
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.
I would love to use the web pages version, both as a user and on websites.
I struggle to see the reason why web pages and apps are even two different things.
The browser is really just a cross-platform platform for building applications.
Yes, a terrible one. That's what the article is about.
What I mean is, I dont see why browsers even exist.
There should be a singlular framework for creating desktop apps.
Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned.
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.
Regarding security: I think this is already managed in the iOS/Android ecosystem. It shouldn't be too difficult to restrict permissions from sites, and has the advantage of possibly allowing accesses for sites you trust.
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.
True those platforms have security controls, better than what we've ever seen on desktop. Desktop also needs controls like that: to use the system tray, filesystem, hardware, etc. There's at least a work multiplier of 3 for Windows, Mac, Linux. It's just one of many things needed.
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.
Plenty of great UI toolkits exist.
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.
Hard disagree. Lots exist but none are great. Usually layout isn't sane. Another blunder is components are too complex with too many layers. Customization and creating your own components becomes difficult. Often the event system is terrible.
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.
Swings layout stuff was fine, better in 2004 than anything the web had until 2020 at least.
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 layout was bad then (gridbaglayout!) and is bad now. The framework's approach is bad. Components provide min, pref, max sizes that are very often just ignored. Components need a layout mystery object in order to participate. The mechanisms to measure and constrain components sizes and positions is bad. None of the layouts are sane and it's difficult to add your own. 95% of layouts are nonoverlapping components arranged in row and columns, but provided layouts do other things.
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.
> There should be a singlular framework for creating desktop apps.
Why?
Well why have two completely different ecosystems for the wbe and desktop/mobile applications, especially in terms of UI? Both can network
But we have more than one OS in the world, how would you think your one framework approach is going to fit in all platform?
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.
Very true, I am speaking merely in ideal terms.
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.
There is. It's called a "browser"
We had multiple implementations of Java, but if still failed for that reason. Even if the concerns had been completely addressed MS did not only want to stop Oracle taking control, it wanted to establish control itself.
Was Java any worse from a security point of view than what we have now?
Yes, significantly. The JVM just flat out does not provide a sandbox. Remember the bad old days of clicking on a suspicious link and getting pwnd? That's what we'd have if it weren't for modern JavaScript engines
I thought the JVM had permissions restrictions in the days of Java applets?
I suppose it had, but as a large codebase written in a memory-unsafe language with unrestricted system access, in an era where browser plugins weren't sandboxed by design, it was a cat and mouse game.
[dead]
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.
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.
For the record, I’d prefer native unstyled widgets in sites too, but that ship has already sailed so I figure it’s best if web devs can do things like have a custom styled popup menu with proper keyboard navigation, accessibility, etc without having to pull in a mountain of wheel reinventing JS.
I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose.
Still, it's quite sad how long we had to wait for stylable checkboxes.
Personally, for something like this I’m not sure that getting consensus really matters or is even desirable (death by design by committee is real). Just pick a direction and go. If it’s sufficiently good it’ll catch on and blossom from there, if it doesn’t go back to drawing board and try again.
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.
> ...if it doesn’t go back to drawing board and try again.
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.
The new APIs wouldn’t be for everybody in the early stages and that’s fine. It’s impossible to build something that everybody can get on board with from day one. There will be early adopters who are willing to pay the price of admission.
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.
I mean, experimental APIs do get built this way, and some get adopted and some do not.
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.
you have put into words a feeling that has been burning in my chest for 20+ years :-)
I cry at the ways we are doing and defining column tables.
> a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS.
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.
There’s still large gaps that need to be filled.
> 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.
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.
So instead of writing an app once I can write it ten times once for each native platform.
I AM SOLD
Agreed. It would also help if the primitives were correctly thought through to begin with.
HTML5 input and form validation are still a broken nightmare that can barely be patched by adding copious amounts of JavaScript.
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.
Visual Basic was a much simpler dev environment 30 years ago already. I was hoping with WASM we'd get something similar, but I'm still waiting.
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.
Visual Basic is significantly less featureful.
Any examples of what the web does better? I can't think of any, esp with activex controls where you could plug in any third party component.
Text layout and typography (text-wrap: pretty comes to mind), for example. Sure, a lot might be possible if you call out of VB and embed another runtime, but out of the box Web is pretty damn batteries includes relative to VB, I think.
OK fair enough. I meant really functionality of crud apps where there usually isn't a lot of text and if there is vb is good enough. Of course you can always put a browser control in your form for what browsers do best.
> 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.
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.
TBF, Turbo Vision was also a better toolkit than most of what was available for '90s GUI systems. Or a lot of '00 GUI systems.
...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.
As for the vertical centering, trying this 20 years ago, it was a pain in the ass. These and layouting in general got massively simplified in the past 20 years. Remember that back then, everything was cramped into tables? I do. So if someone tells me, "DOM, HTML and CSS is becoming more and more difficult" just tells me to ignore their amateurish and unfounded opinion... Hah!
Even if using { display: grid }, or a combination of flex rules, hardly seems like an ideal solution, considering there does exist { text-align: center } (which, incidentally, doesn’t only align the text!), I do agree with the general point. Today it is reasonably easy to make quite complex grid-driven layouts; not easy—often, if not always, making a complex thing easy requires also making it restrictive and opinionated—but perhaps easy enough considering the end result.
20 years ago it was much easier, you could ethically use tables for layouts which semantically did not make much sense, but in terms of code structure it was very simple: this table is the full size of the page, this cell is the header with this height, this cell is the sidebar with this width, this cell occupies the rest of the space with content positioned in the middle, all expressible without any styling at all.
This sounds crazy to me, the flex system is exactly this but also semantically correct. You can’t possibly be telling me that table hacks of yore are easier than this, a clearly designed system for the actual problem you want to solve https://css-tricks.com/wp-content/uploads/2022/02/css-flexbo...
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)
No, tables are the right solution: nonoverlapping elements arranged in a sane way that is easy to reason about. The arguments about semantics so everything can be a div are hilarious -- it really doesn't matter.
Flex is great but tables are also a natural solution for anything grid-based, which of course layouts almost always are. The whole internet used to do stuff like this before the structural flow of content became important:
GP is also wrong anyway, CSS Flex is the wrong thing for creating layouts like this. We now have CSS Grid, which is the actual replacement for table-based layouts (which were used more recently than people like to admit because of Flex not working for two-dimensional layouts).
Sorry, I often conflate flex and grid, they occupy the same spot in my mind as “1 dimensional” and “2 dimensional” versions of the same underlying thing. I am wrong.
Bring back the 90's. ;) The memories of spacer gifs...
I still find myself missing Macromedia Fireworks on occasion!
Not 20 years ago and not now because it makes no sense to blind people using screen readers.
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.
You can still do this if you want, table element still exists and works the same way.
Well yeah but no self-respecting developer has done this for 15 - 20 years... it's kind of a red flag these days!
I really wish this was true. Sadly the caniemail website - https://www.caniemail.com/ - says that Gmail still doesn't support CSS grid or flex, which leaves nested tables for layout as the only viable solution for HTML emails (which, however many times you plead with your marketing colleagues, is still their preferred way for contacting/stalking customers).
[dead]
people say this about inline styles too but Notion built a 100 million user business with them ¯\_(ツ)_/¯
> 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 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
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.
Flutter is amazing exactly because it was a response to the problem of creating modern cross-platform apps for the modern zoo of hardware. The text typesetting engine from the 80s is clearly not a good foundation for it.
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.
You had a great comment I had saved last time this topic came up: https://news.ycombinator.com/item?id=41981458
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.
Text selection is such a great example precisely because it is incredibly useful to have in many unexpected situations (and a great many more that should be expected), but UI designers as a rule do not think about these situations!
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!
+ even when websites decide to be a pain and block text selection/copying, you can fix that with extensions.
Extension not necessary:
In Chrome, open DevTools, Shift+Ctrl+P > Disable JavaScript
CSS can prevent selection.
> Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
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.
Agree with all of this
> 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.
Is Flutter as accessible as HTML out of the box? Or even compared to Win32 or MacOS APIs?
Not out of the box and not even with effort.
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.
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 have no idea why, but tree models scare the shit out of college educated developers.
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.
This is exactly what I am talking about. All these excuses, especially about vanity, are masking behaviors.
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.
"In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory."
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.
Or, more likely, it’s a traversal of a data structure already in memory. If so, then it is a very real operation executing as fast as reported, at near memory speed.
You can't even "traverse" a data structure at that speed. We're talking low-single-digit cycles here. A compiled for loop tends to require two cycles just to loop (you need to increment, compare, and jump back but the CPU can speculate the loop will in fact jump back so the three operations can take two cycles), and I don't know what the minimum for a JS-engine JIT'd loop is but needing 4 or 5 wouldn't stun me. That's literally the "compiled loop do-nothing speed".
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.
I have experienced numerous conversations about performance with people who invent theories while never actually measuring things. Typically this comes from students.
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.
Sure, go ahead and show me your "data structure traversal", in Javascript (JIT'd is fine, since clearly non-JIT is just out of the question), that works in 3-5 cycles.
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.
I am not preventing you from measuring things. The burden of proof is equally on everybody concerned with speed.
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.
> All these excuses, especially about vanity, are masking behaviors.
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 so much as change an element border (which may trigger a full re-layout of the entire page)
This is easily avoided: use 'outline' instead of 'border', or just keep the border width fixed and change the border color to/from transparent.
> This is easily avoided: use 'outline' instead of 'border'
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".
Well, no. First of all visual rendering is an aside not directly relevant to the DOM, a data structure.
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 are two kinds of visual operations that can occur from a DOM change: a screen repaint or a local change.
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.
[dead]
I closed my web dev business just three years ago. I found that many people who work with the web don't want to do the work to understand how it all works. They think there must be a library somewhere to do "that" while doing "that" is simple enough using standard components and features.
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.
I found the same at my last two tech jobs (S&P 100 and 500). People hate getting their hands dirty with fundamental web dev.
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.
The reason WASM does not have dom access is that many recent DOM APIs return and expect javascript objects and classes like iterators, so you would still need some thin js glue wrapper between the dom and wasm. Security has nothing to do with it as (performace aside) wasm+minimal js glue can already do anything js can do
> For WASM to become a replacement it would have to gain full DOM access to the containing page.
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.
> 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.
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 point of WASM is a universal compile target that executes a sandbox. That is all.
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.
I always think of WASM as being like a C FFI. Something you reach out when your module is too slow by being JavaScript. Kinda how Python bind to almost every library in C and C++.
Not so usuful for CRUD, but imagine building some node based editor, you can out the solver in WASM.
Modern JS executes at about the same speed as Java or about 25% C language speed. A JavaScript application is often faster to initialize into memory than a C language application, largely because less overhead is required for application initialization, but otherwise slower because JS is garbage collected.
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.
And that’s why it’s ten years old and just getting traction now. Until it has DOM access nobody working on the front end will be particularly enthused about its utility.
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.
> And that’s why it’s ten years old and just getting traction now.
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.
The reason working with the DOM directly is hard is that you have to implement arbitrary patching to go from one state to another.
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.
Yeah, I prefer vanilla DOM and I don't have any problems with state. State is as ridiculously simple as storing state of user interactions to an object, saving that to somewhere like localStorage, and the applying it on page load. React makes this ant hill into a mountain of complication.
State can be easy when you’re talking about document-based app (forms and content). But it can become quite hard when talking about some long lived interactions and the state diagram becomes difficult to draw. React (the library, not the ecosystem) make it easy to deal with that case. Otherwise you have to write bespoke reactive code. Not that difficult, bit it’s buy VS build.
What about an OS GUI with windows an various different types of utilities? State was still just as simple. The content and utility of the application had no bearing on how state management worked.
Reactivity is just one pattern to help manage state. We have observable (which is just reactivity in another cloth), Entity-Component, View-Model (also Presenter), etc,…
Ever use knockout.js?
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.
React isn’t about persistence between page loads. React is about declaratively declaring two different page states and “diffing” them so that only the diffs are applied to the DOM.
Storing the diffs to local storage is an interesting idea though.
Svelte seems to do this just fine. It's much simpler to work with, doesn't introduce too much proprietary code, and is both lightweight and incredibly fast.
> Browser makers have refused to do that for clear security reasons.
Because only javascript should be allowed to screw up that badly.
some of the worst dom api were designed with java compatibilty in mind
So its the java prefix that matters ;)
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 totally agree. I don't get why people feel so strongly that native apps are better. The web technologies we have are great both from a developer experience perspective and a UX perspective. People hate on electron apps but I think this is mostly due to bloat from electron. I hope Tauri closes the gap it's been great for me so far.
The UX is nowhere near close to native apps, particularly on platforms that take UX seriously like macOS, iOS or Gnome.
There are some great native apps out there and a lot of them do things you couldn't do on the web, but nowhere near close seems like a stretch to me. There are some great web apps out there. And while there are great native apps made with love there are also perfunctory, rushed, clunky ones that could have just been a website.
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.
Can you give some examples, please? I can't think of a single thing that cannot be overcome by good design.
They never look and feel exactly like native apps, even the ones that try a bit.
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.
Things.app, Bear.app, and a few others from the macOS side are nice example of UX.
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.
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:
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.
Why does it matter? Its not like im doing a for..in loop over Element objects.
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.
You can create any arbitrary tag for an element and it will be treated like a span until you define its appearance with CSS.
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.This comes in very handy with XML.
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.
Conflating presentation and data seems like a classically Bad Idea. Changes to presentation break your business logic.
Your business logic should be behind a server.
The parent comment is talking about storing app state in the DOM. That's conflating data with presentation, which is a bad idea.
First Ajax/jquery app I worked on got a lot simpler and a lot less buggy when we started storing state in the DOM. It’s way too easy to miss a state shift in a toggle operation and have the UI be in exactly the opposite state from the api.
Agreed. The idea that moving state out of the document is a touch frustrating to me. Seemed to me that the entire point of a tree of data was to store the state as data?
so do you stringify all your state?
Yes, but not in the sense of dumping serialized JSON into HTML. It ends up being represented by custom HTML attributes and their values. For example, if you need to keep track if the user clicked on some button, you might represent it as follows:
or The content of the attribute becomes "1" after the first click and keeps increasing. The job of the corresponding JS code would be purely to keep track of clicks, so it would be very simple. Meanwhile, the value could be used for a variety of different tasks (including in CSS) and the exact same library could be applied to any element without any modification or writing "glue code".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.
> 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.
https://news.ycombinator.com/item?id=34304655
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).
[...]
The DOM is too large and complex, with so many APIs and concepts.
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 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.
This feels like one of those rewrites where the moment you actually tried to do it, it would became very clear why the status quo is the way it is.
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)
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.
> 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.
It can have such a reason to be the way it is, and still be bad.
[reads the HTML Standard] this is hate speech, essentially
Backward compatibility can (most likely) be achieved with a dom.js polyfill library which sits on top of that hypothetical new middle-layer thingie.
Backwards compatibility is given in HTML by the doctype. I think you might also really be talking to forwards compatibility in addition - "what I would write in an HTML 4 document will (almost) always work the same in an HTML 5 document".
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.
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.
Very nice post. Maybe the best micro CSS basics explanation I've ever seen
This is satire, right? I mean, it has to be.
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.
> every single part of all of this tech was debated for weeks by a large room full of very, very, smart people
I bet that room never smelled of sunk cost fallacy
kinda the point - if you've got a bajillion users who are using the thing you're hoping to change, you have a strong limitation that you can't change anything that they're currently using. You have to maintain backward compatibility.
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.
I feel like people are slowly coming round to web components though...
No, they really don't.
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.
I don't know exact what system you have in mind, but writing a performant shader is hard. Requiring that designers attach arbitrary shader code to HTML elements is an easy way to absolutely tank the performance of the web.
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.
I wouldn't expect devs to be writing their own shaders all the time - the browser could have standard shaders, and no doubt libraries would crop up that offer more.
I smell second system syndrome.
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.
I'd vote for something along the lines of QML or Slint for defining UIs; business logic should be purely done in WASM.
> 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.
> I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications?
In all seriousness, isnt this what Java is for? Why would you need to treat a web browser like a virtual machine?
> 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.
The article isn't complete/correct. Something did change with HTML. Since 2018 every browser interprets ANY <tag-name> with a dash as a valid HTMLElement, not HTMLUnknownElement. Absolutly NO JavaScript required to turn the DIV-soup into <semantic-html> and CSS
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.
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.
What do you think of flutter? That was my first thought when you mentioned HTML on Canvas.
i remember hearing html was dead in 2001
> SVG can e.g. do polygonal hit-testing for mouse events, which CSS cannot
Yes it can. clip-path does just that.
anyone had experience where assembly is not actually faster than optimized js when it’s clean like for example when working on preallocated memory in buffer because v8 optimizer is that good?
Google gets to decide what the DOM is and you just get to live with it
They’re possibly the most significant web-app developer, so if things were really that broken you’d think they’d be the first to fix it.
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.
> CSS has gained a few constructs like contain or will-transform
He probably means will-change.
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.
And we need to stop relying on JS so much.
This view is completely backwards and I'm baffled by its popularity.
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)
I get this viewpoint from a software architecture level, but that is also effectively the death of the open web. When every website is an opaque app, even often requiring a client-side optimizing compiler that builds an arbitrary binary in order to load (WASM), we can say goodbye to things like search engines and typically also hyperlinks. The rise of social media has already balkanized the web a lot, where almost all content is locked behind a login screen.
This could be what we want, but I can't help but think about what we've lost.
Search engines already run JavaScript to understand the pages they're indexing. Android apps manage to deep-link into each other effectively despite being applications. Designing tools and standards that work well with what we have is far better than trying to hold back the tide.
hes saying you could freely link and iframe other sites, now you cant. the literal "open" web.
Yep, and accessibility will be a nightmare.
Just as it was with Java and Flash.
That's because you're looking at it from the perspective of what the developers of those news websites want, rather than what the users of those news websites want.
The users want to get a document, not an app. That's what the web was made for, documents.
The users want to read an article, I'm not sure the average user really cares if it's delivered as a document or an app
Users do want to find the article via a search engine, and the search engine does prefer the article to be a document, rather than an app.
he make a de good point
The user minds when the app gets in the way of the document.
Those apps were the article is hidden between ads and newsletter/subscription pop-ups?
The apps are mire likely used to hinder ad blockers than benefit the reader.
What feature of an article needs an app?
As a user I want to be able to save the page and read it later.
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.
> Given that even newspaper websites are now built as applications, we should accept that [...]
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?
> 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.
There is no "document" or "application" model, the distinction is mostly just vibes.
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.
Agree that it's all vibes-based, but look at how the newspapers understand their own sites - in particular, what they consider to be an "article", how they edit those articles, and the pipeline from that to the article being rendered in the end user's browser.
Many websites have no business being a full-blown application.
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'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
> This view is completely backwards and I'm baffled by its popularity.
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.
at that point just learn a programming language man. the inception like dreams within dreams within virtual machines running other virtual machines will never stop because CPU power will always increase
I know plenty of programming languages, I'm happy with them, what I want to cut out is the sub-Turing tarpit that is CSS.
I agree.
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.
> coding the painful differences between browsers.. even IE6 to IE7.
This is what I always bring up to web devs who think theyve captured the "write once, run anywhere" dragon
I wrote this last week:
> 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.
None of what you wrote changed in the past 10 years. You still need to do all of that for app-like behaviour.
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.
"Web apps" should have been standard desktop apps with a network connection. You don't need a browser to use network protocols (and protocols died when HTTP stopped sending hypertext and started to send JSONs) or call APIs. Your OS manages the network stack.
We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.
> "Web apps" should have been standard desktop apps with a network connection.
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.
Desktop apps run the risk of installing malware.
Life runs the risk of dying.
As someone coding since 1986, and since 1999 has done more Web related projects than native ones, that is my point of view exactly, unfortunely we kind of are in the minority.
I was on the mobile app side, as possible way to turn the balance around, but then everyone started shipping Cordova and Ionic apps.
Every big tech company is too afraid to fundamentally rewrite the front-end of the internet even though they’ve all produced wonderful alternatives to varying degrees (TypeScript, Dart, Silverlight, etc). Most likely because they don’t want to be targeted as antitrust like MS back in the day.
This website looks awesome. Seriously.
Ugh I love this website and a year ago I was desperately trying to remember the name - trying to describe the concept to chatbots trying to get a lead. I just had to wait around to run into it on HN again.
And now leave a comment for when I inevitably forget again.
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>.
or maybe just stop trying to force the round peg in a square hole. an application is surely not a document. they open documents. its conceptual, but it would make your life so much easier if you stopped trying to make a fully fledged platform out of what was essentially a rich text document viewer. java has since come along and given you pretty much write once, run anywhere and close to instant deployment with its applets
Web as a deployment platform has too many advantages for it to be ignored for distributing _anything_.
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.
itds be easier to just make an amazing deployment platform and code native, than the inverse.
edit: if you can program
If it was, it would reflect in reality. But the web wins the "where shall we deploy this" fight every single time. For good reason. You mentioned java, People preferred literally electron over java.
Reality isn't always good.
<wasm src="/some-blob.wasm" /> might be enough.