Abandonware is a clickbait title insofar as it normally refers to licenses, not standards.
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.
People often use declarative UI frameworks such as React, Svelte etc. when they want to build things dynamically in JS like that now, so imperative DOM manipulation APIs have unsurprisingly become a little more niche.
If by “Niche” you mean “not hype” then yes, but the PHP+jQuery combo is still very widely used in 2025 (likely more than React, given WordPress market share alone).
Sure! 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.
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.
What does that have to do with anything? The question was what do people use ‘now’ instead of this imperative table manipulation API, I’m unsure where you disagree with me.
> 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.
Why would it matter what library you use? I'm using React, I do <table> whenever I need to display tabular data, React or no React as no impact on when I'd use <table>.
Just make sure to pass a subscriber to useSyncExternalStore if you decide to venture outside React and use HTMLTable.insertRow, you see react is really smart and won’t let you use this piece of outdated code without punishing you with side effects.
> Just make sure to pass a subscriber to useSyncExternalStore if you decide to venture outside React and use HTMLTable.insertRow, you see react is really smart and won’t let you use this piece of outdated code without punishing you with side effects.
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.
Yes, your point? Anyone who spend 15 minutes learning about React learns that you don't manipulate the DOM directly, you let the rendering engine handle that for you.
Are you implying that when doing DOM reconciliation, React uses these table-specific insertRow/insertCell APIs for adding and removing elements in tables instead of the regular DOM element APIs it would use for all other elements? I would be surprised if that's the case.
The funny thing is the insertRow/insertCell API just call into DOM manipulation functions like appendChild internally, they just provide some syntactic sugar around things like managing the rows/cells array. It's all the same
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.