32 ms·

Rethinking DOM from first principles

lhmiles 1y ago
Very nice post. Maybe the best micro CSS basics explanation I've ever seen
deafpolygon 1y ago
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 1y ago
  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 1y ago
    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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        he make a de good point
      - yoz-y 1y ago
        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 1y ago
        The user minds when the app gets in the way of the document.
      - croes 1y ago
        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?
- masfoobar 1y ago
  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 1y ago
    > 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 1y ago
  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 1y ago
  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 1y ago
  "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.
  - joquarky 1y ago
    Desktop apps run the risk of installing malware.
    - wolvesechoes 1y ago
      Life runs the risk of dying.
  - BrenBarn 1y ago
    > "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.
b_e_n_t_o_n 1y ago
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 1y ago
  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 1y ago
    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 1y ago
  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.
azangru 1y ago
> CSS has gained a few constructs like contain or will-transform He probably means will-change.
porridgeraisin 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      itds be easier to just make an amazing deployment platform and code native, than the inverse. edit: if you can program
      - porridgeraisin 1y ago
        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.
skeezyboy 1y ago
i remember hearing html was dead in 2001
austin-cheney 1y ago
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 1y ago
  > Browser makers have refused to do that for clear security reasons. Because only javascript should be allowed to screw up that badly.
  - afiori 1y ago
    some of the worst dom api were designed with java compatibilty in mind
    - worthless-trash 1y ago
      So its the java prefix that matters ;)
fergie 1y ago
I feel like people are slowly coming round to web components though...
- troupo 1y ago
  No, they really don't.
parasti 1y ago
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 1y ago
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 1y ago
  > 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 1y ago
    Nobody would be using webpages version and everybody would be using app version.
vlindhol 1y ago
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 1y ago
  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 1y ago
> SVG can e.g. do polygonal hit-testing for mouse events, which CSS cannot Yes it can. clip-path does just that.
AshleysBrain 1y ago
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.
- yyyk 1y ago
  >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.
LauraMedia 1y ago
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.
- joquarky 1y ago
  You can create any arbitrary tag for an element and it will be treated like a span until you define its appearance with CSS. Features { display: block; padding-left: 1.5em; list-style-type: disc; } Feature { display: list-item; } 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.
DemocracyFTW2 1y ago
> 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 1y ago
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 1y ago
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 1y ago
  Conflating presentation and data seems like a classically Bad Idea. Changes to presentation break your business logic.
  - joquarky 1y ago
    Your business logic should be behind a server.
    - phailhaus 1y ago
      The parent comment is talking about storing app state in the DOM. That's conflating data with presentation, which is a bad idea.
- taeric 1y ago
  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 1y ago
  so do you stringify all your state?
hungryhobbit 1y ago
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 1y ago
  [reads the HTML Standard] this is hate speech, essentially
- Mizza 1y ago
  > 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 1y ago
  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 1y ago
  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 1y ago
  It can have such a reason to be the way it is, and still be bad.
socalgal2 1y ago
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 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 1y ago
  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 1y ago
    You had a great comment I had saved last time this topic came up: https://news.ycombinator.com/item?id=41981458 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.
    - 1y ago
bloomca 1y ago
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 1y ago
  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 1y ago
    The UX is nowhere near close to native apps, particularly on platforms that take UX seriously like macOS, iOS or Gnome.
    - morsecodist 1y ago
      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.
    - jazzypants 1y ago
      Can you give some examples, please? I can't think of a single thing that cannot be overcome by good design.
taeric 1y ago
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 1y ago
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 1y ago
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 1y ago
https://news.ycombinator.com/item?id=34304655 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-browsers-have-stuck-to-being-document-viewers-and-a-discussion-of-news-5cb92c7b3445 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 1y ago
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.
- bawolff 1y ago
  Why does it matter? Its not like im doing a for..in loop over Element objects.
deleted 1y ago
[deleted]
jmull 1y ago
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.
deleted 1y ago
[deleted]
neuroelectron 1y ago
Google gets to decide what the DOM is and you just get to live with it
- mr_toad 1y ago
  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.
marcus_holmes 1y ago
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.
- setnone 1y ago
  > 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
  - 1y ago
lerp-io 1y ago
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?
bawolff 1y ago
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)
ayaros 1y ago
This website looks awesome. Seriously.
- seaal 1y ago
  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.
dannye 1y ago
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
rebelyes 1y ago
What do you think of flutter? That was my first thought when you mentioned HTML on Canvas.

Very nice post. Maybe the best micro CSS basics explanation I've ever seen

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 1y ago
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 1y ago
  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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        he make a de good point
    - yoz-y 1y ago
      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 1y ago
      The user minds when the app gets in the way of the document.
    - croes 1y ago
      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?
masfoobar 1y ago
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 1y ago
  > 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 1y ago
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 1y ago
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 1y ago
"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.
- joquarky 1y ago
  Desktop apps run the risk of installing malware.
  - wolvesechoes 1y ago
    Life runs the risk of dying.
- BrenBarn 1y ago
  > "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.

b_e_n_t_o_n 1y ago

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 1y ago
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 1y ago
  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 1y ago
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.

azangru 1y ago

> CSS has gained a few constructs like contain or will-transform He probably means will-change.

porridgeraisin 1y ago

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 1y ago
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 1y ago
  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 1y ago
    itds be easier to just make an amazing deployment platform and code native, than the inverse. edit: if you can program
    - porridgeraisin 1y ago
      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.

skeezyboy 1y ago

i remember hearing html was dead in 2001

austin-cheney 1y ago

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 1y ago
> Browser makers have refused to do that for clear security reasons. Because only javascript should be allowed to screw up that badly.
- afiori 1y ago
  some of the worst dom api were designed with java compatibilty in mind
  - worthless-trash 1y ago
    So its the java prefix that matters ;)

fergie 1y ago

I feel like people are slowly coming round to web components though...

troupo 1y ago
No, they really don't.

parasti 1y ago

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 1y ago

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 1y ago
> 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 1y ago
  Nobody would be using webpages version and everybody would be using app version.

vlindhol 1y ago

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 1y ago
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 1y ago

> SVG can e.g. do polygonal hit-testing for mouse events, which CSS cannot Yes it can. clip-path does just that.

AshleysBrain 1y ago

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.

yyyk 1y ago
>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.

LauraMedia 1y ago

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.

joquarky 1y ago
You can create any arbitrary tag for an element and it will be treated like a span until you define its appearance with CSS. Features { display: block; padding-left: 1.5em; list-style-type: disc; } Feature { display: list-item; } 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.

DemocracyFTW2 1y ago

> 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 1y ago

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 1y ago

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 1y ago
Conflating presentation and data seems like a classically Bad Idea. Changes to presentation break your business logic.
- joquarky 1y ago
  Your business logic should be behind a server.
  - phailhaus 1y ago
    The parent comment is talking about storing app state in the DOM. That's conflating data with presentation, which is a bad idea.
taeric 1y ago
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 1y ago
so do you stringify all your state?

hungryhobbit 1y ago

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 1y ago
[reads the HTML Standard] this is hate speech, essentially
Mizza 1y ago
> 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 1y ago
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 1y ago
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 1y ago
It can have such a reason to be the way it is, and still be bad.

socalgal2 1y ago

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 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 1y ago
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 1y ago
  You had a great comment I had saved last time this topic came up: https://news.ycombinator.com/item?id=41981458 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.
  - 1y ago

bloomca 1y ago

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 1y ago
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 1y ago
  The UX is nowhere near close to native apps, particularly on platforms that take UX seriously like macOS, iOS or Gnome.
  - morsecodist 1y ago
    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.
  - jazzypants 1y ago
    Can you give some examples, please? I can't think of a single thing that cannot be overcome by good design.

taeric 1y ago

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 1y ago

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 1y ago

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 1y ago

https://news.ycombinator.com/item?id=34304655 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-browsers-have-stuck-to-being-document-viewers-and-a-discussion-of-news-5cb92c7b3445 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 1y ago

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.

bawolff 1y ago
Why does it matter? Its not like im doing a for..in loop over Element objects.

deleted 1y ago

[deleted]

jmull 1y ago

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.

deleted 1y ago

[deleted]

neuroelectron 1y ago

Google gets to decide what the DOM is and you just get to live with it

mr_toad 1y ago
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.

marcus_holmes 1y ago

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.

setnone 1y ago
> 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
- 1y ago

lerp-io 1y ago

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?

bawolff 1y ago

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)

ayaros 1y ago

This website looks awesome. Seriously.

seaal 1y ago
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.

dannye 1y ago

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

rebelyes 1y ago

What do you think of flutter? That was my first thought when you mentioned HTML on Canvas.