4 ms·

Phew, this post single handedly made me feel old this morning. I started dabbling with the web just over 20 years ago but have mainly been working on the backen

Phew, this post single handedly made me feel old this morning. I started dabbling with the web just over 20 years ago but have mainly been working on the backend the past 10-15 years. I had no clue that nowadays programmers don’t know about this, so I assume it’s supplanted by modern frameworks or modern JS/CSS

dmd 1y ago
Same. I use this all the time, have for decades. Had no idea other people didn’t.
- zkmon 1y ago
  Just a catchy title. Not abandoned etc. This is the only API available to manipulate HTML table tags.
  - jazzypants 1y ago
    Most people use declarative frameworks to build tables, and you could just use `innerHTML` or `append` or any other imperative DOM API to work with tables.
    - moritzwarhier 1y ago
      Declarative frameworks build on the imperative DOM API.
      - jazzypants 1y ago
        And, not a single one of the declarative frameworks use the HTMLTableElement API!
        zkmon 1y ago
        So how they do they talk to the browser to add a row to the table? Do you know of any API other than DOM used for this?
        plorkyeran 1y ago
        They use createElement instead of the table-specific API.
        moritzwarhier 1y ago
        Which is completely fine as long as it makes zero difference. It's not that long ago when people were fighting here about React, Vue etc being too complex and comparing bundle sizes. Using this right now would increase bundle size for no good reason whatsoever.
      - simonw 1y ago
        They don't use .insertRow() and .insertCell(). Try searching the React codebase for those.
        zkmon 1y ago
        What do they use?
        simonw 1y ago
        appendChild() and the like.
        moritzwarhier 1y ago
        Yea, but that's pretty much irrelevant as long as the effect is exactly the same. Which brings us back to the point of the article: seeing this and feeling inspired to imagine interface extensions that go beyond syntax sugar. I was replying to the wrong comment, because I was responding to this: > I still use this pretty much everywhere to create HTML tables. Do people use something else now? Regarding React: what would be the benefit for using this old syntax sugar in its vDOM implementation? Page reflow is not an issue for vDOM as it batches such updates anyway? And using syntax sugar without benefits in the DOM reconciliation would be pointless. React also doesn't locate form input elements using document.forms.[name]?.[name] because... why should they? Just because they can... Regarding the creation of tables, the most common way to do it would be... parsing initial document's HTML?!
  - moritzwarhier 1y ago
    appendChild, replaceChildren, etc work fine with tables?
alentred 1y ago
Thank you for confirming I am not... crazy, just old then. I was staring at the code for minutes, trying to spot something unusual that I missed. So, this really just about the `<table>` element, or do I actually not see something?
- paperpunk 1y ago
  It’s not about the table element, it’s about the API to construct and manipulate that element with a columns and rows interface which is largely superseded by general DOM manipulation.
  - littlestymaar 1y ago
    Exactly like how `getElementById` replaced the direct use of the id as a JavaScript identifier.
    - xg15 1y ago
      I remember there being posts that explicitly discouraged using IDs directly, but I'm not sure of tge reasons anymore. Maybe browser incompatibilities or unclear scoping and confusion with other variables?
      - withinboredom 1y ago
        It was either Mozilla (Netscape, I think) or IE that it didn’t work on for the longest time.
        mook 1y ago
        I think that was a native IE API that Mozilla had to add support for, as well as document.all (Netscape used document.layers).
      - chrismorgan 1y ago
        It works everywhere (it’s now specified in https://html.spec.whatwg.org/multipage/nav-history-apis.html#named-access-on-the-window-object https://html.spec.whatwg.org/multipage/nav-history-apis.html...), but it’s brittle. It can break by adding colliding properties to window deliberately or by accidental global leak (… including things like setting in dev tools), by browser defining new globals, by some 'name' attribute conflict.
jcpst 1y ago
Yep, didn’t realize this was unknown by enough web developers to warrant an article.
- embedding-shape 1y ago
  I see new frontend developers using <div> for building buttons, and I've even seen people using <div> for doing titles! Us greybeards don't know how much apparent knowledge we're sitting on, it seems.
  - deleted 1y ago
    [deleted]
  - jfengel 1y ago
    Is that bad? Seems to me that we have redundant mechanisms for specifying semantics: tags and attributes (and classes as a specific attribute). Seems to me that tags are really just syntactic sugar for things like roles. Tables in particular are easily abused. Of course I use the tag names, because they're idiomatic. But I feel like a newbie who identifies divs as the only true structure builder has a proper developer's intuition for separating presentation from content.
    - embedding-shape 1y ago
      > Is that bad? As long as you think about semantics and accessibility and does the extra work to add those things, then not really. But why add those extra things when we already get those for free by doing <h1> and then customizing the style? Everything you'd need to manually add, automatically works fine then, so seems like a no-brainer to avoid putting more work on your table.
    - swiftcoder 1y ago
      div-as-button/link leaves a lot of default interaction behaviour on the table. You'll need to handle all the keyboard interactions yourself, all the accessibility markup, etc.
  - 1y ago
prokopton 1y ago
I’ve been doing ssr for so long I can’t fathom why you’d build a table using JS.
- EvanAnderson 1y ago
  I've been working on a little SPA that manipulates tabular data and allows the user to insert rows. This is exactly the API I've been using. Like a lot of other commenters it never occurred to me that people wouldn't know this API exists. Aside: I started with Perl CGI scripts, then ColdFusion, and finally Classic ASP back in the 90s. I had a chuckle a couple years ago dealing with a younger developer who was shocked that and oldster like me was up on new-fangled SSR patterns.
spinningarrow 1y ago
I’ve been building sites since around 2000 and I’ve used HTML tables a lot (including for page layouts, remember those days?). There was a time when I thought I was fluent enough to not have to look up HTML or CSS docs for most things. But I don’t think I’ve ever actively used the DOM API that this article mentions so I learned something new today.
- mattmanser 1y ago
  Surprised, as we used this a lot around 2005, when IE6 was still dominant. If was much simpler to build tables in javascript with this rather than using document.createElement. Perhaps this was one of those things that you just had to know about, or be working on data heavy web apps.
simonw 1y ago
You knew about the .insertRow() and .insertCell() methods?
- spiderfarmer 1y ago
  I made my first CRUD UI that didn't do full page refreshes with those methods.
  - embedding-shape 1y ago
    I think most of us did the ol `$el.appendChild(document.createElement('tr'))` dance rather than using those, at least I did during the 00s for sure.
phkahler 1y ago
HTML tables are cognitively if not officially deprecated these days. I made my 1996 resume in HTML using a table for layout and it was indistinguishable from the Word version when printed. Made by editing the HTML by hand too! Tables are great. I don't doubt that CSS stuff is more capable, but the old ones are still useful.
- xg15 1y ago
  I think the problem was that tables were always supposed to be for things that look like actual tables in the output - for that purpose they are not deprecated. What is discouraged is using tables as invisible layout grids - and that was their primary de-facto usecase before CSS and grid layouts. But that had always been a hack, even though a necessary one.
  - fortyseven 1y ago
    Yep. Tables for tabular data are still on the menu.
  - leptons 1y ago
    Tables are probably still useful for layout in HTML emails (for advertising). I haven't had to work with HTML emails in probably 20 years, but I doubt much has changed about what is and isn't allowed in HTML emails.
  - euroderf 1y ago
    > What is discouraged is using tables as invisible layout grids - and that was their primary de-facto usecase before CSS and grid layouts. After too. I've seen enough "Introduction to CSS"s filled with caveats and hemming & hawing to know that it's all to be avoided when+if possible. I know, I know, there's a whole wide wonderful world out there full of aligns and borders and containers and insets and margins and masks and offsets and paddings and positions oh my. Bleccch..
  - joquarky 1y ago
    How was it a hack? Hack implies brittleness. Using tables for layout was just fine for all but the most ideologically pure pedants.
nunez 1y ago
I feel like I used this when I built a red-light, green-light dashboard for Windows servers at a bank for my first job out of college (in 2009).
JofArnold 1y ago
It's worth checking who the author is... Cristian's not exactly new to the game. I think he's being humble he doesn't know something despite his experience.
lelanthran 1y ago
> Phew, this post single handedly made me feel old this morning. 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" :-)

dmd 1y ago

Same. I use this all the time, have for decades. Had no idea other people didn’t.

zkmon 1y ago
Just a catchy title. Not abandoned etc. This is the only API available to manipulate HTML table tags.
- jazzypants 1y ago
  Most people use declarative frameworks to build tables, and you could just use `innerHTML` or `append` or any other imperative DOM API to work with tables.
  - moritzwarhier 1y ago
    Declarative frameworks build on the imperative DOM API.
    - jazzypants 1y ago
      And, not a single one of the declarative frameworks use the HTMLTableElement API!
      - zkmon 1y ago
        So how they do they talk to the browser to add a row to the table? Do you know of any API other than DOM used for this?
        plorkyeran 1y ago
        They use createElement instead of the table-specific API.
      - moritzwarhier 1y ago
        Which is completely fine as long as it makes zero difference. It's not that long ago when people were fighting here about React, Vue etc being too complex and comparing bundle sizes. Using this right now would increase bundle size for no good reason whatsoever.
    - simonw 1y ago
      They don't use .insertRow() and .insertCell(). Try searching the React codebase for those.
      - zkmon 1y ago
        What do they use?
        simonw 1y ago
        appendChild() and the like.
      - moritzwarhier 1y ago
        Yea, but that's pretty much irrelevant as long as the effect is exactly the same. Which brings us back to the point of the article: seeing this and feeling inspired to imagine interface extensions that go beyond syntax sugar. I was replying to the wrong comment, because I was responding to this: > I still use this pretty much everywhere to create HTML tables. Do people use something else now? Regarding React: what would be the benefit for using this old syntax sugar in its vDOM implementation? Page reflow is not an issue for vDOM as it batches such updates anyway? And using syntax sugar without benefits in the DOM reconciliation would be pointless. React also doesn't locate form input elements using document.forms.[name]?.[name] because... why should they? Just because they can... Regarding the creation of tables, the most common way to do it would be... parsing initial document's HTML?!
- moritzwarhier 1y ago
  appendChild, replaceChildren, etc work fine with tables?

alentred 1y ago

Thank you for confirming I am not... crazy, just old then. I was staring at the code for minutes, trying to spot something unusual that I missed. So, this really just about the `<table>` element, or do I actually not see something?

paperpunk 1y ago
It’s not about the table element, it’s about the API to construct and manipulate that element with a columns and rows interface which is largely superseded by general DOM manipulation.
- littlestymaar 1y ago
  Exactly like how `getElementById` replaced the direct use of the id as a JavaScript identifier.
  - xg15 1y ago
    I remember there being posts that explicitly discouraged using IDs directly, but I'm not sure of tge reasons anymore. Maybe browser incompatibilities or unclear scoping and confusion with other variables?
    - withinboredom 1y ago
      It was either Mozilla (Netscape, I think) or IE that it didn’t work on for the longest time.
      - mook 1y ago
        I think that was a native IE API that Mozilla had to add support for, as well as document.all (Netscape used document.layers).
    - chrismorgan 1y ago
      It works everywhere (it’s now specified in https://html.spec.whatwg.org/multipage/nav-history-apis.html#named-access-on-the-window-object https://html.spec.whatwg.org/multipage/nav-history-apis.html...), but it’s brittle. It can break by adding colliding properties to window deliberately or by accidental global leak (… including things like setting in dev tools), by browser defining new globals, by some 'name' attribute conflict.

jcpst 1y ago

Yep, didn’t realize this was unknown by enough web developers to warrant an article.

embedding-shape 1y ago
I see new frontend developers using <div> for building buttons, and I've even seen people using <div> for doing titles! Us greybeards don't know how much apparent knowledge we're sitting on, it seems.
- deleted 1y ago
  [deleted]
- jfengel 1y ago
  Is that bad? Seems to me that we have redundant mechanisms for specifying semantics: tags and attributes (and classes as a specific attribute). Seems to me that tags are really just syntactic sugar for things like roles. Tables in particular are easily abused. Of course I use the tag names, because they're idiomatic. But I feel like a newbie who identifies divs as the only true structure builder has a proper developer's intuition for separating presentation from content.
  - embedding-shape 1y ago
    > Is that bad? As long as you think about semantics and accessibility and does the extra work to add those things, then not really. But why add those extra things when we already get those for free by doing <h1> and then customizing the style? Everything you'd need to manually add, automatically works fine then, so seems like a no-brainer to avoid putting more work on your table.
  - swiftcoder 1y ago
    div-as-button/link leaves a lot of default interaction behaviour on the table. You'll need to handle all the keyboard interactions yourself, all the accessibility markup, etc.
- 1y ago

prokopton 1y ago

I’ve been doing ssr for so long I can’t fathom why you’d build a table using JS.

EvanAnderson 1y ago
I've been working on a little SPA that manipulates tabular data and allows the user to insert rows. This is exactly the API I've been using. Like a lot of other commenters it never occurred to me that people wouldn't know this API exists. Aside: I started with Perl CGI scripts, then ColdFusion, and finally Classic ASP back in the 90s. I had a chuckle a couple years ago dealing with a younger developer who was shocked that and oldster like me was up on new-fangled SSR patterns.

spinningarrow 1y ago

I’ve been building sites since around 2000 and I’ve used HTML tables a lot (including for page layouts, remember those days?). There was a time when I thought I was fluent enough to not have to look up HTML or CSS docs for most things. But I don’t think I’ve ever actively used the DOM API that this article mentions so I learned something new today.

mattmanser 1y ago
Surprised, as we used this a lot around 2005, when IE6 was still dominant. If was much simpler to build tables in javascript with this rather than using document.createElement. Perhaps this was one of those things that you just had to know about, or be working on data heavy web apps.

simonw 1y ago

You knew about the .insertRow() and .insertCell() methods?

spiderfarmer 1y ago
I made my first CRUD UI that didn't do full page refreshes with those methods.
- embedding-shape 1y ago
  I think most of us did the ol `$el.appendChild(document.createElement('tr'))` dance rather than using those, at least I did during the 00s for sure.

phkahler 1y ago

HTML tables are cognitively if not officially deprecated these days. I made my 1996 resume in HTML using a table for layout and it was indistinguishable from the Word version when printed. Made by editing the HTML by hand too! Tables are great. I don't doubt that CSS stuff is more capable, but the old ones are still useful.

xg15 1y ago
I think the problem was that tables were always supposed to be for things that look like actual tables in the output - for that purpose they are not deprecated. What is discouraged is using tables as invisible layout grids - and that was their primary de-facto usecase before CSS and grid layouts. But that had always been a hack, even though a necessary one.
- fortyseven 1y ago
  Yep. Tables for tabular data are still on the menu.
- leptons 1y ago
  Tables are probably still useful for layout in HTML emails (for advertising). I haven't had to work with HTML emails in probably 20 years, but I doubt much has changed about what is and isn't allowed in HTML emails.
- euroderf 1y ago
  > What is discouraged is using tables as invisible layout grids - and that was their primary de-facto usecase before CSS and grid layouts. After too. I've seen enough "Introduction to CSS"s filled with caveats and hemming & hawing to know that it's all to be avoided when+if possible. I know, I know, there's a whole wide wonderful world out there full of aligns and borders and containers and insets and margins and masks and offsets and paddings and positions oh my. Bleccch..
- joquarky 1y ago
  How was it a hack? Hack implies brittleness. Using tables for layout was just fine for all but the most ideologically pure pedants.

nunez 1y ago

I feel like I used this when I built a red-light, green-light dashboard for Windows servers at a bank for my first job out of college (in 2009).

JofArnold 1y ago

It's worth checking who the author is... Cristian's not exactly new to the game. I think he's being humble he doesn't know something despite his experience.

lelanthran 1y ago

> Phew, this post single handedly made me feel old this morning. 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" :-)