Ecma262: stop putting the entire spec as a single page

[ghost]

If you go here:

http://ecma-international.org/ecma-262/

You are presented with a single monolithic page, a 6 megabyte page:

$ curl -I ecma-international.org/ecma-262/
HTTP/1.1 200 OK
Date: Thu, 31 Jan 2019 02:20:48 GMT
Server: Apache
Last-Modified: Wed, 04 Jul 2018 07:26:57 GMT
Accept-Ranges: bytes
Content-Length: 6241600
Content-Type: text/html; charset=UTF-8

Compare this to the POSIX standard, example page:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

result, 23 kilobyte:

$ curl -I pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
HTTP/1.1 200 OK
Date: Thu, 31 Jan 2019 02:25:47 GMT
Server: Apache
Accept-Ranges: bytes
Content-Length: 22544
Content-Type: text/html

plus each function, utility and header are put on their own page. This makes
using and referencing the C/POSIX standard a pleasure and you can link a person
direct to a function and often even a paragraph explaining whatever it is you
need, and without significant overhead. Because of these limitation I find
myself referencing Mozilla instead for example:

https://developer.mozilla.org/Web/JavaScript

Several other languages follow this format as well:

• http://nim-lang.github.io/Nim
• http://perldoc.perl.org/index-functions-by-cat.html
• http://php.net/funcref
• http://ruby-doc.org/core
• https://docs.julialang.org/en/latest
• https://docs.python.org/library

[ljharb]

Thanks for your thoughts!

Since there are many people that prefer a single page view (in addition to those that would prefer a multi page view), what tooling would you suggest to preserve the current authoring experience while making it easy to produce both a single page and multi page view? (note that every section does have a permalink, so it seems that the primary issue in your OP seems to be the download size of the initial request?)

[ghost]

@ljharb Ive been involved in the open source community long enough to know that my suggestion will likely never come to fruition. however that doesnt mean its pointless to voice my opinion. as someone once said, "the only wrong thing is to do nothing".

in my view the 2 sides are incompatible with each other, so its a waste of time to try to maintain both. however if one insisted on doing this you could perhaps follow the GNU model, as they offer both monolith page and split pages:

https://gnu.org/software/make/manual

[mathiasbynens]

Instead of https://ecma-international.org/ecma-262/ (which is not directly linked to this repository), you should be using the latest draft, which lives here: https://tc39.github.io/ecma262/

Additionally, browsers support compression, so curling without --compressed gives a misguided result. 6 MB? Nah:

$ curl -sI --compressed https://tc39.github.io/ecma262/ | grep content-length
content-length: 754744

(~755 KB.)

[mathiasbynens]

Closing as duplicate of #1270.

[ljharb]

@cup i don’t think they’re incompatible; i just think that either a choice has to be made, or tooling has to be incorporated. This spec has always been a single page; so that’ll be the choice until we have that tooling. A PR would be most welcome if you feel up to it!

[mathiasbynens]

@cup

after the response from mathias its clear he thinks its a non issue

Where did you get that from? I would love to see a multi-page version, just like the WHATWG HTML spec!

I closed this issue because it’s a duplicate, not because I disagree with it.

[ljharb]

@cup It’s very confusing, for the record, when you delete your comments.

[mathiasbynens]

also @mathiasbynens im not sure what youre trying to prove with the compressed

That it’s nowhere near the 6 MB figure you cited.

[mathiasbynens]

Don’t call me Shirley.

[mathiasbynens]

@cup Bad jokes aside, no one is hand-waving it away. You’ve identified a real issue here that we’re all aware of (although I feel you overstated the problem slightly).

I’m asking you to please move the discussion to the already-existing issue, which is #1270.

[ghost]

no thanks. it seems interacting with TC39 is akin to krusty the clown. I will pass.