3 ms·

This post… probably doesn’t really mean anything. Firstly, judging a web browser’s compelxity by judging the spec catalogue is already unfair. The catalogue is

This post… probably doesn’t really mean anything. Firstly, judging a web browser’s compelxity by judging the spec catalogue is already unfair. The catalogue is basically a dump of things related to the web, for example the specs of JSON-LD. (Which probably has almost no relationship to implementing web browsers, since that’s just a data format of JSON.) Also, word count doesn’t correlate with complexity. That’s like…. saying that a movie will be more entertaining than another one because it’s runtime is longer. Web-related specs are much, much more detailed than POSIX-specs because of their cross-platform nature: we’ve already seen what happens if web-related specs look like POSIX: anybody remember trying to make web pages that work both in IE, Safari, Firefox in the early 2000s? (Or, just try to make a shell script that works on both macOS, FreeBSD, Ubuntu, and Fedora without trying out on all four OSes. Can you make one with confidence?) Really, it’s just tiring to hear the complaints about web browsers on HN, especially the ones about ‘It wasn’t like it in the 90s, why is every site bloated and complex? Do we really need SPAs?’ Things are there for a reason, and while I agree that not every web-API is useful (and some are harmful), one should not dismiss everything as ‘bloat’ or ‘useless complexity’.

ddevault 7y ago
>Firstly, judging a web browser’s compelxity by judging the spec catalogue is already unfair. The catalogue is basically a dump of things related to the web, for example the specs of JSON-LD. (Which probably has almost no relationship to implementing web browsers, since that’s just a data format of JSON.) https://paste.sr.ht/~sircmpwn/13c1951014a256e9f551296a129bf6d10e9303dc https://paste.sr.ht/~sircmpwn/13c1951014a256e9f551296a129bf6... Specs like JSON-LD are included but do not meaningfully change the numbers. Also, the word count I used in the article is less than half of the real word count I ended up with, just to put to rest any doubts like these about the margin of error. >Also, word count doesn’t correlate with complexity. That’s like…. saying that a movie will be more entertaining than another one because it’s runtime is longer. Web-related specs are much, much more detailed than POSIX-specs because of their cross-platform nature: we’ve already seen what happens if web-related specs look like POSIX: anybody remember trying to make web pages that work both in IE, Safari, Firefox in the early 2000s? (Or, just try to make a shell script that works on both macOS, FreeBSD, Ubuntu, and Fedora without trying out on all four OSes. Can you make one with confidence?) This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard? Can you make a website with confidence which works on all browsers? When was the last time you found a browser-specific issue? Mine was three days ago.
- pcr910303 7y ago
  > Specs like JSON-LD are included but do not meaningfully change the numbers. JSON-LD was a simple example that I just used b.c. it was on the front page. That JSON-LD doesn't meaningfully change the numbers doesn't change the fact that the catalogue is a dump of things related to the web, which is probably different from each spec (POSIX, C, C++, etc...) which has a narrow scope. For example, the link dump has 104 links that mentions CSS in the slug: it probably makes sense to make a comprehensive CSS spec (which would probably reduce the size since it will remove a lot of repetitive parts), but the web standards don't work like that. > This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard? That's based on some @chubot's oilshell blog posts[0][1][2][3] about shell. Excerpts from blog post: > POSIX Uses Brute Force: In theoretical terms, a language is described by a grammar, and a grammar accepts or rejects strings of infinite length. But POSIX apparently specifies no such thing. Only the "unspecified" cases are allowed to use a grammar! > Over the last few years of implementing shell, I've found many times that a careful reading of the POSIX spec isn't sufficient. > The POSIX shell spec says that shell arithmetic is C arithmetic, So it's natural to wonder what the creators of C used. They didn't use grammars to specify their language. The code came first and grammars came later. > Discovery: all shells are highly POSIX compliant, for the areas of the language that POSIX specifies. But POSIX only covers a small portion of say dash, let alone bash. There are probably much more posts about this, but I think this is sufficient enough to explain that POSIX is underspecified. > Can you make a website with confidence which works on all browsers? I can make a website that reasonably works well on all browsers with confidence. At least on the level where one can develop a full SPA based on one browser and then try & test it on others. Most browser-specific issues don't exist and when they do, it's usually a one-liner. > When was the last time you found a browser-specific issue? Mine was three days ago. That's interesting, what was it? (Genuinely interested in that one.) In my experience, it doesn't surface that much unless you're trying to use WASM or some new/non-standard APIs. [0] https://www.oilshell.org/blog/2017/08/31.html#posix-uses-brute-force https://www.oilshell.org/blog/2017/08/31.html#posix-uses-bru... [1] https://www.oilshell.org/blog/2020/01/alias-and-prompt.html#the-alias-problem https://www.oilshell.org/blog/2020/01/alias-and-prompt.html#... [2] https://www.oilshell.org/blog/2017/04/22.html https://www.oilshell.org/blog/2017/04/22.html [3] https://www.oilshell.org/blog/2019/01/18.html#criteria-for-the-osh-language-definition-analogy-to-posix https://www.oilshell.org/blog/2019/01/18.html#criteria-for-t...

ddevault 7y ago

>Firstly, judging a web browser’s compelxity by judging the spec catalogue is already unfair. The catalogue is basically a dump of things related to the web, for example the specs of JSON-LD. (Which probably has almost no relationship to implementing web browsers, since that’s just a data format of JSON.) https://paste.sr.ht/~sircmpwn/13c1951014a256e9f551296a129bf6d10e9303dc https://paste.sr.ht/~sircmpwn/13c1951014a256e9f551296a129bf6... Specs like JSON-LD are included but do not meaningfully change the numbers. Also, the word count I used in the article is less than half of the real word count I ended up with, just to put to rest any doubts like these about the margin of error. >Also, word count doesn’t correlate with complexity. That’s like…. saying that a movie will be more entertaining than another one because it’s runtime is longer. Web-related specs are much, much more detailed than POSIX-specs because of their cross-platform nature: we’ve already seen what happens if web-related specs look like POSIX: anybody remember trying to make web pages that work both in IE, Safari, Firefox in the early 2000s? (Or, just try to make a shell script that works on both macOS, FreeBSD, Ubuntu, and Fedora without trying out on all four OSes. Can you make one with confidence?) This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard? Can you make a website with confidence which works on all browsers? When was the last time you found a browser-specific issue? Mine was three days ago.

pcr910303 7y ago
> Specs like JSON-LD are included but do not meaningfully change the numbers. JSON-LD was a simple example that I just used b.c. it was on the front page. That JSON-LD doesn't meaningfully change the numbers doesn't change the fact that the catalogue is a dump of things related to the web, which is probably different from each spec (POSIX, C, C++, etc...) which has a narrow scope. For example, the link dump has 104 links that mentions CSS in the slug: it probably makes sense to make a comprehensive CSS spec (which would probably reduce the size since it will remove a lot of repetitive parts), but the web standards don't work like that. > This doesn't seem right at all. How do you figure that POSIX is less specified than the web? Have you read either standard? That's based on some @chubot's oilshell blog posts[0][1][2][3] about shell. Excerpts from blog post: > POSIX Uses Brute Force: In theoretical terms, a language is described by a grammar, and a grammar accepts or rejects strings of infinite length. But POSIX apparently specifies no such thing. Only the "unspecified" cases are allowed to use a grammar! > Over the last few years of implementing shell, I've found many times that a careful reading of the POSIX spec isn't sufficient. > The POSIX shell spec says that shell arithmetic is C arithmetic, So it's natural to wonder what the creators of C used. They didn't use grammars to specify their language. The code came first and grammars came later. > Discovery: all shells are highly POSIX compliant, for the areas of the language that POSIX specifies. But POSIX only covers a small portion of say dash, let alone bash. There are probably much more posts about this, but I think this is sufficient enough to explain that POSIX is underspecified. > Can you make a website with confidence which works on all browsers? I can make a website that reasonably works well on all browsers with confidence. At least on the level where one can develop a full SPA based on one browser and then try & test it on others. Most browser-specific issues don't exist and when they do, it's usually a one-liner. > When was the last time you found a browser-specific issue? Mine was three days ago. That's interesting, what was it? (Genuinely interested in that one.) In my experience, it doesn't surface that much unless you're trying to use WASM or some new/non-standard APIs. [0] https://www.oilshell.org/blog/2017/08/31.html#posix-uses-brute-force https://www.oilshell.org/blog/2017/08/31.html#posix-uses-bru... [1] https://www.oilshell.org/blog/2020/01/alias-and-prompt.html#the-alias-problem https://www.oilshell.org/blog/2020/01/alias-and-prompt.html#... [2] https://www.oilshell.org/blog/2017/04/22.html https://www.oilshell.org/blog/2017/04/22.html [3] https://www.oilshell.org/blog/2019/01/18.html#criteria-for-the-osh-language-definition-analogy-to-posix https://www.oilshell.org/blog/2019/01/18.html#criteria-for-t...