> 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?

Included in multiple places?

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

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

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

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.

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.

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

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

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

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

Left-pad anyone?

It's in their codebase.

That's an external dependency. You don't install anything here. It's no different than making any other module you reuse in multiple places.

Because using a JS module will set back your 30-minutes project by an entire day.

Of course you are supposed to master which of the es/interop/amd/require incantation you are supposed to use. I wish Typescript would have mandated one style and one style of JS module only!!

And I’ve never succeeded to find a good guidelines on which kind of JS module I should use. Any advice on what is a very easy and stable and worth-to-learn technique to master imports in 2024?

What? If you don’t have external dependencies, just remove your bundler/transpiler and rely on browsers to import your code.

Your rant is several years out of date. You can use ES imports natively in Node and the browser. I have been very happy doing so.

Besides, if you’re working with a codebase of non-zero complexity you need imports/require/whatever anyway.

Use ESM. It's built into the browser. CJS is legacy. Every major JS runtime has module interop built in now.

Modules aren't hard anymore.

> Because using (a JS) module will set back your 30-minutes project by an entire day

May be learn to do the basic of YOUR JOB for once, some "software engineer".

In 2024 the one and only answer is finally just ESM.

If you need to support the browser use `<script type="module">`. That works natively in every current browser today. You may need an "importmap" for more easily handling dependencies. You may need to spot build with something like esbuild or rollup or rolldown for some of your dependencies if they were written in CJS or to add missing things a browser needs like ".js" file extensions.

If you need to support Node use the package.json incantation `"type": "module"` and the `"exports"` key instead of `"main"` and get sane modern defaults in all LTS supported versions of Node (and a few past versions now, too). Most imports will "just work", your module files will be sensibly named ".js". If you publish a library, most people can consume it, even if some of them (CJS stalwarts/people trapped in legacy swamps) complain about having to work with Promises some of the time.

If you need to support Deno or Bun, they already have sane defaults and their documentation guides you pretty well, including Typescript setup.

> I wish Typescript would have mandated one style and one style of JS module only!!

The good news it that they kind of did: the import/export syntax that Typescript has made familiar since around TS 1.0/1.5 is "surprise" ESM syntax. Typescript has been preparing developers into using it all along. You can stop cross-compiling the ESM you've already become used to writing to older, worse formats like CJS and AMD, you can let Typescript do a lot less work on your behalf and just "strip types" more than "transpile".

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.

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.

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

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.

    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.

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?

I really wish it was a native script to use qs and qsa, rather than something I have to add.

FYI: I know you meant to give an example, but element tags with ID are DOM variables as well.

I recently attempted to remove React as a dependency just to see what would happen. It turns out different browsers are still incredibly inconsistent when it comes to event handling. For example the select event on an <input> element somehow doesn't fire at all on Safari during my test, and doesn't fire when the caret is merely moved on some browsers. Using just the native browser functions isn't just fine, even if you don't need all the React features like components or state or props. It turns out React DOM is valuable as it papers over browser differences.

I haven’t tested myself, but according to MDN the select event on <input> elements should be supported by Safari?

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl...

The MDN page you linked to includes a nice selection logger example. It just doesn't work on my Safari (iOS).

And does an equivalent in React work? Because I don't believe React does any of the papering-over you describe. My understanding (as a non-user) is that React does, logically, essentially nothing special around event handling.

I don't remember off the top of my head whether this specific example works in React as I'm not next to a computer. But I remember reading React source code and finding a whole lot of code to handle the select event. (Just found it by doing a GitHub code search on my phone https://github.com/facebook/react/blob/7c8e5e7ab8bb63de91163...)

In general React has its own event handling code. For one in React the user doesn't even deal with the browser native DOM events but React synthetic events. React also readily creates brand new synthetic events from other browser events. React also sometimes gives different names or behaviors to browser events; the most famous example is that the React onChange event is roughly equivalent to the browser onInput event, but absolutely different from the browser onChange event.

Good to know, thanks. I knew it made synthetic events, but thought it was all still 1:1. I see I was completely wrong. I gotta say, yuck. Don't like it, wish they'd taken a more polyfill-like approach.

IIRC they do that to deal with browser differences and be consistent with things like event bubbling. Probably other benefits as well but that's the one I'm fairly sure I remember from years ago.

There are a couple of edge cases I forget at the moment where react event handlers intentionally behave differently from the DOM handlers with the same name.

Looks like bling.js https://gist.github.com/paulirish/12fb951a8b893a454b32

Bling.js is just $() and .on(), Cash is more than bling.

And you might need Cash before you can have bling.

This is my favorite trick that I've been using for a long time

...I just checked and it turns out I first blogged[0] about it 12 years ago. Time flies.

[0] https://nmn.gl/blog/javascript-shortcut-for-getelementbyid-a...

Your “ct” ligatures in your headings have a fun little loop connecting them!

Haha I'm glad you noticed :) I'm a huge typography nerd.

The css to do that comes from the Normalize-OpenType.css [0] library

[0] https://kennethormandy.com/journal/normalize-opentype-css/

> Just look at it’s size!

Should have been its. Now you are aware of a 12 year old typo

How do people you work with recieve this? I'd imagine it could get messy6if every dev has their own little things like this

querySelectorAll() isn't live. So you could do what I very often do and already convert the result to an array, i.e.

  dqsA = s => Array.from(document.querySelectorAll(s));

Reason why I do that very often is because it allows all array methods to be used on the result, like .map() or .filter(), which makes it feel very much like jQuery. YMMV

    NodeList.prototype.__proto__ = Array.prototype;

Problem solved without Array.from().

Does the underlying data structure work okay with that? I would assume there is some sort of lazy iterator involved that may not work with array methods, or only work once.

This is JavaScript though…

Prototype pollution is bad. We learned this over a decade ago.

Good point!

I wonder what I would have to look for in my codebase in terms of what could break when dqsA starts returning an array instead of a NodeList?

The versions of those methods (map/filter/reduce/etc) that support any iterator (including upgrading NodeList "for free") have passed Stage 4 of the process, which means they will be in the next version of the standard and already starting to show up in some browsers.

https://github.com/tc39/proposal-iterator-helpers

you can use `$(queryGoesHere)` or `$$(queryGoesHere)` too from the devtool console.

Not every utility function is a one-liner. For example $.fn.one() or $.fn.on() with multiple events is easier to write with jQuery/Cash. Have a look under the hood: https://github.com/fabiospampinato/cash/blob/master/src/even...