5 ms·

The fact that this software is so complex is the problem imo. The focus at this point should be on cleanup and simplification instead of feature bloat. Every de

by rapind 7y ago

The fact that this software is so complex is the problem imo. The focus at this point should be on cleanup and simplification instead of feature bloat. Every design decision should consider "what can we delete?"

nradov 7y ago
Complex software is what customers want. A rendering engine for clean, valid XHTML could be very simple. But everyone wants to be able to see web pages created by technically incompetent designers with "tag soup" HTML. There's no point in complaining, that's just the reality of the modern web.
- ripdog 7y ago
  The complexity in modern browser engines has nothing to do with parsing invalid HTML and everything to do with the vast, absurd feature set of the modern web platform, and the complex interactions between the components.
  - bobthepanda 7y ago
    Yeah, if you were to design HTML, CSS, and JS from the ground up today they'd likely look very different. The bigger issue is backwards compatibility; the web has bent over backwards to maintain it, which is a blessing and a curse. On the one hand it makes the feature set absurd, but on the other hand the web is (relatively) easy to archive since format interpreters for it are widespread, and pages can be built and then forgotten about because they still work.
    - amelius 7y ago
      > Yeah, if you were to design HTML, CSS, and JS from the ground up today they'd likely look very different. I'd like to see that experiment done.
      - hencoappel 7y ago
        This is sort of what Flutter claims to be.
        rubber_duck 7y ago
        Flutter is a GUI toolkit, it's a different use case entirely with some small overlap (flutter can run on the web or could be used to build the front-end for a new browser)
        bobajeff 7y ago
        I think he's referring to the fact that Flutter was started as a project, by some of Google's browser and web standards people, to see what the could come up with if they designed a browser from scratch with the knowledge we have today. This is talked about in a few videos and articles by it's creators.
      - dodobirdlord 7y ago
        WASM does seem to be on the road to eventually being a better JS.
        mycall 7y ago
        I wish WASM was AST based instead of stack based architecture.
        wokkel 7y ago
        What does that statement mean? As far as i know stack VS AST is Apple VS. Oranges. If you meant a register based architecture that would make sense. I don't know is wasm code is verifiable, in which case it's trivial to rewrite it to a register like architecture (like dalvik does for jvm bytecode).
  - Aeolun 7y ago
    I think we can drop all non-flexbox layout without any degradation in functionality.
    - emn13 7y ago
      You mean grid? I'm suspect you can emulate most if not all of flexbox in grid, but definitely not vice-versa.
- acdha 7y ago
  > A rendering engine for clean, valid XHTML could be very simple. But everyone wants to be able to see web pages created by technically incompetent designers with "tag soup" HTML. The HTML5 parsing algorithm is not _that_ hard: https://www.w3.org/TR/2011/WD-html5-20110113/parsing.html https://www.w3.org/TR/2011/WD-html5-20110113/parsing.html Do you really think that the complexity of a full XML implementation of the half dozen specs required to implement XHTML would really be that significant a savings compared to the actual features browser developers actually spend their time on? You're correct that complex software is what people want but that's complex as in an advanced document layout system with advanced language support, rich media, forms, etc. rather than the format those features are implemented in.
  - mycall 7y ago
    Browser do much more than just HTML5 parsing. https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_browsers https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_...
    - acdha 7y ago
      Yes, that was my point? Even if it was plausible to switch to XHTML, that’s a small and rather insignificant part of browser code bases.
  - emn13 7y ago
    That algorithm - for what it is, namely pretty basic tree construction - is absurdly complicated. Did you actually read and grok all that stuff about the stack of open elements, and how all kinds of elements have special gotcha clauses? How you can't nest stuff like `<div>`s in `<p>`s, even in descendants - except in those weird corner cases where you can? And let's not forget that the page you linked to is only one of a few pages you need to parse html; stuff like tokenization also has a bunch of weird, legacy modes, and so on. It's pretty crazy; worse than quite a few programming languages, and they have a conceptually much, much more complex domain. Worst perhaps isn't just the sheer size, it's the haphazard inconsistency. If you don't know all the exceptions, it's hard to predict which part will be exceptional. Seriously, XML is arguably bad, but html5 is absurdly horrible. The only reason it's acceptable is because it's so widely used that parsers are huge shared projects and most bugs are shallow. I guess it's all a matter of perspective: sure, you might argue, hey, the spec isn't hundreds of pages, so it's humanly comprehensible. But from my perspective that's a really low bar, and it clears it just barely. It matters too, because these weird quirks have often hidden things like performance issues, misparses, and security issues due to incorrect normalization.
- reilly3000 7y ago
  Much of the complexity isn’t about HTML rendering, but instead about security and device optimizations.
  - dredmorbius 7y ago
    Examples? Or perhaps more useful: domains / classes of such issues? I suspect a lot is: - XHR - JS generally - Cookies A heatmap of problem areas might be interesting. Update: that's sort of here: https://www.cvedetails.com/vulnerabilities-by-types.php https://www.cvedetails.com/vulnerabilities-by-types.php
    - reilly3000 7y ago
      I think you hit on the big ones, but also issues around file system access, secure+performant+efficient use of memory across a lot of devices, and complying with an ever-changing landscape of external standards. Great link!
- EliRivers 7y ago
  "Complex software is what customers want." I think I disagree. Most of my customers don't even want software. They want to watch a movie, or read something, or make some data transform, or something else that is their actual goal. Complex software is what we make in order to enable them to achieve their goal; perhaps if we were smarter and better, we'd be able to make simple software that enabled their goals.
Vinnl 7y ago
That would be incompatible with the mantra 'don't break the web', I'm afraid.

by rapind 7y ago

nradov 7y ago

Complex software is what customers want. A rendering engine for clean, valid XHTML could be very simple. But everyone wants to be able to see web pages created by technically incompetent designers with "tag soup" HTML. There's no point in complaining, that's just the reality of the modern web.

ripdog 7y ago
The complexity in modern browser engines has nothing to do with parsing invalid HTML and everything to do with the vast, absurd feature set of the modern web platform, and the complex interactions between the components.
- bobthepanda 7y ago
  Yeah, if you were to design HTML, CSS, and JS from the ground up today they'd likely look very different. The bigger issue is backwards compatibility; the web has bent over backwards to maintain it, which is a blessing and a curse. On the one hand it makes the feature set absurd, but on the other hand the web is (relatively) easy to archive since format interpreters for it are widespread, and pages can be built and then forgotten about because they still work.
  - amelius 7y ago
    > Yeah, if you were to design HTML, CSS, and JS from the ground up today they'd likely look very different. I'd like to see that experiment done.
    - hencoappel 7y ago
      This is sort of what Flutter claims to be.
      - rubber_duck 7y ago
        Flutter is a GUI toolkit, it's a different use case entirely with some small overlap (flutter can run on the web or could be used to build the front-end for a new browser)
        bobajeff 7y ago
        I think he's referring to the fact that Flutter was started as a project, by some of Google's browser and web standards people, to see what the could come up with if they designed a browser from scratch with the knowledge we have today. This is talked about in a few videos and articles by it's creators.
    - dodobirdlord 7y ago
      WASM does seem to be on the road to eventually being a better JS.
      - mycall 7y ago
        I wish WASM was AST based instead of stack based architecture.
        wokkel 7y ago
        What does that statement mean? As far as i know stack VS AST is Apple VS. Oranges. If you meant a register based architecture that would make sense. I don't know is wasm code is verifiable, in which case it's trivial to rewrite it to a register like architecture (like dalvik does for jvm bytecode).
- Aeolun 7y ago
  I think we can drop all non-flexbox layout without any degradation in functionality.
  - emn13 7y ago
    You mean grid? I'm suspect you can emulate most if not all of flexbox in grid, but definitely not vice-versa.
acdha 7y ago
> A rendering engine for clean, valid XHTML could be very simple. But everyone wants to be able to see web pages created by technically incompetent designers with "tag soup" HTML. The HTML5 parsing algorithm is not _that_ hard: https://www.w3.org/TR/2011/WD-html5-20110113/parsing.html https://www.w3.org/TR/2011/WD-html5-20110113/parsing.html Do you really think that the complexity of a full XML implementation of the half dozen specs required to implement XHTML would really be that significant a savings compared to the actual features browser developers actually spend their time on? You're correct that complex software is what people want but that's complex as in an advanced document layout system with advanced language support, rich media, forms, etc. rather than the format those features are implemented in.
- mycall 7y ago
  Browser do much more than just HTML5 parsing. https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_browsers https://en.wikipedia.org/wiki/Comparison_of_lightweight_web_...
  - acdha 7y ago
    Yes, that was my point? Even if it was plausible to switch to XHTML, that’s a small and rather insignificant part of browser code bases.
- emn13 7y ago
  That algorithm - for what it is, namely pretty basic tree construction - is absurdly complicated. Did you actually read and grok all that stuff about the stack of open elements, and how all kinds of elements have special gotcha clauses? How you can't nest stuff like `<div>`s in `<p>`s, even in descendants - except in those weird corner cases where you can? And let's not forget that the page you linked to is only one of a few pages you need to parse html; stuff like tokenization also has a bunch of weird, legacy modes, and so on. It's pretty crazy; worse than quite a few programming languages, and they have a conceptually much, much more complex domain. Worst perhaps isn't just the sheer size, it's the haphazard inconsistency. If you don't know all the exceptions, it's hard to predict which part will be exceptional. Seriously, XML is arguably bad, but html5 is absurdly horrible. The only reason it's acceptable is because it's so widely used that parsers are huge shared projects and most bugs are shallow. I guess it's all a matter of perspective: sure, you might argue, hey, the spec isn't hundreds of pages, so it's humanly comprehensible. But from my perspective that's a really low bar, and it clears it just barely. It matters too, because these weird quirks have often hidden things like performance issues, misparses, and security issues due to incorrect normalization.
reilly3000 7y ago
Much of the complexity isn’t about HTML rendering, but instead about security and device optimizations.
- dredmorbius 7y ago
  Examples? Or perhaps more useful: domains / classes of such issues? I suspect a lot is: - XHR - JS generally - Cookies A heatmap of problem areas might be interesting. Update: that's sort of here: https://www.cvedetails.com/vulnerabilities-by-types.php https://www.cvedetails.com/vulnerabilities-by-types.php
  - reilly3000 7y ago
    I think you hit on the big ones, but also issues around file system access, secure+performant+efficient use of memory across a lot of devices, and complying with an ever-changing landscape of external standards. Great link!
EliRivers 7y ago
"Complex software is what customers want." I think I disagree. Most of my customers don't even want software. They want to watch a movie, or read something, or make some data transform, or something else that is their actual goal. Complex software is what we make in order to enable them to achieve their goal; perhaps if we were smarter and better, we'd be able to make simple software that enabled their goals.

Vinnl 7y ago

That would be incompatible with the mantra 'don't break the web', I'm afraid.