5 ms·

I personally blame the robustness principle[1], which I think explains a lot of the accidental complexity in web programming. [1] https://en.m.wikipedia.org/wi

I personally blame the robustness principle[1], which I think explains a lot of the accidental complexity in web programming. [1] https://en.m.wikipedia.org/wiki/Robustness_principle https://en.m.wikipedia.org/wiki/Robustness_principle

Anthony-G 5y ago
Agreed. That’s why I liked XHTML when it came out – it’s hard to believe that’s more than two decades ago! While HTML5 had lots of goodies, I liked the rigour that XHTML imposed on web authors.
- badsectoracula 5y ago
  In theory XHTML was nice as it allowed easier parsing of pages, but in practice it was doomed to fail from the moment a single bracket off made entire sites to stop working. That W3C put their hands in their ears going all lalalalala while ignoring how the world actually used HTML is what led to their irrelevance in defining HTML and essentially giving control to Google, et al. IMO the "robustness principle" is a good thing because it realizes that people make mistakes and their goal isn't to make something correct but something that produces the results they want to see. Even if browsers started with XHTML-like strictness with no alternative, that strictness would quickly have eroded during the first browser wars.
  - xpressvideoz 5y ago
    And after all these years, those people surrendered and started to stick to mandatory closing tags when React was introduced, proving XHTML was right. How amusing.
    - nauticacom 5y ago
      Yes, because everybody has willingly surrendered to the horrors of React hegemony
    - wnevets 5y ago
      > And after all these years, those people surrendered and started to stick to mandatory closing tags when React was introduced, proving XHTML was right. I would argue HTML has been way more successful than React and thus XHTML hasn't been proven right.
    - fregante 5y ago
      JSX requires a build though, it's easier to enforce syntax when a missing character will just work while writing it. There are no JSX errors at runtime for this reason.
  - Sohcahtoa82 5y ago
    > but in practice it was doomed to fail from the moment a single bracket off made entire sites to stop working. Maybe the solution was to not publish sites that are a bracket off. I think half the problems with JavaScript are because of its weak typing. 1 + {} should be a type error.
    - zerocount 5y ago
      No, half the problems with JavaScript are because people refuse to learn it. Just don't write 1+{}. Every time people start bashing JavaScript, it's with these odd-ball examples that they make up.
      - tadfisher 5y ago
        And this is how add_two_numbers becomes embedded in the node_modules of 73,000 projects on GitHub. It's okay if JS has warts, but denying they exist doesn't help anyone.
        Akronymus 5y ago
        If JS just had stuck to LISP like syntax it'd be quite a bit more usable IMO.
  - aaaaaaaaaaab 5y ago
    Delete a semicolon from a C/C++/Java/C# program, and it won’t compile. Delete a byte from a zip file, and it won’t unzip. I don’t see why HTML should be different…
    - badsectoracula 5y ago
      Compiling is something that happens locally and is static - it either compiles now or it doesn't and once you have the final executable you can distribute to your users the syntactical errors or whatever of your source code doesn't matter after that. HTML is different because it is parsed by the browser the end user is using when it is using it. If a site completely broke like, f.e. how Mozilla treated bad XHTML sites (instead of showing the site itself you'd get some yellow page with the error) when you got a tiny syntax error then anything with user generated content (forums, blogs, etc) or even just generated could be a potential minefield. Especially as websites started adding code from external sources (be it for ads or for things like youtube embeds or whatever).
    - deleted 5y ago
      [deleted]
    - FridgeSeal 5y ago
      Yeah I don’t see how that is supposed to be a benefit? Why _shouldn’t_ people have to make actually-valid-html? We don’t tolerate “only sort of correct JSON” tightening the acceptable requirements for valid HTML and CSS would likely make using those formats in more places _easier_.
rplnt 5y ago
That's basically mantra of one of the most popular technologies of the past - php. And javascript to a degree. > Do anything, even the wrong thing, just work.
- secondcoming 5y ago
  On Error Resume Next
  - Sohcahtoa82 5y ago
    It's so bad that this ever existed. It's even worse than PHP and JS were built around it. Errors should never pass silently unless explicitly silenced.
    - technobabbler 5y ago
      Why? Very little on the web is critical. If it mostly renders, it's mostly good enough. shrug It's not like the big vendors with fancy programmers and difficult types release without bugs and security issues. But so what? Life goes on.
    - josefx 5y ago
      > unless explicitly silenced. Which is what "On Error Resume Next" was doing by overwriting the current error handler. Seems to me that it was simply overused. Implicitly ignoring errors is more a C thing.
      - Sohcahtoa82 5y ago
        I suppose you're technically right. It's just the worst way to do it.
Akronymus 5y ago
IMO, if someone is trying to use an API in a malformed way, they just should get a message back saying it is malformed. Possibly with potential causes. I prefer endpoints to shout at me, rather than accepting it and trying their best.
derf_ 5y ago
https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance https://datatracker.ietf.org/doc/html/draft-iab-protocol-mai...
Spivak 5y ago
Over the years I've switched my philosophy to "be paranoid about what you accept, normalize inputs, randomize outputs, and fail loud and on purpose." Make it so that if the caller/client works at all then it must work correctly. Force them to handle errors and retry on things that might fail, values that might change, and if the result is something that must be parsed send it back in varying formats so they have to parse it.
- BiteCode_dev 5y ago
  I understand the benefit of randomize output, but that's very costly.

Anthony-G 5y ago

Agreed. That’s why I liked XHTML when it came out – it’s hard to believe that’s more than two decades ago! While HTML5 had lots of goodies, I liked the rigour that XHTML imposed on web authors.

badsectoracula 5y ago
In theory XHTML was nice as it allowed easier parsing of pages, but in practice it was doomed to fail from the moment a single bracket off made entire sites to stop working. That W3C put their hands in their ears going all lalalalala while ignoring how the world actually used HTML is what led to their irrelevance in defining HTML and essentially giving control to Google, et al. IMO the "robustness principle" is a good thing because it realizes that people make mistakes and their goal isn't to make something correct but something that produces the results they want to see. Even if browsers started with XHTML-like strictness with no alternative, that strictness would quickly have eroded during the first browser wars.
- xpressvideoz 5y ago
  And after all these years, those people surrendered and started to stick to mandatory closing tags when React was introduced, proving XHTML was right. How amusing.
  - nauticacom 5y ago
    Yes, because everybody has willingly surrendered to the horrors of React hegemony
  - wnevets 5y ago
    > And after all these years, those people surrendered and started to stick to mandatory closing tags when React was introduced, proving XHTML was right. I would argue HTML has been way more successful than React and thus XHTML hasn't been proven right.
  - fregante 5y ago
    JSX requires a build though, it's easier to enforce syntax when a missing character will just work while writing it. There are no JSX errors at runtime for this reason.
- Sohcahtoa82 5y ago
  > but in practice it was doomed to fail from the moment a single bracket off made entire sites to stop working. Maybe the solution was to not publish sites that are a bracket off. I think half the problems with JavaScript are because of its weak typing. 1 + {} should be a type error.
  - zerocount 5y ago
    No, half the problems with JavaScript are because people refuse to learn it. Just don't write 1+{}. Every time people start bashing JavaScript, it's with these odd-ball examples that they make up.
    - tadfisher 5y ago
      And this is how add_two_numbers becomes embedded in the node_modules of 73,000 projects on GitHub. It's okay if JS has warts, but denying they exist doesn't help anyone.
      - Akronymus 5y ago
        If JS just had stuck to LISP like syntax it'd be quite a bit more usable IMO.
- aaaaaaaaaaab 5y ago
  Delete a semicolon from a C/C++/Java/C# program, and it won’t compile. Delete a byte from a zip file, and it won’t unzip. I don’t see why HTML should be different…
  - badsectoracula 5y ago
    Compiling is something that happens locally and is static - it either compiles now or it doesn't and once you have the final executable you can distribute to your users the syntactical errors or whatever of your source code doesn't matter after that. HTML is different because it is parsed by the browser the end user is using when it is using it. If a site completely broke like, f.e. how Mozilla treated bad XHTML sites (instead of showing the site itself you'd get some yellow page with the error) when you got a tiny syntax error then anything with user generated content (forums, blogs, etc) or even just generated could be a potential minefield. Especially as websites started adding code from external sources (be it for ads or for things like youtube embeds or whatever).
  - deleted 5y ago
    [deleted]
  - FridgeSeal 5y ago
    Yeah I don’t see how that is supposed to be a benefit? Why _shouldn’t_ people have to make actually-valid-html? We don’t tolerate “only sort of correct JSON” tightening the acceptable requirements for valid HTML and CSS would likely make using those formats in more places _easier_.

rplnt 5y ago

That's basically mantra of one of the most popular technologies of the past - php. And javascript to a degree. > Do anything, even the wrong thing, just work.

secondcoming 5y ago
On Error Resume Next
- Sohcahtoa82 5y ago
  It's so bad that this ever existed. It's even worse than PHP and JS were built around it. Errors should never pass silently unless explicitly silenced.
  - technobabbler 5y ago
    Why? Very little on the web is critical. If it mostly renders, it's mostly good enough. shrug It's not like the big vendors with fancy programmers and difficult types release without bugs and security issues. But so what? Life goes on.
  - josefx 5y ago
    > unless explicitly silenced. Which is what "On Error Resume Next" was doing by overwriting the current error handler. Seems to me that it was simply overused. Implicitly ignoring errors is more a C thing.
    - Sohcahtoa82 5y ago
      I suppose you're technically right. It's just the worst way to do it.

Akronymus 5y ago

IMO, if someone is trying to use an API in a malformed way, they just should get a message back saying it is malformed. Possibly with potential causes. I prefer endpoints to shout at me, rather than accepting it and trying their best.

derf_ 5y ago

https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance https://datatracker.ietf.org/doc/html/draft-iab-protocol-mai...

Spivak 5y ago

Over the years I've switched my philosophy to "be paranoid about what you accept, normalize inputs, randomize outputs, and fail loud and on purpose." Make it so that if the caller/client works at all then it must work correctly. Force them to handle errors and retry on things that might fail, values that might change, and if the result is something that must be parsed send it back in varying formats so they have to parse it.

BiteCode_dev 5y ago
I understand the benefit of randomize output, but that's very costly.