It depends on what kind of I/O you're after. I think that table is primarily looking at system calls, and the stdin/stdout interface to a console windows or terminal. System calls simply don't exist in Javascript, and there's no stdin/stdout-style console window either, so I assume that's why it's not listed (though you can make a case for node.js here).
The closest thing I know of to failsafe-ness in vanilla Javascript is that calling a function that doesn't exist or accessing a resource that hasn't been loaded will throw an exception. But everything that is available generally "just works" without any error codes or exceptions. Assigning text to innerHTML or using HTML5 canvas methods won't throw if the browser "fails to render" the result somehow (at least, if it does, that's not documented/standardized behavior). Also note that Javascript has no (cross-browser) filesystem API, which is the one thing I can think of where error codes/exceptions would effectively be mandatory. And, Javascript's closest equivalent to console I/O--the console.log() function--also isn't standard, meaning you're never supposed to use it in production code anyway.
So as far as I can tell, the sort of "I/O" where "failsafe" is a meaningful property to ask about doesn't really exist in Javascript. Simply leaving it out of the table probably was the best way to represent it.