Abandoned? When? I still use this pretty much everywhere to create HTML tables. Do people use something else now?
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.
A website can be fully rendered on the server at load time and still being interactive on the client side after that initial load.
In that situation, if you want to interactively create a table on your webpage, then you can either use generic DOM methods (which I suspect is the most common way), or you can use the dedicated API.
That's how we did websites back in the 2000s and that's still how most of them are made in practice because the “legacy” tech never went away even if it has minimal visibility on tech forums like HN.
It wasn't my intention to misrepresent anything, I can see how my original comment was perhaps a bit too broad, all I meant to point out was that when building tables dynamically on the client, a declarative framework is now (I thought) a common approach, how common it really is I have no idea, and I do not mean to diminish regular imperative DOM manipulation or label it as 'legacy' by any means.
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...