21 ms·

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

by Kiro 2y ago

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.
croes 2y ago
Left-pad anyone?
- sadeshmukh 2y ago
  It's in their codebase.
- Kiro 2y ago
  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.
eastbound 2y ago
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?
- genuinelydang 2y ago
  What? If you don’t have external dependencies, just remove your bundler/transpiler and rely on browsers to import your code.
- afavour 2y ago
  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.
- jazzypants 2y ago
  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.
- nsonha 2y ago
  > 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".
- WorldMaker 2y ago
  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".

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

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

croes 2y ago

Left-pad anyone?

sadeshmukh 2y ago
It's in their codebase.
Kiro 2y ago
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.

eastbound 2y ago

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?

genuinelydang 2y ago
What? If you don’t have external dependencies, just remove your bundler/transpiler and rely on browsers to import your code.
afavour 2y ago
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.
jazzypants 2y ago
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.
nsonha 2y ago
> 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".
WorldMaker 2y ago
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".