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.)
import { x } from '/a.js';
import { y } from '/b.js';
import { x } from '/a.js';
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?
Besides, if you’re working with a codebase of non-zero complexity you need imports/require/whatever anyway.
Modules aren't hard anymore.
May be learn to do the basic of YOUR JOB for once, some "software engineer".
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".
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.
Better KISS and fit all of JS in a single script.
which costs time
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.
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?
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?