Don't make me think, or why I switched to Rails from JavaScript SPAs

Ruby's not as consistent as you think. I can pull single examples out too -- is it 1.upto or 1.up_to? And I've never had a problem with Python's pluralization.

> In Ruby it's Time.now, come on people.

YMMV, but I don't find it terribly burdensome to import datetime and call datetime.now().

And there was Sails and any number of other attempts at this.

A key strength for Rails is Ruby and a key weakness for any aspiring JS equivalent is JS and the JS ecosystem.

If the Rails team had had to spend time adapting to 6 different alternatives to bundler, rack, and every other library they use it wouldn't be what it is today.

Haha that was my reaction when I first picked up Laravel.

I'm pretty sure every new dev has the same reaction when picking up their first opinionated framework.

I agree with the author's core assertion that throwing too many decisions at a project right away makes it difficult to even get started. It increases the risk of hitting analysis paralysis right away. I've rarely worked with Rails, but when I did, I really enjoyed its approach to sensible defaults, easily overridden if needed. I hope that's still available, and I think other frameworks benefit from following that approach.

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.