Posted by begoon 1 day ago
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);I still remember reading a news article on C|net about the addition of the <table> element.
Yeah, I'm old.
https://github.com/ClickHouse/ClickHouse/blob/master/program...
I'm not sure if I read that that specific experiment was debunked or not, but it certainly sounds familiar to how some developer trends get propagated even though the ground truth as changed.
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.
I think semantic HTML is a great idea but it's kind of jaded to expect it at this point.
It also doesn't help that semantic elements have styling. That right there gives people good reason to use a neutral container as a baseline. In fact I would go as far as to say that having both div and span is a bad design decision. They are just aliases for css `display` values.
Just look at how they salivate for WASM where everything is closed up and inaccessible, including a11y.
I dunno; ISTR that the materializecss library used `<a>` for buttons.
It’d be interesting to have a parallel DocBook web for technical content, where consumers of that content could apply their own styles to render it in a way that’s best for them.
(I’m not saying I like the world we live in, but I don’t see a likely alternative.)
These days it's a moot point anyway, because everyone is using things like tailwind which provide a full reset for things like default buttons, so there really is no excuse.
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.
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.
The idea of the author seems to be that this part of the DOM API that could benefit from backwards-compatible additions. So, by "abandoned", he hints at the headroom for building more table capabilities into the platform.
He compares it loosely to the form element API and the additions it received over the last decades.
In the case of tables, I could think of things such as a sorting, filtering API, but I can't tell whether that's what he means.
Even if, for some reason, you were filling in the table content dynamically via jQuery, I think the fashion there was also to just pass in whole HTML markup snippets as strings to be injected into the DOM, so you'd also more likely use plain <tr> elements than this table-specific API, same as with a 'hype' framework of now.
> But if you render server side (as with PHP), you'd likely just build up your table on the server rather than dynamically on the client, so you would also not use these imperative table element specific APIs.
The question was: What do people use now to create HTML tables instead of the table manipulation API described in this blog post.
I said:
- If you render a table on the client (not what JS was originally built for, but what it is often used for now) using a framework like React, you declaratively render the table using its semantic elements (table, thead, tbody, tr, td etc.) instead of imperatively building it up using that API
- If you render a table on the server, you essentially do the same (output the table markup)
That's why I described the above mentioned table API as "niche", which you seem to have taken offense with but I still have no idea why.
Maybe you're suggesting that this API is commonly used to add interactivity to a table element on a page with JS? I could see it being used for that, no idea if it is, I still have the feeling that just using regular Element APIs is more common - the question was also about creating tables specifically, not manipulating them, so that's why I mentioned declarative frontend frameworks.
Thanks Vercel & Meta for protecting us.
Huh? Why'd you involve state in this or any imperative code? You render the rows/columns as you'd render any other DOM elements in React, pass in the data as props and iterate on it, create children and pass them to render.
https://github.com/WebKit/WebKit/blob/28fa568972a4d34d867948...
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.