Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making a Website Under 1kB

tdarb.org

Post reply on HN
Print view View original

101–109 of 109 posts

Re: Making a Website Under 1kB

#101

Post by dna_polymerase »

skyfaller wrote: post #86
thegeekpirate wrote: post #37

Earlier quoted context omitted.

will work just fine ;) Another fun trick is using since the spec says to pretend a space is there if not present for whatever reason ( https://html.spec.whatwg.org/multipage/parsing.html#parse-er... )

Cute, but I just ran both your suggestions through the HTML validator at https://validator.w3.org/nu/ and neither of them validated. The first error read "Bad value data: for attribute href on element link: Premature end of URI." The 2nd error read "Missing space before doctype name." Depending on the context these hacks may still be useful, but I personally think that both production sites and code golfing should re…

I run this in prod. Never had an issue with it.

Re: Making a Website Under 1kB

#102

Post by pjmlp »

jrockway wrote: post #98
pjmlp wrote: post #96

Earlier quoted context omitted.

As long as it has more than 8MB, Emacs will do just fine.

I thought it was 80MB and even then you're constantly swapping. (I had 32MB of RAM on the computer I learned Emacs on and it was totally fine.)

When Emacs came to be, you'd be lucky to have a 80MB hard disk, let alone main memory. :)

Re: Making a Website Under 1kB

#103

Post by eska »

chrismorgan wrote: post #47
eska wrote: post #38

Earlier quoted context omitted.

I tried that too but decided that saving a few bytes is not worth the parser restarting, so I adhered to strict XHTML for fast page load times.

Not worth the… what? I’m not sure what you’re talking about or thinking of, but I think you’re wrong. Parser restarting is purely when speculative parsing fails , and there’s nothing here that can trigger speculative parsing, or failures in it. If you’re using the HTML parser (e.g. served with content-type text/html), activities like including the html/head/body start and end tags and quoting attribute values will ha…

So far your theory, but I measured it in practice. Developer tools give easy access to parser events and different page load timings such as parsing stage.

Re: Making a Website Under 1kB

#105

Post by chrismorgan »

eska wrote: post #103
chrismorgan wrote: post #47

Earlier quoted context omitted.

Not worth the… what? I’m not sure what you’re talking about or thinking of, but I think you’re wrong. Parser restarting is purely when speculative parsing fails , and there’s nothing here that can trigger speculative parsing, or failures in it. If you’re using the HTML parser (e.g. served with content-type text/html), activities like including the html/head/body start and end tags and quoting attribute values will ha…

So far your theory, but I measured it in practice. Developer tools give easy access to parser events and different page load timings such as parsing stage.

The tools you’re talking about are useless for measuring this kind of thing. We’re talking about potential differences well below microseconds, and you’re proposing using tools that (presuming I correctly understand which you mean) report answers in milliseconds, with noise rates of milliseconds (and a lot more if you try scaling it up with things like a million elements in a row). It is possible to benchmark this stuff, but the way you describe is utterly unsound.

Unless presented with concrete steps to reproduce what you’re talking about, I refuse to believe you.

(Mind you, I’m not denying in this that there are differences, just that they’re even measurable this way on even vaguely plausible documents.)

Re: Making a Website Under 1kB

#106

Post by chrismorgan »

eska wrote: post #103
chrismorgan wrote: post #47

Earlier quoted context omitted.

Not worth the… what? I’m not sure what you’re talking about or thinking of, but I think you’re wrong. Parser restarting is purely when speculative parsing fails , and there’s nothing here that can trigger speculative parsing, or failures in it. If you’re using the HTML parser (e.g. served with content-type text/html), activities like including the html/head/body start and end tags and quoting attribute values will ha…

So far your theory, but I measured it in practice. Developer tools give easy access to parser events and different page load timings such as parsing stage.

FYI: with some super basic benchmarking that repeats an HTML snippet 1–100000 times and times how long setting innerHTML takes, I can report that in Firefox, it’s a little faster to omit

, a little faster to omit trailing slashes on void elements, quoting attributes is probably a bit faster, and that the XML parser is much slower (mostly 2–4×). In Chromium, parser performance is way noisier, and I mostly can’t easily see a difference by numbers (without plotting), though it’s probably faster to omit

. As for the effects of using the XML parser, my benchmark crashes the tab (SIGILL) in Chromium and I don’t care enough to figure out why.

Re: Making a Website Under 1kB

#107

Post by thegeekpirate »

skyfaller wrote: post #86
thegeekpirate wrote: post #37

Earlier quoted context omitted.

will work just fine ;) Another fun trick is using since the spec says to pretend a space is there if not present for whatever reason ( https://html.spec.whatwg.org/multipage/parsing.html#parse-er... )

Cute, but I just ran both your suggestions through the HTML validator at https://validator.w3.org/nu/ and neither of them validated. The first error read "Bad value data: for attribute href on element link: Premature end of URI." The 2nd error read "Missing space before doctype name." Depending on the context these hacks may still be useful, but I personally think that both production sites and code golfing should re…

You can't use the error handling part of the spec without invoking an error. Good minifiers will do the same, fwiw.

Re: Making a Website Under 1kB

#108

Post by chrismorgan »

chrismorgan wrote: post #106
eska wrote: post #103

Earlier quoted context omitted.

So far your theory, but I measured it in practice. Developer tools give easy access to parser events and different page load timings such as parsing stage.

FYI: with some super basic benchmarking that repeats an HTML snippet 1–100000 times and times how long setting innerHTML takes, I can report that in Firefox, it’s a little faster to omit , a little faster to omit trailing slashes on void elements, quoting attributes is probably a bit faster, and that the XML parser is much slower (mostly 2–4×). In Chromium, parser performance is way noisier, and I mostly can’t easily…

I might as well also mention that we are talking about differences of a a few dozen nanoseconds at most per instance, and that even then the noise threshold is normally well above that, and that it’s difficult to show significant results in benchmarking at all because you require preposterous amounts of serialised HTML to get a measurable result at all.

Re: Making a Website Under 1kB

#109

Post by eska »

chrismorgan wrote: post #105
eska wrote: post #103

Earlier quoted context omitted.

So far your theory, but I measured it in practice. Developer tools give easy access to parser events and different page load timings such as parsing stage.

The tools you’re talking about are useless for measuring this kind of thing. We’re talking about potential differences well below microseconds, and you’re proposing using tools that (presuming I correctly understand which you mean) report answers in milliseconds, with noise rates of milliseconds (and a lot more if you try scaling it up with things like a million elements in a row). It is possible to benchmark this st…

I’m not talking, like you, about “A parses faster than B”. I talk about “A causes the parser to start over, B doesn’t, so B is faster”. Resets do make a difference that does not require microbenchmarks and is in the realm of milliseconds. This way I was able to load pages in a single frame at 60Hz, which was the threshold I wanted to hit, because it made my webdev friend not realize he already was on the next page when he clicked the link. Feel free to refuse to believe me.
Post reply on HN