4 ms·

body.qsa('.class').forEach(e=>): Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands

body.qsa('.class').forEach(e=>): Yes, add qs() and Array.from(qsa()) aliases to the Node prototype, and .body to the window, and you’ve saved yourself thousands of keystrokes. Then you can get creative with Proxy if you want to, but I never saw the need.

jraph 9mo ago
Please don't mess with native prototypes though.
- Sammi 9mo ago
  Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.
  - jraph 9mo ago
    If you are an app or website developer, at least you won't break other's systems. But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name. Newer libraries start using that new standard method. You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code. It only works if you ever works on projects that have zero dependencies, or dependencies you never update. Or you could spare yourself the troubles and define a method that takes the node in parameter. It's also a question of forming good habits: you could be working on your projects now, forming a habit of extending prototypes, but will you remember not to do this the day you write a library? By the way, how can you be sure you won't move some of your app code to a library because you like your utility functions and would like to reuse them in another project of yours? And why not open source that shared code, so you can just install it with NPM? Bam, that stuff is a library now.
    - hyperhello 9mo ago
      Rules beget rules.
    - janderland 9mo ago
      > You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code. He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.
      - jraph 9mo ago
        I'm discussing the "adding a prototype method" case and I'm explaining in my comment why this can be, in fact, an issue.
        hyperhello 9mo ago
        Thanks for the feedback. But you did recommend a method that takes the node as a parameter. What protects me from that method name being claimed by some library later in the exact same way?
    - tracker1 9mo ago
      We have a few oddly named methods for arrays and iterators because of the prototype and other libraries being very common.
- tracker1 9mo ago
  I used to use prototype (and sometimes scriptaculous)... Then came IE8 and broke the world on me. For anyone that didn't know, IE8 implemented native JSON.(parse/stringify) methods, and the second parameter is a hydrator/dehydrator... however, if you added custom properties/methods to Array or Object prototypes, they would throw an error you couldn't catch in JS... so to work around, you'd have to load the JSON library and use it under a different name, in ALL your code, because the native implementation was locked/sealed and couldn't be masked out. Second most annoying IE bug was 5.0.0 and the old/new api's for dealing with select elements. New worked, old broken, have fun.
deleted 9mo ago
[deleted]

jraph 9mo ago

Please don't mess with native prototypes though.

Sammi 9mo ago
Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.
- jraph 9mo ago
  If you are an app or website developer, at least you won't break other's systems. But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name. Newer libraries start using that new standard method. You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code. It only works if you ever works on projects that have zero dependencies, or dependencies you never update. Or you could spare yourself the troubles and define a method that takes the node in parameter. It's also a question of forming good habits: you could be working on your projects now, forming a habit of extending prototypes, but will you remember not to do this the day you write a library? By the way, how can you be sure you won't move some of your app code to a library because you like your utility functions and would like to reuse them in another project of yours? And why not open source that shared code, so you can just install it with NPM? Bam, that stuff is a library now.
  - hyperhello 9mo ago
    Rules beget rules.
  - janderland 9mo ago
    > You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code. He was suggesting adding a prototype method, not replacing one. Unless the library your using is also adding prototypes, I can't think of an issue with this. Sure, if a new version of JS ends up using these names then things could break, but I'd bet this won't cause him a problem in actuality.
    - jraph 9mo ago
      I'm discussing the "adding a prototype method" case and I'm explaining in my comment why this can be, in fact, an issue.
      - hyperhello 9mo ago
        Thanks for the feedback. But you did recommend a method that takes the node as a parameter. What protects me from that method name being claimed by some library later in the exact same way?
  - tracker1 9mo ago
    We have a few oddly named methods for arrays and iterators because of the prototype and other libraries being very common.
tracker1 9mo ago
I used to use prototype (and sometimes scriptaculous)... Then came IE8 and broke the world on me. For anyone that didn't know, IE8 implemented native JSON.(parse/stringify) methods, and the second parameter is a hydrator/dehydrator... however, if you added custom properties/methods to Array or Object prototypes, they would throw an error you couldn't catch in JS... so to work around, you'd have to load the JSON library and use it under a different name, in ALL your code, because the native implementation was locked/sealed and couldn't be masked out. Second most annoying IE bug was 5.0.0 and the old/new api's for dealing with select elements. New worked, old broken, have fun.

deleted 9mo ago

[deleted]