Hacker News Reader

Comment by neya | Hacker News Reader

That's funny because the argument against tables was always that they added extra markup a.k.a lines of code, only to replace them with dozens of nested divs, half assed CSS layout ideologies (floats and clear's, for example) and barely functional JS that all somehow needed to work in sync which was almost never. That's how NPM was born.

Tables worked with 100% of the browsers. The alternatives needed polyfills and shims and ironically the whole thing needed easily 2x the number of integration time and lines of code compared to just slapping tables.

View on HN

There will always be a tension between those who want purely semantic documents and those who argue for a pragmatic allowance of layout to just be allowed in the document itself.

It’s indisputable though that the modern BS of frontend tech is approaching an asymptote of ridiculous complexity. The divs go so deep that it is often pointless to even try to determine what’s going on from a web inspector. And I think the documents themselves are now less semantic than they ever were. Sure, tables were abused (to the extent they weren’t anything close to tabular data). But today every element you see being a layer of 37 divs and spans that don’t even function or in some cases even render without JavaScript getting involved… the web is now just basically a responsive version of PDF.

View Source on any major modern website and many (most?) others is useless. You get 15 lines with some cryptic webpacked JS references.

It must be that we now have a new generation of devs that have no experience with the beauty of the original web where others’ pages were legible and you could as a human easily read and learn from their source. I’m not saying there are 0 tradeoffs but there’s definitely a loss there.

My first time wading into web development was hopping into the source of the MSN.com homepage circa 2000 to see how their DHTML menu rollovers worked, and then stealing it. It was mostly CSS, but to support some browsers they had JS assist with what's being moused over.

That kind of thing is utterly impossible to replicate with a modern frontend build -- all the classes are generated by styled components and all the behaviors are attached with React or Angular. Best you could hope for is to find some telltale attribute that points you toward an open-source library. Or, hope they left their sourcemaps on.

True. We have a product website (1) built entirely with tables and HTML 4.01 (2) in 2026. Works as expected everywhere.

1. https://www.tirreno.com

2. https://validator.w3.org/check?uri=https://www.tirreno.com/&...

Loads super fast and scrolls easy. On mobile, my one complaint is that the menu items (top bar, footer) are quite small.

I mean, it doesn't even render properly on my default samsung android phone...

Thanks! You probably mean page zoom-out on Android because of the viewport. Should work now.

Yeah, works now

Thanks for letting me know.

The argument was for markup to have semantic meaning, not number of lines. Also, NPM was not born for browser JS.

No, npm ultimately enabled the exact kind of accidental complexity I'm talking about where you need a massive node_modules folder and Babel just to generate client-side code

Did front-end dev (among other things) for half of the 2000s (and beyond) and heard plenty of arguments about semantic markup, flexible restyling, accessibility, separation of concerns, and more.

But not one about extra lines of code when it came to table layout.

And claiming non-table alternatives always needed polyfills and more code doesn’t sound like an accurate reflection of the time either. It sounds more like resentment of people who actually did invest in understanding of the domain because they might not just let you use the small toolset you knew without thinking about anything else.

And I say that as a person who did a lot of table-layout markup too.

Reply on news.ycombinator.com