Yes, there is a lot of shit, but stick to ES2015+ and you'll be mostly fine. No reason to continue with the .cjs .mjs crap. Either set "type": "module" or use Deno (the superior option) and don't look back. If others still want to use Common JS, that's their problem. Yeah, a lot of modules won't work out of the box because they're Common JS, and visa versa, but screw Common JS. That and goofy junkware like Gulp and Grunt which are overcomplicated, change their APIs frequently, and don't really do anything better than a Makefile. Ok, Gulp might be helpful if you're running Windows, but I pity those who still do web development on Windows without WSL2.

Gulp and Grunt? Are you a time traveler from 2012?

¯\_(ツ)_/¯ used to build Typescript: https://github.com/microsoft/TypeScript/blob/main/Gulpfile.j...

That is freaking bananas. Thanks for sharing.

Gulp is practical to insert extra behavior if you have a multi-step build process and are allergic to Webpack. Just write a gulpfile and spawn whatever you need spawning, like some glorified bash that is already in JS so you don't need to manage more languages.

I worked on a project using Gulp and Grunt as recently as 2020.

This was a product the company I was working for inherited from a merger. They bought the company for this product.

It was a nightmare of bad software practices. Still using Gulp in 2020 was only the tip of the iceberg.

At least (I hope) you weren't still using Bower.

Look at the source code of web.dev site :-) It's Eleventy with gulp for asset management.

https://github.com/GoogleChrome/web.dev

Both still work fine to this day. I don't know what the exact (dis)advantages of the competing toolsets are, but if you know Gulp and Grunt then I don't see why you wouldn't use them.

Was helping an org migrate off of CloudFoundry and Grunt gave us no end of trouble. In the end, we wound up building with Node 8(!) and then praying that everything would still work with a 12.x runtime.

unless one is in need of piping files (and streams) in a complex and prolific way, npm scripts or a makefile can supplant Gulp/Grunt with much less overhead.

Yeah Grunt is pretty ancient but Gulp is still used in many places.

Gulp it's really useful when your workflow gets out of what webpack, esbuild & cia expects

2012 === bad. 2022 == awesome!

Problem is that a ton of random stuff breaks when you "type": "module". Unexpected stuff, like Prettier.

Oh no, whatever will the world do without Prettier turning nicely formatted JS into a pile of unreadable shit because line 218 was 71 characters long instead of 69.

I’ve recently had a PR that Prettier would add 2 extra whitespace and Lint would complain about it. And these were in the same build process. The resolution was for me to change my code…

I reflected recently that, for years, I've carried a previously unverbalised and deep-seated expectation that JavaScript Will (Eventually) Be Replaced.

The language contains so many lurking horrors, accreted over the years, that it might even seem irrational to assume otherwise.

I suspect this sense of ephemerality then pervades the entire extended ecosystem, including all JS derivatives, reducing everyone's time horizon to maybe the next eighteen months at best. Thus the roulette wheel of broken tools keeps spinning.

I think these arguments often miss the “for who” both in the producer and consumer sense.

If you have a team or teams of engineers, having one or two people deal with all the dev-ops stuff makes a lot of problems go away.

But if you have a large C++ project for example, you probably need more than a couple people focusing on build and target dev-ops work, or at least a lot more of their time.

It’s a lot easier to get a frontend person to help out with the backend dev-ops than it is to hire a new C++ guru and wait a bunch of time to catch up on the nuances of your build systems/org/whatever.

Anecdotally, I see the people who balk at Node are usually enterprise Java devs, backend Python devs, or junior Go/Rust enthusiasts.

At the end of the day, all these languages can interoperate with all the others in a bunch of different ways, and an organization’s ability to engineer and maintain systems is mostly orthogonal to its choices of “driver” technologies.

Anecdotally, I've met a ton of people who balk at Node for backend stuff. I've been at two companies where it was actually prohibited.

> At the end of the day, all these languages can interoperate with all the others in a bunch of different ways, and an organization’s ability to engineer and maintain systems is mostly orthogonal to its choices of “driver” technologies.

I think people say that in an interest to keep the peace, but the assertion doesn't stand up to close scrutiny. Poor technological choices kill companies, or at the very least, make them perform more poorly. Choosing the right technology is a core skill for technology companies.

The problem is that each company is a goddamn unique snowflake. Company X has a bunch of front-end developers and spends most of their money on headcount. Company Y has a bunch of back-end developers and spends most of their money on infrastructure. The "best language for a project could be R, Python, Go, Rust, C++, TypeScript, C#, Java, or something else. Picking the wrong language can sometimes be outright disastrous compared to picking a good language. But most of the time, there's no clear "best" language.

Even though there's no clear "best" language, these people balking at Node may have a point.

This isn’t merely about tools. They’re one piece of a much larger puzzle. The fragmented chaos of the Node ecosystem arising from that aforementioned ephemerality ensures that eighteen months is roughly the duration before bitrot of dependencies is corrosive enough to have folks talking about rewrites. In four decades driving keyboards in various capacities, I’ve never seen any language experience dependency rot in production apps so rapidly as JavaScript and its offspring.

Aside: any shop operating under the assumption that devops is a function you assign to someone, has already failed devops 101.

I genuinely don’t believe you’re coming at this from a business stakeholder POV, which is fair for HN. But if you have to advocate for a devops org outside of some massive global scale or as a small % of revenue, you’re doing something wrong.

Unfortunately a proven playbook for struggling devops teams is to just fire all the devops and infra folks, which seems to help with platform stability, recruiting, and velocity year over year.

Your opening assumption is false. I start and run businesses.

Any reference to “devops team” is also automatically failing at devops. It’s not a job, a task, or a team. I don’t spare much time for folks encumbered by a silo mindset. It’s the antithesis of a service/product-team approach, and (to the actual point) does nothing to oppose the myopia I’m accusing the JS ecosystem of.

I do almost exclusively backend and DX development on Node and it's a joy. None of the frontend world's problems.

There is value in an ecosystem that lets you do it "your way," rather than enforcing convention. It's not for everybody though.

Yeah. We have both Scala and Node (TypeScript) backend services and honestly the latter are much nicer to work on.

Theoretically if you just used a runtime that didn't depend on code being transpiled and transformed a million times over (e.g deno) you could just run your damn code. It would even work in the browser, if you used `import/export` syntax instead of `require/module.exports`.

I don't buy the argument that the existence of separate binaries for the typescript compiler, test runner, packaging system, etc. is somehow unbearably confusing, I would almost prefer that over certain other languages where one magic command does it all. Although if you like that, you could try `bun`.

I could write an article solely about npm and just the swear words would take up more space than this article.

It’s beyond repair. The future is Rust, Go, and Deno.