6 ms·

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 virt

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.
  - deleted 1y ago
    [deleted]
  - strogonoff 1y ago
    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 1y ago
    I would love to use the web pages version, both as a user and on websites.
  - ezst 1y ago
    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.
- rizky05 1y ago
  [dead]
- davidmurdoch 1y ago
  You'd still have all the same backwards compatibility problems with the "Web for applications" stdlib and UI framework as we do now.
  - justinator 1y ago
    You just use the novel solution of downloading the whole thing as an applet.
- graemep 1y ago
  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 1y ago
    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 1y ago
      I thought the JVM had permissions restrictions in the days of Java applets?
      - ezst 1y ago
        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 1y ago
  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 1y ago
    Yes, a terrible one. That's what the article is about.
    - andoando 1y ago
      What I mean is, I dont see why browsers even exist. There should be a singlular framework for creating desktop apps.
      - conartist6 1y ago
        There is. It's called a "browser"
      - n4te 1y ago
        Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned. You'd never design from the start the bonkers HTML/CSS, box model, and other junk we are stuck with, but browsers have a number of good aspects that you'd probably end up with in a complete redesign. The problem is multifaceted. UI toolkits are very hard to do well (I have a lot of opinions on this, and my own crossplatform toolkit), even on a single platform. Just that alone is huge. There are basically no overall great UI toolkits, even if some have good parts. Even a theoretical great UI toolkit will have quite a task to achieve parity with what browser UIs can do. If we could get past that (spoiler: we can't, no way in hell) then we'd also have to be willing to ditch all the legacy browser stuff to switch billions of users and devices to something new AND we'd still have many other big problems to deal with: getting the committee/everyone to agree without ruining it, security, privacy, etc. We've accepted we can't really fix it, so the only thing we can do is keep extending it. That's how we got here.
- postalrat 1y ago
  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 1y ago
    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
    - postalrat 1y ago
      To them the web probably isn't much more than doomscrolling video content.
ale 1y ago
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 1y ago
  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 1y ago
  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.
  - jauntywundrkind 1y ago
    Really loved Steve witten's recent broad look at web tech. Covers a ton of ground. Almost all the anti-web "bloat" stuff feels unserious as fuck, just vague general whining without the faintest leadership towards actual meaningful better. It's so unclear to me, there's so little evidence to me the legacy really drags us down. Steve nicely reviews real actual points and topics, has actual concerns to bring up. I'm still wholy unconvinced this online endless whinge-fest has anything serious to say, has even a modicum of a points and there's so little effort to point to or steer to better. But God damn does it feel so good to escape totally fucking useless and at least see some good discussion of inside out vs outside in paint models, that at least has specific concerns about core basics of the rendering paradigm. Acko.net is the greatest. https://acko.net/blog/html-is-dead-long-live-html/ https://acko.net/blog/html-is-dead-long-live-html/ The web platform has just done exceedingly fantastically well with incredibly respectable people working really hard to steer things forwards. Having multiple layers of security and technical architecture groups to review, having other browsers review proposals: it's inconceivable to me to imagine spending 1/20th as much effort building an alternative of any even modest caliber. They sure tried with Dart, Flutter, Fuschia, but it's just not a significant enough lift, it's just another app dev platform, and it's desire for pixel perfect graphics made it absolutely ass and terrible at being a good reactive malleable platform. And it being Flash 2.0 made it vastly inferior to what users got from the web. The web is big and dense. Even ignoring the sprawling amazing magical web platform and focusing on the robust DOM. And that pisses a lot of people off. There is much clutching for certainty, wanting to be steered. Devs crave having the validation of Modernism, of solutions that when written fit expected shape and parameters. 'Another fine Cathedral!'; you know it when you see it. But the web doesn't give us that certainty at all. There's many ways to get there, there's overlapping options and tools, dozens of paradigms to pick from for how you want to organize your css rules, different layout models to swizzle together. The dirty rough open possibility of the web Bazaar drives people frelling off the wall. I can't help but see those people clutching for certainty as hopelessly out of touch with the universe, obsessed with a narrow engineering paradigm of control & missing the organic beauty of life the universe & everything. Wittens here at least has some core points (amid lots of buckshot, much that various tensions are unresolved). It's fantastic that we have so many different ways to do web apps. The basics have proven so malleable, such endless ability to be interpreted and governed into forms of whatever we might imagine. The layout of the DOM has gotten so so much better, had so many wonderful additions and fixed in the past decade. The Web Platform Tests have put to the sword so much uncertainty, become a massive way for the web to remain one thing even across many browsers. New browsers like Ladybird and Servo show promise of new engines, new life. Web Components will or won't they questions dog us us still, we all consult our team leaves to guess their future, but meanwhile a similar structuring of custom comments is endemic to React. Invoker/commands are spreading id-ref dogma, for the page linking to other parts of the page declaratively. It's all incredibly exciting. I'd be very happy to have anything else that shows life, that can compete as an equally radiant open question we can continue to improve. But that's not what the DOM haters are after. And the narrow vision view: I think it bereft & sad, and the lack of material they have to point to to steer us, to offer spiritual council upwards rather than just condemning downwards, throwing faint "bloat" condemnations: it makes me sad we critics so obviously up to no good, who just standby and have such vacuous aspersions to cast, on endless repeat.
troupo 1y ago
> 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 1y ago
  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 1y ago
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 1y ago
  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 1y ago
  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 1y ago
    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-flexbox-poster.png 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)
    - 1y ago
crabbone 1y ago
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.
- conartist6 1y ago
  So instead of writing an app once I can write it ten times once for each native platform. I AM SOLD
LunaSea 1y ago
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.
cosmic_cheese 1y ago
Much of this complexity comes down to primitives being too primitive for the use case of web apps. They’re fine for documents, but for web apps it’s like trying to build a building from grains of sand instead of concrete blocks. Rube Goldberg machines are unavoidable when you’re doing that. The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
- paulryanrogers 1y ago
  I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose. Still, it's quite sad how long we had to wait for stylable checkboxes.
  - cosmic_cheese 1y ago
    Personally, for something like this I’m not sure that getting consensus really matters or is even desirable (death by design by committee is real). Just pick a direction and go. If it’s sufficiently good it’ll catch on and blossom from there, if it doesn’t go back to drawing board and try again. The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re still extremely primitive relative to something like AppKit or win32.
    - paulryanrogers 1y ago
      > ...if it doesn’t go back to drawing board and try again. My guess is that would put the burden of keeping up with evolving APIs on web developers and web companies. And there is a huge and very diverse ecosystem out there. Native app developers seem to be burning resources trying to stay in stores and working on modern devices.
jongjong 1y ago
Yes IMO, the DOM is actually quite good. There are some valid complaints around superficial aspects of the API... For example, the ambiguous boundary between properties and methods being abused... But these are really superficial points. The DOM cannot assume that it's just for building declarative applications, it needs to support imperative functionality too... IMO, the custom Web Components API solves the declarative problem very neatly, much more neatly than React or any other declarative framework I've come across. I think it's wonderful how the DOM API has evolved slowly over time to meet user needs and it would be foolish to think we can just redesign it better from the bottom up without sacrificing some gems. I think the people complaining about it are stuck in some utopian mindset. They have a specific frame of mind and they look at the DOM through the lens of a limited number of use cases which are relevant to them. They hold rigid, blanket beliefs around concepts like "Functional programming, side effects, reactivity" but these beliefs are siloed around each concept; they neglect the fact that the intersection of multiple approaches can transform the problem and radically alter the equation... For example, the modularization of Web Components and associated lifecycle methods, greatly reduce the dangers of imperative programming within component boundaries. It's good to be aware that both strong acids and strong alkaline solutions are dangerous on their own, but one should recognize that mixing them together could completely change this fact.
rr808 1y ago
Visual Basic was a much simpler dev environment 30 years ago already. I was hoping with WASM we'd get something similar, but I'm still waiting.
- wolpoli 1y ago
  The market seems incapable of producing a modern VB like development environment for the web. I have theories, but still unsure why it is like that. However, we do have a bunch of zero code tools companies that locks your logic into their ecosystem and charges quite a bit of money every month.
- strogonoff 1y ago
  Visual Basic is significantly less featureful.
  - rr808 1y ago
    Any examples of what the web does better? I can't think of any, esp with activex controls where you could plug in any third party component.
    - strogonoff 1y ago
      Text layout and typography (text-wrap: pretty comes to mind), for example. Sure, a lot might be possible if you call out of VB and embed another runtime, but out of the box Web is pretty damn batteries includes relative to VB, I think.
      - rr808 1y ago
        OK fair enough. I meant really functionality of crud apps where there usually isn't a lot of text and if there is vb is good enough. Of course you can always put a browser control in your form for what browsers do best.
atoav 1y ago
I often handcode UI layouts and animations in C on embedded devices. I also use HTML and CSS a lot. Sometimes I prefer the raw simplicity of writing your own layout code. You then basically just need X/Y coordinates, anchor points and dimensions of the screen and the elements on them. The rest can be done using simple arithmetic. The good thing about this is that you can do 95% of what people use CSS for, while using a handful of consistent methods. Wbile this to the uninitiated requires some introduction into how to think in a coordinate system, the simplicity can be refreshing. Meanwhile in CSS you have a organically grown complexity of features where sometimes things that should be simple are hard, often because the elements that should be styled have default attributes with subtle differences which people aren't aware of. Only the minority could tell you the differences between display: inline, block, inline-block, contents, flex, grid, table, rable-column-group, etc. But elements may have them set per default. I get that it is hard to simplify CSS for reasons of backwards compatibility, but sometimes I wish that instead of adding on top someone had had a long hard think about how to solve the problems elegantly and with consistency instead.
otabdeveloper4 1y ago
> However, it is a product designed by committee (in fact, by multitudes of various committees) Not really. The Web is owned and operated by Google. They can literally do whatever the fuck they want with it. (Any "standardization" process is less then a formality at this point.)

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.
- deleted 1y ago
  [deleted]
- strogonoff 1y ago
  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 1y ago
  I would love to use the web pages version, both as a user and on websites.
- ezst 1y ago
  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.
rizky05 1y ago
[dead]
davidmurdoch 1y ago
You'd still have all the same backwards compatibility problems with the "Web for applications" stdlib and UI framework as we do now.
- justinator 1y ago
  You just use the novel solution of downloading the whole thing as an applet.
graemep 1y ago
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 1y ago
  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 1y ago
    I thought the JVM had permissions restrictions in the days of Java applets?
    - ezst 1y ago
      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 1y ago
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 1y ago
  Yes, a terrible one. That's what the article is about.
  - andoando 1y ago
    What I mean is, I dont see why browsers even exist. There should be a singlular framework for creating desktop apps.
    - conartist6 1y ago
      There is. It's called a "browser"
    - n4te 1y ago
      Ah. One difference is a normal desktop can access a lot more or even all of your system. Otherwise cross platform UI toolkits exist: GTK, Qt, Swing, SWT, etc. They could be great but they aren't, not because it can't be done well just no one has managed to do it well. They could technically be sandboxed but they aren't, or not well. Java applets tried long ago and a lot of systems got owned. You'd never design from the start the bonkers HTML/CSS, box model, and other junk we are stuck with, but browsers have a number of good aspects that you'd probably end up with in a complete redesign. The problem is multifaceted. UI toolkits are very hard to do well (I have a lot of opinions on this, and my own crossplatform toolkit), even on a single platform. Just that alone is huge. There are basically no overall great UI toolkits, even if some have good parts. Even a theoretical great UI toolkit will have quite a task to achieve parity with what browser UIs can do. If we could get past that (spoiler: we can't, no way in hell) then we'd also have to be willing to ditch all the legacy browser stuff to switch billions of users and devices to something new AND we'd still have many other big problems to deal with: getting the committee/everyone to agree without ruining it, security, privacy, etc. We've accepted we can't really fix it, so the only thing we can do is keep extending it. That's how we got here.
postalrat 1y ago
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 1y ago
  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
  - postalrat 1y ago
    To them the web probably isn't much more than doomscrolling video content.

ale 1y ago

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 1y ago
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 1y ago
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.
- jauntywundrkind 1y ago
  Really loved Steve witten's recent broad look at web tech. Covers a ton of ground. Almost all the anti-web "bloat" stuff feels unserious as fuck, just vague general whining without the faintest leadership towards actual meaningful better. It's so unclear to me, there's so little evidence to me the legacy really drags us down. Steve nicely reviews real actual points and topics, has actual concerns to bring up. I'm still wholy unconvinced this online endless whinge-fest has anything serious to say, has even a modicum of a points and there's so little effort to point to or steer to better. But God damn does it feel so good to escape totally fucking useless and at least see some good discussion of inside out vs outside in paint models, that at least has specific concerns about core basics of the rendering paradigm. Acko.net is the greatest. https://acko.net/blog/html-is-dead-long-live-html/ https://acko.net/blog/html-is-dead-long-live-html/ The web platform has just done exceedingly fantastically well with incredibly respectable people working really hard to steer things forwards. Having multiple layers of security and technical architecture groups to review, having other browsers review proposals: it's inconceivable to me to imagine spending 1/20th as much effort building an alternative of any even modest caliber. They sure tried with Dart, Flutter, Fuschia, but it's just not a significant enough lift, it's just another app dev platform, and it's desire for pixel perfect graphics made it absolutely ass and terrible at being a good reactive malleable platform. And it being Flash 2.0 made it vastly inferior to what users got from the web. The web is big and dense. Even ignoring the sprawling amazing magical web platform and focusing on the robust DOM. And that pisses a lot of people off. There is much clutching for certainty, wanting to be steered. Devs crave having the validation of Modernism, of solutions that when written fit expected shape and parameters. 'Another fine Cathedral!'; you know it when you see it. But the web doesn't give us that certainty at all. There's many ways to get there, there's overlapping options and tools, dozens of paradigms to pick from for how you want to organize your css rules, different layout models to swizzle together. The dirty rough open possibility of the web Bazaar drives people frelling off the wall. I can't help but see those people clutching for certainty as hopelessly out of touch with the universe, obsessed with a narrow engineering paradigm of control & missing the organic beauty of life the universe & everything. Wittens here at least has some core points (amid lots of buckshot, much that various tensions are unresolved). It's fantastic that we have so many different ways to do web apps. The basics have proven so malleable, such endless ability to be interpreted and governed into forms of whatever we might imagine. The layout of the DOM has gotten so so much better, had so many wonderful additions and fixed in the past decade. The Web Platform Tests have put to the sword so much uncertainty, become a massive way for the web to remain one thing even across many browsers. New browsers like Ladybird and Servo show promise of new engines, new life. Web Components will or won't they questions dog us us still, we all consult our team leaves to guess their future, but meanwhile a similar structuring of custom comments is endemic to React. Invoker/commands are spreading id-ref dogma, for the page linking to other parts of the page declaratively. It's all incredibly exciting. I'd be very happy to have anything else that shows life, that can compete as an equally radiant open question we can continue to improve. But that's not what the DOM haters are after. And the narrow vision view: I think it bereft & sad, and the lack of material they have to point to to steer us, to offer spiritual council upwards rather than just condemning downwards, throwing faint "bloat" condemnations: it makes me sad we critics so obviously up to no good, who just standby and have such vacuous aspersions to cast, on endless repeat.

troupo 1y ago

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

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 1y ago
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 1y ago
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 1y ago
  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-flexbox-poster.png 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)
  - 1y ago

crabbone 1y ago

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.

conartist6 1y ago
So instead of writing an app once I can write it ten times once for each native platform. I AM SOLD

LunaSea 1y ago

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.

cosmic_cheese 1y ago

Much of this complexity comes down to primitives being too primitive for the use case of web apps. They’re fine for documents, but for web apps it’s like trying to build a building from grains of sand instead of concrete blocks. Rube Goldberg machines are unavoidable when you’re doing that. The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.

paulryanrogers 1y ago
I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose. Still, it's quite sad how long we had to wait for stylable checkboxes.
- cosmic_cheese 1y ago
  Personally, for something like this I’m not sure that getting consensus really matters or is even desirable (death by design by committee is real). Just pick a direction and go. If it’s sufficiently good it’ll catch on and blossom from there, if it doesn’t go back to drawing board and try again. The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re still extremely primitive relative to something like AppKit or win32.
  - paulryanrogers 1y ago
    > ...if it doesn’t go back to drawing board and try again. My guess is that would put the burden of keeping up with evolving APIs on web developers and web companies. And there is a huge and very diverse ecosystem out there. Native app developers seem to be burning resources trying to stay in stores and working on modern devices.

jongjong 1y ago

Yes IMO, the DOM is actually quite good. There are some valid complaints around superficial aspects of the API... For example, the ambiguous boundary between properties and methods being abused... But these are really superficial points. The DOM cannot assume that it's just for building declarative applications, it needs to support imperative functionality too... IMO, the custom Web Components API solves the declarative problem very neatly, much more neatly than React or any other declarative framework I've come across. I think it's wonderful how the DOM API has evolved slowly over time to meet user needs and it would be foolish to think we can just redesign it better from the bottom up without sacrificing some gems. I think the people complaining about it are stuck in some utopian mindset. They have a specific frame of mind and they look at the DOM through the lens of a limited number of use cases which are relevant to them. They hold rigid, blanket beliefs around concepts like "Functional programming, side effects, reactivity" but these beliefs are siloed around each concept; they neglect the fact that the intersection of multiple approaches can transform the problem and radically alter the equation... For example, the modularization of Web Components and associated lifecycle methods, greatly reduce the dangers of imperative programming within component boundaries. It's good to be aware that both strong acids and strong alkaline solutions are dangerous on their own, but one should recognize that mixing them together could completely change this fact.

rr808 1y ago

Visual Basic was a much simpler dev environment 30 years ago already. I was hoping with WASM we'd get something similar, but I'm still waiting.

wolpoli 1y ago
The market seems incapable of producing a modern VB like development environment for the web. I have theories, but still unsure why it is like that. However, we do have a bunch of zero code tools companies that locks your logic into their ecosystem and charges quite a bit of money every month.
strogonoff 1y ago
Visual Basic is significantly less featureful.
- rr808 1y ago
  Any examples of what the web does better? I can't think of any, esp with activex controls where you could plug in any third party component.
  - strogonoff 1y ago
    Text layout and typography (text-wrap: pretty comes to mind), for example. Sure, a lot might be possible if you call out of VB and embed another runtime, but out of the box Web is pretty damn batteries includes relative to VB, I think.
    - rr808 1y ago
      OK fair enough. I meant really functionality of crud apps where there usually isn't a lot of text and if there is vb is good enough. Of course you can always put a browser control in your form for what browsers do best.

atoav 1y ago

I often handcode UI layouts and animations in C on embedded devices. I also use HTML and CSS a lot. Sometimes I prefer the raw simplicity of writing your own layout code. You then basically just need X/Y coordinates, anchor points and dimensions of the screen and the elements on them. The rest can be done using simple arithmetic. The good thing about this is that you can do 95% of what people use CSS for, while using a handful of consistent methods. Wbile this to the uninitiated requires some introduction into how to think in a coordinate system, the simplicity can be refreshing. Meanwhile in CSS you have a organically grown complexity of features where sometimes things that should be simple are hard, often because the elements that should be styled have default attributes with subtle differences which people aren't aware of. Only the minority could tell you the differences between display: inline, block, inline-block, contents, flex, grid, table, rable-column-group, etc. But elements may have them set per default. I get that it is hard to simplify CSS for reasons of backwards compatibility, but sometimes I wish that instead of adding on top someone had had a long hard think about how to solve the problems elegantly and with consistency instead.

otabdeveloper4 1y ago

> However, it is a product designed by committee (in fact, by multitudes of various committees) Not really. The Web is owned and operated by Google. They can literally do whatever the fuck they want with it. (Any "standardization" process is less then a formality at this point.)