[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.