IMO the `Either` construct should be avoided in JS because inevitably you'll either need to wrap everything in `try ... catch` anyway or you'll be pulling your hair out trying to figure out how to get them to work in an async/event context, in which case you'll end up re-inventing the Promise api (perhaps wrapped in an extra thunk to make it more fp-friendly or whatever).

A more practical approach is to work along the grain of JS while getting inspiration from fp. A common snippet would be:

   function maybeUrl(str) {
     try {
       return new URL(str);
     } catch (err) {
       return null;
     }
   }

This is much more straight-forward and interoperable. Dealing with something like Left<InvalidUrlError> where you've created an entire error subclass and wrapping function for an unrecoverable failure that will be discarded is way overkill.

The unreliablility of thrown values in JS is a valid concern, but instead of trying to wrap all my code in a container construct, I simply wrap/convert the untrusted errors themselves if I need to use properties on an error reliably.