3 ms·

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, h

by neya 4mo ago

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.

Kudos 4mo ago
The argument was for markup to have semantic meaning, not number of lines. Also, NPM was not born for browser JS.
- neya 4mo ago
  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
xp84 4mo ago
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.
- user3939382 4mo ago
  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.
  - xp84 4mo ago
    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.
wwweston 4mo ago
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.
reconnecting 4mo ago
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 https://www.tirreno.com 2. https://validator.w3.org/check?uri=https://www.tirreno.com/&ss=1&group=1 https://validator.w3.org/check?uri=https://www.tirreno.com/&...
- pbronez 4mo ago
  Loads super fast and scrolls easy. On mobile, my one complaint is that the menu items (top bar, footer) are quite small.
- wredcoll 4mo ago
  I mean, it doesn't even render properly on my default samsung android phone...
  - reconnecting 4mo ago
    Thanks! You probably mean page zoom-out on Android because of the viewport. Should work now.
    - wredcoll 4mo ago
      Yeah, works now
      - reconnecting 4mo ago
        Thanks for letting me know.

by neya 4mo ago

Kudos 4mo ago

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

neya 4mo ago
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

xp84 4mo ago

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.

user3939382 4mo ago
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.
- xp84 4mo ago
  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.

wwweston 4mo ago

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.

reconnecting 4mo ago

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 https://www.tirreno.com 2. https://validator.w3.org/check?uri=https://www.tirreno.com/&ss=1&group=1 https://validator.w3.org/check?uri=https://www.tirreno.com/&...

pbronez 4mo ago
Loads super fast and scrolls easy. On mobile, my one complaint is that the menu items (top bar, footer) are quite small.
wredcoll 4mo ago
I mean, it doesn't even render properly on my default samsung android phone...
- reconnecting 4mo ago
  Thanks! You probably mean page zoom-out on Android because of the viewport. Should work now.
  - wredcoll 4mo ago
    Yeah, works now
    - reconnecting 4mo ago
      Thanks for letting me know.