> 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?
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.
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.
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.
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?
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".
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?
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.
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
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.
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.
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.
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.
I usually import the two functions from a module like this:
import { dqs, dqsA } from '/lib/js/dqs.js';
This is the module:
https://github.com/no-gravity/dqs.js