[dkarras]

just make a utility function! don't see what the fuss is about. the original API choice is arguably not great, but haphazardly adding multiple ways to do the same thing does not improve the API either.

[croes]

Especially because we have npm packages for things like left-pad.

So this is a no-brainer.

[mjevans]

Something like...

if (typeof URL.parse != 'function') {URL.parse = function (_s){let _ret; try { _ret = new URL(_s)} catch {}; return _ret} } ;

[RaisingSpear]

Yeah, you can write it in less than a minute:

const tryNew = (f, ...a) => {

  try {

   return new f(...a);

  } catch(x) {

   return undefined;

  }

 };

const myUrl = tryNew(URL, 'http://example.com/');

I don't get why JS devs like to whinge about the smallest things. And we get stuff like leftPad because of huge aversion to writing utility functions.

[hyperhopper]

Ironic since your snippet is now a new leftpad.

Does every dev need to write the same line now? Or should your one-liner be a library?

The basics that everybody needs, should be standardized in the standard library.

[RaisingSpear]

> Does every dev need to write the same line now?

Yes.

> Or should your one-liner be a library?

Definitely not.

Particularly if I can write the one-liner faster than it takes one to search, check, include and install the library.

[jeroenhd]

On the one hand, the Javascript spec is so littered with API helper functions to patch over old APIs that I think it'll only continue to grow in exploitability.

On the other hand, you don't want to be Java, where List.Last took until Java 21 to get implemented. It's not hard to make a wrapper function, but it's really annoying to clutter your code with helper functions where the native API should help you.

In this specific instance, I agree with the new spec: most constructors for native Javascript types don't throw, so neither should the URL constructor. However, the try/catch isn't exactly the problem some people seem to think it is. It's a minor annoyance that apparently annoyed at least three browser teams enough to come up with a new API. In other circumstances, I hope the API spec won't be extended as easily.

[spankalee]

> the Javascript spec is so littered with API helper functions to patch over old APIs that I think it'll only continue to grow in exploitability

Can you explain how helpers create exploits? Are there any examples?

[jeroenhd]

The higher the surface area, the higher the risk. Either browser engines maintain two separate methods for creating the URL object, or they use the same base function that's called in two different ways. If someone writes optimised code for one, they can easily forget to keep the other into account.

It's easier to secure a JIT with 100 methods than it is to secure a JIT with a thousand.