5 ms·

This is really short. I think my complaints, compiled into an article, would probably fill out an article five or ten times as long. There’s just so much shit.

This is really short. I think my complaints, compiled into an article, would probably fill out an article five or ten times as long. There’s just so much shit. Everyone made their own system. There’s .js .ts .mjs .cjs extensions. Theres’s tsc and jest and npx and create-react-app. These are just the tip of the iceberg. If I try to update the build system to use newer versions of the software, all sorts of stuff will break. The really shocking part, for me, is that I feel like it’s easier to set up my build system for C than for JS.

ramesh31 4y ago
It’s beyond repair. The future is Rust, Go, and Deno.
ravenstine 4y ago
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.
- andrew_ 4y ago
  Gulp and Grunt? Are you a time traveler from 2012?
  - jeroenhd 4y ago
    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.
    - coredog64 4y ago
      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.
    - andrew_ 4y ago
      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.
  - ravenstine 4y ago
    Yeah Grunt is pretty ancient but Gulp is still used in many places.
    - Zardoz84 4y ago
      Gulp it's really useful when your workflow gets out of what webpack, esbuild & cia expects
  - azangru 4y ago
    Look at the source code of web.dev site :-) It's Eleventy with gulp for asset management. https://github.com/GoogleChrome/web.dev https://github.com/GoogleChrome/web.dev
  - bluefirebrand 4y ago
    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.
    - toomanybeersies 4y ago
      At least (I hope) you weren't still using Bower.
  - jitl 4y ago
    ¯\_(ツ)_/¯ used to build Typescript: https://github.com/microsoft/TypeScript/blob/main/Gulpfile.js https://github.com/microsoft/TypeScript/blob/main/Gulpfile.j...
    - andrew_ 4y ago
      That is freaking bananas. Thanks for sharing.
  - aordano 4y ago
    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.
    - deleted 4y ago
      [deleted]
  - theteapot 4y ago
    2012 === bad. 2022 == awesome!
- klodolph 4y ago
  Problem is that a ton of random stuff breaks when you "type": "module". Unexpected stuff, like Prettier.
  - BigJono 4y ago
    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.
    - ThalesX 4y ago
      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…
andrew_ 4y ago
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.
- kahnclusions 4y ago
  Yeah. We have both Scala and Node (TypeScript) backend services and honestly the latter are much nicer to work on.
wonnage 4y ago
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`.
deleted 4y ago
[deleted]
inopinatus 4y ago
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.
- engmgrmgr 4y ago
  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.
  - klodolph 4y ago
    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.
hinkley 4y ago
I could write an article solely about npm and just the swear words would take up more space than this article.

ramesh31 4y ago

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

ravenstine 4y ago

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.

andrew_ 4y ago
Gulp and Grunt? Are you a time traveler from 2012?
- jeroenhd 4y ago
  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.
  - coredog64 4y ago
    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.
  - andrew_ 4y ago
    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.
- ravenstine 4y ago
  Yeah Grunt is pretty ancient but Gulp is still used in many places.
  - Zardoz84 4y ago
    Gulp it's really useful when your workflow gets out of what webpack, esbuild & cia expects
- azangru 4y ago
  Look at the source code of web.dev site :-) It's Eleventy with gulp for asset management. https://github.com/GoogleChrome/web.dev https://github.com/GoogleChrome/web.dev
- bluefirebrand 4y ago
  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.
  - toomanybeersies 4y ago
    At least (I hope) you weren't still using Bower.
- jitl 4y ago
  ¯\_(ツ)_/¯ used to build Typescript: https://github.com/microsoft/TypeScript/blob/main/Gulpfile.js https://github.com/microsoft/TypeScript/blob/main/Gulpfile.j...
  - andrew_ 4y ago
    That is freaking bananas. Thanks for sharing.
- aordano 4y ago
  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.
  - deleted 4y ago
    [deleted]
- theteapot 4y ago
  2012 === bad. 2022 == awesome!
klodolph 4y ago
Problem is that a ton of random stuff breaks when you "type": "module". Unexpected stuff, like Prettier.
- BigJono 4y ago
  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.
  - ThalesX 4y ago
    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…

andrew_ 4y ago

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.

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

wonnage 4y ago

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

deleted 4y ago

[deleted]

inopinatus 4y ago

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.

engmgrmgr 4y ago
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.
- klodolph 4y ago
  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.

hinkley 4y ago

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