Regarding "require" vs "import", I find this to be a constant nightmare trying to choose one or the other. The browser and tooling for writing for the browser has all-around excellent support for using "import".

Then, at some point, I want to run some unit tests using Jest or something, and it turns into a total fucking nightmare. Each bit of tooling has certain expectations for how it expects you to import--relative vs non-relative? Do you include the .js at the end? What about .ts at the end? (That one is always "no".) Do you need .js / .mjs or .cjs / .js? Do you use ts-node? Do you want to see a warning printed to stderr every time you run Node?

The answers to this in 2022:

1. Doesn't matter so much as long as you're using newest versions of either one. Newest yarn has plugin support which is neat. Npm has more stable backing and an open roadmap. Could be some considerations regarding monorepo support, but otherwise either is fine.

2. Yes

3. Use ES6 modules

4. Jest + Cypress

5. Vite

* Note: this is only valid for the time of writing. We cannot guarantee these libraries will still represent the state of the art past this date.

I guess your point is that this would change constantly, which isn't really the case.

Yarn and NPM has been around for a long time. Yarn 1 used to be the better choice since NPM stagnated, now they're a bit more equal.

Typescript has been around for a long time. So has ES6 modules. Same for Jest and Mocha.

The only thing that is changing somewhat are the bundlers and build tools (thankfully, they've been the weakest part of FE dev for a long time).

I've kept up with frontend for many years. There really isn't all that much "fatigue" if one actually understands what the tools do and the niches they fill.

I agree with this persons answer, if your goal is to go full custom. If you want all this setup done for you I suggest NextJS. It should be noted that Deno is not a bundler but an entirely different JS Runtime. The question should be do I use Node or Deno.

I think for many people NextJS or Nuxt should really be the first choice rather than going for e.g. Create-React-App or some generic boilerplate.

Great questions. 3 years from now you will have completely different answers.

I often find my choices will rub up against each other a lot. I never know whether to build glue code because that's the right way, or I should have picked a different library.

It's too fine grained.

This really hits home for another JS outsider that likes the language but not the ecosystem. I like to do small personal projects in Node. Simple things like consuming the Google Sheets API feel great, but when I want to expand the scope of the project and start thinking about tests, caching, and "am I doing my modules/imports/package management the RIGHT way" I usually give up or switch to a different stack.

Have you tried Deno? if you hate setup and want it all to just work. I highly suggest it.

> * which test framework? Mocha? Karma? Jest? Cypress?

Most of the dependencies you will install will have no tests at all anyways. This is another issue of its own, you are building on very weak foundations.

This is a pretty huge assumption.

Anybody who had to maintain & keep up to date a large node codebase knows what I'm talking about. Testing is an afterthought at best and non-existent in a lot of packages. I'm not talking about the top packages of course, just the N+4 small packages you depend on.

Why wouldn't you just use a JS framework that takes care of all of those questions for you?

I think these are great questions. As someone who has been doing Golang for a couple of years and just got back to doing Node.js development again, I can answer some of these questions. I'll add that most JavaScript developers never think about these questions btw.

* Should I use npm or yarn?

This is one area where JavaScript is notoriously weak. As another comment mentioned, the answer might be different a couple of years from now. I discovered a package manager recently named `pnpm` and it is incredible, quite frankly. That being said, any package manager will do. They all work well (relatively, npm gets very slow in bigger projects).

* Should I introduce Typescript to be able to handle complexity better?

In 2022, the answer to this is almost always yes, for backend systems. I think this is unfortunate because you do need a transpiler. But its ease of use and type safety are hard to pass up once you've used it on a project. For frontend I tend to be more lax, although a lot of developers argue you should use TypeScript there too.

* Which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?!

Nowadays you'll likely only use `import/export`, especially if you're using TypeScript. This is not a question most JavaScript devs ask on a daily basis.

* Which test framework? Mocha? Karma? Jest? Cypress?

The short answer is it doesn't matter. The longer answer is that if you want assertions and snapshot testing built-in, Jest is a good choice. If you decide to go with Mocha, you'll need an assertion library (most commonly Chai). You probably don't want to use Karma as it was originally designed around Angular 1.x and it's starting to show its age.

Cypress is an end-to-end testing framework and has nothing to do with the rest. You'd use it in place of something like Protractor or Selenium. Additionally if you're using something like GraphQL you probably won't be able to use Cypress without a lot of hardship.

* Should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?!

This is only relevant in the frontend nowadays. And you'll probably want to use Vite. `esbuild`, while an amazing project, is a bit too verbose to set up and Vite uses it under the hood. IMO Grunt and Gulp and Webpack have never been good bundling systems (I dread every time I have to use these), so any new innovation in this area is welcome.

I see a lot of people complaining about the constant churn. I'm of the opinion that the JavaScript ecosystem is constantly improving. Vite and pnpm are absolutely amazing and I wish I would have had these tools when I was first doing frontend development. I would argue that every year JavaScript development gets way easier, not harder, and now it's the most accessible it's ever been.

Unfortunately, the amount of options can get overwhelming. Off the top of my head, there's a ton of HTTP frameworks (Express, Koa, Sails.js, Hapi.js, Nest.js, etc.) The list goes on. However I don't think this is a fair argument against JavaScript. There's a lot of choice in the Python and Golang world too. Just make good choices (maturity, stability, support) and don't always choose the newer, shinier framework, and you'll seldom run into problems in the JavaScript ecosystem IMO.

Thanks, this was helpful.

I looked at pnpm and I like it... so it's bringing the Maven strategy of having ONE place where dependencies are downloaded to and shared between projects to JavaScript!?.. which has been used since early 2000's in Java land... :D good.