It’s not about the <table> element itself—we hope everyone knows about tables—but rather about the table-specific DOM interface, including things like HTMLTableElement.prototype.insertRow() and HTMLTableRowElement.prototype.insertCell() as alternatives to the generic DOM techniques like Document.prototype.createElement() and Node.prototype.appendChild().

These are handy if you’re hand-writing your DOM interactions, but libraries that construct and maintain DOM trees (e.g. React, Svelte, Vue) will never use them, and that’s the direction everything has headed, so in practice they’ve fallen into near-complete disuse.

They match HTML syntax in another important way: HTML tables have thead/tbody/tfoot section elements, but you can mostly skip writing them in HTML syntax because it’ll imply <tbody> open and close tags. Likewise in this interface, if you have a thead/tbody/tfoot element you can call .insertRow() on it, but you can also call .insertRow() on the table, and it’ll put it in the last tbody, creating one if necessary. Meanwhile, I presume in React/Svelte/Vue/whatever you must write out your tbody manually.

I’ve definitely used at least .insertRow, .insertCell, .createTHead, .rows and .cells in the last five years in no-library throwaway/demo scripts where I was generating tables.

—⁂—

Concerning the specific example given, here’s what I find a clearer code style, using for instead of forEach, using better variable names, and omitting the index argument to insertRow/insertCell which was quite unnecessary and only confused matters (the author doesn’t seem to have realised it’s optional):

  let data = [
      ['one','two','three'],
      ['four','five','six']
  ];
  let table = document.createElement('table');
  for (const row of data) {
      let tr = table.insertRow();
      for (const value of row) {
          tr.insertCell().innerText = value;
      }
  }
  document.body.append(table);

https://github.com/ClickHouse/ClickHouse/blob/master/program...

Not sure when it was (10-15 years ago), but at some point everything became <div>s. So, instead of semantic markup, HTML became a UI toolbox.

Not quite sure what the author means by that. Re-rendering pnly happens when the current task queue elemt has been processed. Never while JS is running (aside from webworker and the like). I would honestly be surprised if this API had much (if any) performance benefits over createElement.

That's nice, but isn't that what the standard DOM methods are already doing? Or does that API have any additional abilities?

Nevertheless, that's really cool and potentially saves a lot of tedious and error-prone DOM navigation.

I fear this will be even worse now that we have the origin File System API and people can bring their own database engines (like web-assambled SQLite). But for those of us that are striving towards smaller download sizes this is a disaster.

Topic is reminiscent of a submission from yesterday about XSLT:

https://news.ycombinator.com/item?id=45779261

I remember doing this 25 years ago, but I assume (and hope) it's a huge minority who do this today?

    let table = [
      ['one','two','three'],
      ['four','five','six']
    ];
    let b = document.body;
    let t = document.createElement('table');
    b.appendChild(t);
    table.forEach((row,ri) => {
      let r = t.insertRow(ri);
      row.forEach((l,i) => {
        let c = r.insertCell(i);
        c.innerText = l;  
      })
    });

And there is way more to it.

This kind of code was common and also the starting point of every modern language innovation we have today in JavaScript - even TypeScript, and maybe any modern web development on the server as well.

Tables were the only way to create browser independent layouts dynamically. Or put another way: adding interactivity to websites. And simply because hacking is fun and browsers were experimenting with APIs accessible by JavaScript.

CSS was still bleeding from ACID tests, Netscape was forgotten, Mozilla build Phoenix out of the ashes of the bursting bubble and called their effort Firefox.

In Germany there was and still is the infamous selfHTML project. I remember vividly reading and testing Stefans Münz tutorials on this topic. The content is untouched, only the layout changed, so go back in time for more table fun:

https://wiki.selfhtml.org/wiki/Beispiel:JS-Anwendung-Tabelle...

https://wiki.selfhtml.org/wiki/JavaScript/Tutorials/Tabellen...

It was pretty common to have large one file websites: php and html with css and javascript mixed.

There was no git, no VisualStudio Code, Claude Sonnet - no, Notepad and later Notepad++

(Even the DOOM guys had no version control system in the early stages.)

For me John Resig shines out here. Epic genius behind jQuery. The source code was pure magic, and his book "Secrets of the JavaScript Ninja" is for me the all time climax in programming excellence.

If you never utilised the prototype property, you will never understand any of the most basic structures and inner workings JavaScript has to this day and why Classes are "syntactical sugar" for functions and nothing else.

Function.toString in combination with New Function made me enter 10 matrices in parallel at the time. What a revelation. :D

Nicholas Zakas comes close with his seminal Web Development book, in which he featured every Browser API available at the time with examples on roughly 1000 pages. To this day, exercising most of it and understanding the DOM and Windows object was the best investment ever, because and this fact 15 years later paved the way for the success of a financial SaaS platform. Lost wisdom, not covered by any modern framework like Angular or ReacJS.

https://archive.ph/APbi8

https://en.wikipedia.org/wiki/Eternal_September

As someone who likes to program in Haskell, I feel this pain very strongly. :)

If you're going to use short names at least make it clear which belong together. Especially don't use different lengths when things ought to be similar.

    data.forEach((row,i) => row.forEach((ele,j) => ... ))

This one hurts the most. Save a few bytes for an ungodly amount of mental friction.

that's like saying in spoken language "don't ever use pronouns, or even first or nicknames, use full given names"

    const te = document.createElement('table');
    document.body.appendChild(te);
    [
        ['one',  'two',  'three'],
        ['four', 'five', 'six'  ],
    ].forEach((r, i) => {
        const re = te.insertRow(i);
        r.forEach((c, j) => {
            re.insertCell(j).innerText = c;
        })
    });

Disclaimer: I have not tested the code and I only write JavaScript once every few years and when I do I am unhappy about it.

Tables are great. I don't doubt that CSS stuff is more capable, but the old ones are still useful.

I hear you!

For me though, it made me feel old for a different reason

I had first developed webapps in the late 90s (96 onwards) using cgi-bin, perl, etc. My first webapp, done for money, was something similar to MRTG.

At some point in the last almost-30-years) I had actually used this API! I have, however, forgotten all about it and was only reminded of it with this post.

So, yeah, I feel old because I can legitimately say to many modern web-devs that "I've forgotten more about web dev than you you currently know" :-)

<table> just gives you so many good defaults (semantic structure, accessibility, column styling, column alignment, keyboard navigation) for free compared to using CSS to create your own table, that I'm not sure why you wouldn't use <table> for tabular data.

Of course, if you need masonry, card grids and so on it makes sense, do actual layouting with layouting tools. But thankfully <table> hasn't died just yet, it's still better than CSS for many use cases.

Tables built with flex and grid absolutely can be made accessible with WAI-ARIA, but native table elements are harder to mess up.