Earlier quoted context omitted.
The OP isn't talking about Ajax calls and Dom transformations. He's talking about using semantically correct markup (c'mon, it is literally an ordered list) and a style sheet. Things that would make the site faster, easier to maintain, and easier to parse. If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.
It wouldn't make the site easier to maintain. This stuff is all generated by software. All that would change is what the software generated as output. How much faster would HN pages render if they used "semantically correct markup?"
Ask HN: Why is HN HTML laid out in tables?
21–30 of 40 posts
Re: Ask HN: Why is HN HTML laid out in tables?
#22Because it doesn't matter.
If someone writes C/Python/Lua/language-of-your-choice code that violates good principles, misuses constructs, and generally looks like crap, everyone calls them a lousy coder. Yet when it comes to HTML, using semantically incorrect markup is somehow ok. I understand why pg hasn't updated the display markup, and it's his website, so he can do what he likes with it, but to say "it doesn't matter" is to give anyone wri…
Will all existing C++ code be 'incorrect' once C++0x is finally released?
Re: Ask HN: Why is HN HTML laid out in tables?
#23Earlier quoted context omitted.
If someone writes C/Python/Lua/language-of-your-choice code that violates good principles, misuses constructs, and generally looks like crap, everyone calls them a lousy coder. Yet when it comes to HTML, using semantically incorrect markup is somehow ok. I understand why pg hasn't updated the display markup, and it's his website, so he can do what he likes with it, but to say "it doesn't matter" is to give anyone wri…
What's 'incorrect'? It's just following an older standard. Will all existing C++ code be 'incorrect' once C++0x is finally released?
Re: Ask HN: Why is HN HTML laid out in tables?
#24Earlier quoted context omitted.
It wouldn't make the site easier to maintain. This stuff is all generated by software. All that would change is what the software generated as output. How much faster would HN pages render if they used "semantically correct markup?"
Why are you generating styling at all? It's not dynamic information. It's a static asset that can be cached. Semantically correct markup uses fewer tags, so the output is smaller (also, there'd be no online styling, which would also make the page smaller). Even a small difference on a popular site could matter. But only you can answer that for HN. Look, do what you want. You want to write bullshit markup, be my guest…
I wasn't asking how much faster "semantically correct markup" would make HN pages render as a rhetorical question. I'm genuinely curious. If you want to make claims that x is faster than y, you should be prepared to back them up with numbers, not merely with more heated language.
Re: Ask HN: Why is HN HTML laid out in tables?
#25Earlier quoted context omitted.
The OP isn't talking about Ajax calls and Dom transformations. He's talking about using semantically correct markup (c'mon, it is literally an ordered list) and a style sheet. Things that would make the site faster, easier to maintain, and easier to parse. If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.
It wouldn't make the site easier to maintain. This stuff is all generated by software. All that would change is what the software generated as output. How much faster would HN pages render if they used "semantically correct markup?"
Google's HTML is also all generated. They switched to CSS-based markup in 2007. It is a bit easier to maintain, but only a little, and mostly because of obscure things like bold tags needing to be red and normal-weight in Chinese because bolded Chinese characters look like shit.
Size and rendering speed wise, it's basically a wash. The HTML is significantly smaller, but the CSS is significantly larger, and CSS is a massive pain to refactor and can easily lead to bugs.
It's much easier to manipulate with JavaScript, because the DOM structure of the page is much simpler. Tables also have weird implicit element insertion rules, eg. the first direct child of the on this page is a tag, not the tag that you outputted as source. That alone is a big reason why Google would never go back, though I don't know how much it applies to a mostly static site like this.
Re: Ask HN: Why is HN HTML laid out in tables?
#26Earlier quoted context omitted.
The OP isn't talking about Ajax calls and Dom transformations. He's talking about using semantically correct markup (c'mon, it is literally an ordered list) and a style sheet. Things that would make the site faster, easier to maintain, and easier to parse. If this were anyone other than pg, you'd all be excoriating the developer for living in the 90s.
It wouldn't make the site easier to maintain. This stuff is all generated by software. All that would change is what the software generated as output. How much faster would HN pages render if they used "semantically correct markup?"
Re: Ask HN: Why is HN HTML laid out in tables?
#27Because it doesn't matter.
If someone writes C/Python/Lua/language-of-your-choice code that violates good principles, misuses constructs, and generally looks like crap, everyone calls them a lousy coder. Yet when it comes to HTML, using semantically incorrect markup is somehow ok. I understand why pg hasn't updated the display markup, and it's his website, so he can do what he likes with it, but to say "it doesn't matter" is to give anyone wri…
IMHO, it doesn't matter - for Hacker News. That's independent of whether it matters for whatever website you're being paid to write at any given job.
Re: Ask HN: Why is HN HTML laid out in tables?
#28Earlier quoted context omitted.
Why are you generating styling at all? It's not dynamic information. It's a static asset that can be cached. Semantically correct markup uses fewer tags, so the output is smaller (also, there'd be no online styling, which would also make the page smaller). Even a small difference on a popular site could matter. But only you can answer that for HN. Look, do what you want. You want to write bullshit markup, be my guest…
Generating and caching are orthogonal questions. You can generate stuff, and then cache it. And in fact HN does do a lot of caching. I wasn't asking how much faster "semantically correct markup" would make HN pages render as a rhetorical question. I'm genuinely curious. If you want to make claims that x is faster than y, you should be prepared to back them up with numbers, not merely with more heated language.
Re: Ask HN: Why is HN HTML laid out in tables?
#29Earlier quoted context omitted.
If someone writes C/Python/Lua/language-of-your-choice code that violates good principles, misuses constructs, and generally looks like crap, everyone calls them a lousy coder. Yet when it comes to HTML, using semantically incorrect markup is somehow ok. I understand why pg hasn't updated the display markup, and it's his website, so he can do what he likes with it, but to say "it doesn't matter" is to give anyone wri…
Part of being a good engineer is understanding tradeoffs and figuring out when contextually-dependent knowledge doesn't apply. IMHO, it doesn't matter - for Hacker News . That's independent of whether it matters for whatever website you're being paid to write at any given job.
This is just a semantic argument, but it's one I find important. At our startup, we came out of the gate with viable, working software in under six weeks. Believe me, there were tradeoffs. But at no point in that process did I say, "this doesn't matter". That's lying to myself. It matters, but I will accept for today that I cannot have both. This helps us avoid complacency and keeps our product sharp.
Re: Ask HN: Why is HN HTML laid out in tables?
#30Because it doesn't matter.
If someone writes C/Python/Lua/language-of-your-choice code that violates good principles, misuses constructs, and generally looks like crap, everyone calls them a lousy coder. Yet when it comes to HTML, using semantically incorrect markup is somehow ok. I understand why pg hasn't updated the display markup, and it's his website, so he can do what he likes with it, but to say "it doesn't matter" is to give anyone wri…
Similarly, the code generated by good Python, to a CPU, looks like crap because it repeats stuff, allocates and releases memory, makes unnecessary calls, swaps stuff between stack and registers, and a whole host of other sins.
But we don't care, because what we care about is the end result: the Python or Lua or Ruby code generates lovely computational results. Perhaps 1% of spend time looking in detail at the actual machine code generated. The purpose of these languages is to 1) Let us write good, readable code and 2) generate a useful, sometimes beautiful result.
Similarly, the purpose of this particular Arc program is to generate a useful result, that is, a readable, useful set of html files that our browsers render readably.
So really, "it doesn't matter" if the assembly language is junk, or if the html is not something early versions of Patrick would turn out with notepad.
Think of the generated html as assembly language. It no more degrades our art form than the goofy stuff that modern languages make our CPUs eat.