29 ms·

> Browsers have become so nice to work with, that these days, I get away with just the following two lines of code to simplify DOM manipulation: > > dqs =

> Browsers have become so nice to work with, that these days, I get away with just the following two lines of code to simplify DOM manipulation: > > dqs = document.querySelector.bind(document); > dqsA = document.querySelectorAll.bind(document); Sounds useful and reasonable. > I usually import the two functions from a module like this: > > import { dqs, dqsA } from '/lib/js/dqs.js'; Utterly absurd. Just copy and paste. It’s only two simple lines, how could it be worth a dependency?

brightball 2y ago
Included in multiple places?
0xCMP 2y ago
modern browsers support the import syntax natively, so it really shouldn't be a lot of overhead to import it.
- notpushkin 2y ago
  The overhead here would be the need to make another request just for these two functions. On the other hand, with bundling though it’s totally fine to have a module just for these two helpers. (Even better if it can be inlined, but I haven’t seen anything supporting this since Prepack, which is still POC I think.)
  - mg 2y ago
    AFAIK modern HTTP versions like HTTP/3 can request multiple files in a single network packet. So it is basically free to do "another request". As the data request goes out and the data comes in in packets with other "requests".
    - theandrewbailey 2y ago
      A network request isn't free, only less costly than it used to be. Even with HTTP 3, your JS execution is stalled for however long the RTT is back to the server. That could be 500+ ms if its on the side of the world and doesn't have a CDN.
      - mg 2y ago
        Depends on the import tree. The way I understand it, this: import { x } from '/a.js'; import { y } from '/b.js'; Does not take longer than this: import { x } from '/a.js'; Because the message to the server "Give me b.js" goes out in the same network packet as "Give me a.js" and the data of b.js comes back in the same packet(s) as the data of a.js.
Cyphase 2y ago
It looks like it's intended to be copied and pasted into your codebase, not be an external dependency.
0x457 2y ago
I guess it's meant to be processed by some bundler later.
kfajdsl 2y ago
/lib/js/dq.js is part of their codebase.
Kiro 2y ago
Bizarre comment. Why would you copypaste this into every file when you can do it once and import it? What's the problem exactly?
- mrweasel 2y ago
  Every file? You have one .js file per project, if you're like me. So just throwing those two lines in the top and never having to worry about it ever again seems like a nice option.
  - NoahKAndrews 2y ago
    How big are your projects? It's very strange to me that you would want to have just a single JS file per project. Even if you want to avoid bundlers, ES modules make it easy to import code from other files.
    - mrweasel 2y ago
      > How big are your projects? In terms of Javascript, as little as I can possibly get away with. The web stuff that I do is mostly CRUD type apps, which can be done entirely server side. The Javascript is only where it make the user experience better, so basic form help or to do a modal, things like that.
    - niutech 2y ago
      Importing an ES module without a bundler involves making a HTTP request, which costs time. Better KISS and fit all of JS in a single script.
      - mg 2y ago
        which costs time No sure this holds true anymore. When you go to a site like reddit.com which uses HTTP/2, you see a gazillion of requests for JS files, many starting at the same time and ending at the same time. I think that is because newer HTTP versions can put multiple requests in the same data packet. And even HTTP/3 is now supported by over 90% of browsers.
fragmede 2y ago
Because if it ever needs to change, you're in for a world of hurt. Because useful stuff like that is worth sharing elsewhere. It starts with 2 lines, but then theres another useful function you'd like in another file. So you just copy and paste those two lines. But then you want that in a third file. Pretty soon you have this almost-library you're carrying around you've spread across a bunch of files, and now what started with two simple lines is now a mountain of tech debt. Maybe you'll never write enough JavaScript to have additional utility functions. You'll probably never need to modify those two lines. But copying and pasting like that makes for quite the code smell. Because if you're copying and pasting that, the question that someone may never actually verbalize to you is what else in the code is copy and pasting instead of being turned into a shared function in a libray?

brightball 2y ago

Included in multiple places?

0xCMP 2y ago

modern browsers support the import syntax natively, so it really shouldn't be a lot of overhead to import it.

notpushkin 2y ago
The overhead here would be the need to make another request just for these two functions. On the other hand, with bundling though it’s totally fine to have a module just for these two helpers. (Even better if it can be inlined, but I haven’t seen anything supporting this since Prepack, which is still POC I think.)
- mg 2y ago
  AFAIK modern HTTP versions like HTTP/3 can request multiple files in a single network packet. So it is basically free to do "another request". As the data request goes out and the data comes in in packets with other "requests".
  - theandrewbailey 2y ago
    A network request isn't free, only less costly than it used to be. Even with HTTP 3, your JS execution is stalled for however long the RTT is back to the server. That could be 500+ ms if its on the side of the world and doesn't have a CDN.
    - mg 2y ago
      Depends on the import tree. The way I understand it, this: import { x } from '/a.js'; import { y } from '/b.js'; Does not take longer than this: import { x } from '/a.js'; Because the message to the server "Give me b.js" goes out in the same network packet as "Give me a.js" and the data of b.js comes back in the same packet(s) as the data of a.js.

Cyphase 2y ago

It looks like it's intended to be copied and pasted into your codebase, not be an external dependency.

0x457 2y ago

I guess it's meant to be processed by some bundler later.

kfajdsl 2y ago

/lib/js/dq.js is part of their codebase.

Kiro 2y ago

Bizarre comment. Why would you copypaste this into every file when you can do it once and import it? What's the problem exactly?

mrweasel 2y ago
Every file? You have one .js file per project, if you're like me. So just throwing those two lines in the top and never having to worry about it ever again seems like a nice option.
- NoahKAndrews 2y ago
  How big are your projects? It's very strange to me that you would want to have just a single JS file per project. Even if you want to avoid bundlers, ES modules make it easy to import code from other files.
  - mrweasel 2y ago
    > How big are your projects? In terms of Javascript, as little as I can possibly get away with. The web stuff that I do is mostly CRUD type apps, which can be done entirely server side. The Javascript is only where it make the user experience better, so basic form help or to do a modal, things like that.
  - niutech 2y ago
    Importing an ES module without a bundler involves making a HTTP request, which costs time. Better KISS and fit all of JS in a single script.
    - mg 2y ago
      which costs time No sure this holds true anymore. When you go to a site like reddit.com which uses HTTP/2, you see a gazillion of requests for JS files, many starting at the same time and ending at the same time. I think that is because newer HTTP versions can put multiple requests in the same data packet. And even HTTP/3 is now supported by over 90% of browsers.

fragmede 2y ago

Because if it ever needs to change, you're in for a world of hurt. Because useful stuff like that is worth sharing elsewhere. It starts with 2 lines, but then theres another useful function you'd like in another file. So you just copy and paste those two lines. But then you want that in a third file. Pretty soon you have this almost-library you're carrying around you've spread across a bunch of files, and now what started with two simple lines is now a mountain of tech debt. Maybe you'll never write enough JavaScript to have additional utility functions. You'll probably never need to modify those two lines. But copying and pasting like that makes for quite the code smell. Because if you're copying and pasting that, the question that someone may never actually verbalize to you is what else in the code is copy and pasting instead of being turned into a shared function in a libray?