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.
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.
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.
Or just skip all of the newly released stuff and use React as it was originally made, like me and many others still do. Never suffer from having to debug "useEffect" because we literally never use it. You don't have to use the newest and shiniest toys, especially not those with footguns.
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
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.
JS hasn't been invented to render on the client side but to allow interactivity.
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.
It has to do with your previous comment…
> 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.
I feel like this is going nowhere...
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.
Yes, React
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.
Thanks Vercel & Meta for protecting us.
> 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.
InsertRow updates the live DOM and React just wholesale replaces it. It’s a masterstroke footgun.
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.
Yes that’s why of instead of learning the standard apis, you have to spend 15 months learning how to debug useEffect
Or just skip all of the newly released stuff and use React as it was originally made, like me and many others still do. Never suffer from having to debug "useEffect" because we literally never use it. You don't have to use the newest and shiniest toys, especially not those with footguns.
React is as orthogonal to DOM manipulation API as it is to letting the browser render tables from HTML.
And what does that use internally to manage tables? Just because there is layer between you and the API, it doesn't mean API is abandoned.
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
https://github.com/WebKit/WebKit/blob/28fa568972a4d34d867948...
Why would anyone use this outdated code over useInsertRow() and useTableColumnEffect()?
What are those and where are they in standard Javascript / DOM API?