4 ms·

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 sa

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.

mjevans 2y ago
Something like... if (typeof URL.parse != 'function') {URL.parse = function (_s){let _ret; try { _ret = new URL(_s)} catch {}; return _ret} } ;
RaisingSpear 2y ago
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/ 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 2y ago
  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 2y ago
    > 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.
croes 2y ago
Especially because we have npm packages for things like left-pad. So this is a no-brainer.
jeroenhd 2y ago
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 2y ago
  > 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 2y ago
    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.

mjevans 2y ago

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

RaisingSpear 2y ago

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/ 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 2y ago
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 2y ago
  > 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.

croes 2y ago

Especially because we have npm packages for things like left-pad. So this is a no-brainer.

jeroenhd 2y ago

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 2y ago
> 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 2y ago
  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.