[HN Gopher] Rethinking DOM from first principles
___________________________________________________________________
Rethinking DOM from first principles
Author : puzzlingcaptcha
Score : 153 points
Date : 2025-08-06 06:51 UTC (16 hours ago)
(HTM) web link (acko.net)
(TXT) w3m dump (acko.net)
| lhmiles wrote:
| Very nice post. Maybe the best micro CSS basics explanation I've
| ever seen
| deafpolygon wrote:
| 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.
| pistoriusp wrote:
| 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.
| troupo wrote:
| 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.
| lmm wrote:
| 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)
| sirwhinesalot wrote:
| 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.
| Jarwain wrote:
| 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
| teddyh wrote:
| 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.
| skeezyboy wrote:
| he make a de good point
| yoz-y wrote:
| 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.
| squidbeak wrote:
| The user minds when the app gets in the way of the
| document.
| croes wrote:
| 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?
| simonask wrote:
| 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.
| lmm wrote:
| 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.
| skeezyboy wrote:
| hes saying you could freely link and iframe other sites,
| now you cant. the literal "open" web.
| deafpolygon wrote:
| 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
| dkh wrote:
| > 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
| skeezyboy wrote:
| 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
| troupo wrote:
| > 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.
| zelphirkalt wrote:
| > 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?
| lmm wrote:
| > 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.
| krapp wrote:
| 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.
| masfoobar wrote:
| 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.
| skeezyboy wrote:
| > 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
| jimbob45 wrote:
| 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.
| pjmlp wrote:
| 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.
| wolvesechoes wrote:
| "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.
| b_e_n_t_o_n wrote:
| 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.
| simonask wrote:
| 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.
| b_e_n_t_o_n wrote:
| 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.
| gherkinnn wrote:
| 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.
| skeezyboy wrote:
| > 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?
| fiedzia wrote:
| > 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.
| fiedzia wrote:
| > 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.
| LorenDB wrote:
| I'd vote for something along the lines of QML or Slint for
| defining UIs; business logic should be purely done in WASM.
| azangru wrote:
| > CSS has gained a few constructs like contain or will-transform
|
| He probably means will-change.
| porridgeraisin wrote:
| 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>.
| skeezyboy wrote:
| 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
| porridgeraisin wrote:
| 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.
| skeezyboy wrote:
| itds be easier to just make an amazing deployment platform
| and code native, than the inverse.
|
| edit: if you can program
| porridgeraisin wrote:
| 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.
| b_e_n_t_o_n wrote:
| <wasm src="/some-blob.wasm" /> might be enough.
| skeezyboy wrote:
| i remember hearing html was dead in 2001
| austin-cheney wrote:
| 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.
| worthless-trash wrote:
| > Browser makers have refused to do that for clear security
| reasons.
|
| Because only javascript should be allowed to screw up that
| badly.
| afiori wrote:
| some of the worst dom api were designed with java
| compatibilty in mind
| continuational wrote:
| 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.
| alpha_squared wrote:
| 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.
| assimpleaspossi wrote:
| 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.
| afiori wrote:
| 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
| chrismorgan wrote:
| > _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.
| troupo wrote:
| > 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.
| austin-cheney wrote:
| 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.
| troupo wrote:
| > 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.
| fergie wrote:
| I feel like people are slowly coming round to web components
| though...
| troupo wrote:
| No, they really don't.
| parasti wrote:
| 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.
| strogonoff wrote:
| 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.
| ezst wrote:
| > 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.
| dvh wrote:
| Nobody would be using webpages version and everybody would be
| using app version.
| strogonoff wrote:
| 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.
| graemep wrote:
| I would love to use the web pages version, both as a user
| and on websites.
| ezst wrote:
| 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.
| davidmurdoch wrote:
| You'd still have all the same backwards compatibility
| problems with the "Web for applications" stdlib and UI
| framework as we do now.
| justinator wrote:
| You just use the novel solution of downloading the whole
| thing as an applet.
| graemep wrote:
| 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?
| achierius wrote:
| 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
| graemep wrote:
| I thought the JVM had permissions restrictions in the
| days of Java applets?
| ezst wrote:
| 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.
| andoando wrote:
| 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.
| n4te wrote:
| Yes, a terrible one. That's what the article is about.
| postalrat wrote:
| 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.
| wpm wrote:
| 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
| ale wrote:
| 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.
| dleeftink wrote:
| 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.
| strogonoff wrote:
| 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.
| no_wizard wrote:
| 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
| troupo wrote:
| > 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.
| Shog9 wrote:
| 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.
| 7bit wrote:
| 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!
| strogonoff wrote:
| 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.
| benoau wrote:
| 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.
| corytheboyd wrote:
| 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)
| benoau wrote:
| 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:
| <table width="100%" height="100%"> <tr>
| <td colspan="2" height="50"> header </td>
| </tr> <tr> <td width="200"
| valign="top"> sidebar </td> <td
| valign="middle"> content </td> </tr>
| </table>
| icedchai wrote:
| Bring back the 90's. ;) The memories of spacer gifs...
| benoau wrote:
| I still find myself missing Macromedia Fireworks on
| occasion!
| Izkata wrote:
| 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).
| corytheboyd wrote:
| 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.
| n4te wrote:
| 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.
| jitl wrote:
| You can still do this if you want, table element still
| exists and works the same way.
| benoau wrote:
| Well yeah but no self-respecting developer has done this
| for 15 - 20 years... it's kind of a red flag these days!
| rikroots wrote:
| 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).
| crabbone wrote:
| 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.
| LunaSea wrote:
| 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.
| vlindhol wrote:
| 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.
| omnimus wrote:
| 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.
| chrismorgan wrote:
| > _SVG can e.g. do polygonal hit-testing for mouse events, which
| CSS cannot_
|
| Yes it can. clip-path does just that.
| AshleysBrain wrote:
| 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.
| LauraMedia wrote:
| 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.
| DemocracyFTW2 wrote:
| > 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.
| superkuh wrote:
| 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.
| romaniv wrote:
| _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.
| phailhaus wrote:
| Conflating presentation and data seems like a classically Bad
| Idea. Changes to presentation break your business logic.
| taeric wrote:
| 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?
| kh_hk wrote:
| so do you stringify all your state?
| romaniv wrote:
| 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".
| hungryhobbit wrote:
| 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.
| suprfsat wrote:
| [reads the HTML Standard] this is hate speech, essentially
| Mizza wrote:
| > 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.
| flohofwoe wrote:
| Backward compatibility can (most likely) be achieved with a
| dom.js polyfill library which sits on top of that hypothetical
| new middle-layer thingie.
| zamadatix wrote:
| 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.
| satvikpendem wrote:
| It can have such a reason to be the way it is, and still be
| bad.
| socalgal2 wrote:
| 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.
| divan wrote:
| 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.
| satvikpendem wrote:
| 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.
| Shog9 wrote:
| 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!
| Bolwin wrote:
| + even when websites decide to be a pain and block text
| selection/copying, you can fix that with extensions.
| adrian17 wrote:
| > 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.
| socalgal2 wrote:
| 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.
| bloomca wrote:
| 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.
| morsecodist wrote:
| 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.
| dontlaugh wrote:
| The UX is nowhere near close to native apps, particularly on
| platforms that take UX seriously like macOS, iOS or Gnome.
| taeric wrote:
| 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.
| lenkite wrote:
| 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 ?
| cyberax wrote:
| 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.
| DonHopkins wrote:
| 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).
|
| [...]
| c-smile wrote:
| 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: section {
| color: red; // ... and other basic CSS 2.1 props
| display: grid( rows: ...; columns: ...;
| align-items: center; justify-items: start );
| }
|
| 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.
| jmull wrote:
| 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.
___________________________________________________________________
(page generated 2025-08-06 23:00 UTC)