3 ms·

I started using Go at work ~2 years ago and I love it, especially for the backwards compatibility. But my personal projects up until then were node.js backends

I started using Go at work ~2 years ago and I love it, especially for the backwards compatibility. But my personal projects up until then were node.js backends written with Typescript. Those personal projects are essentially stuck in time because of the whole ESM/commonjs mess that is modern javascript. Some of the npm package I use have been updated to only support ESM modules, while others will never be updated, some are half and half. It's in such a bad state that I've decided if it does ever fully break I'm just going to re-write the backend in Go, and I know I'm not the only one just frustrated with the modern javascript ecosystem and have projects stuck on old node.js and npm package versions because of it.

cookiengineer 3y ago
Babel was the most enterprise thing that could happen to the JS ecosystem. Gone are the simple distribution channels, and all build pipelines have 100s of megabytes of legacy crap that nobody actually ever executes. If you want to tell me your page is working in IE6, you're lying. It will break apart in all places. Anybody remember bower and pikapkg? That was the peak in my opinion.
- nobleach 3y ago
  Oh my.... yes. For me, that would have been Angular 1.x days. And while it was neat having a tool that could pull a deterministic flat list of dependencies, I wouldn't go back to those days. I do wholeheartedly agree that injecting core-js into every single build, in the rarest of cases that you'd need to support a browser that doesn't support generators, or some other featured added around 2015, is just plain silly. I cringe when I look at a dependency graph and see all those polyfills in my builds!!
joshstrange 3y ago
In your position I'd probably do the same thing and no doubt the ESM/commonJS mess is a mess and huge PITA. All that said I'll probably continue with my TypeScript/NodeJS backends since I just absolutely love writing TypeScript and I love sharing code between the front and backend. I use JS/TS in my day job (frontend only) as well so it's super nice to be able to benefit from that knowledge/practice. I also use TypeScript to write a few apps (some for work, some for my side project, some for personal use) so staying in the TypeScript ecosystem for almost everything I do is really nice. Again, I'm not defending that annoying/bad parts of TS and certainly not saying I've escaped the ESM/commonJS hell unscathed, just that I use TS everywhere and I generally have a lot of fun writing/running it.
madeofpalk 3y ago
The whole Nodejs ESM thing is the result of a bunch of different parties - Node, Typescript, Babel/Webpack/etc - with a lot of influence over the ecosysten with conflicting priorities. This is the price of truely "open" standards. One of the reasons why it's such a mess was due to bending over backwards maintain backwards compatibility. It's a mess. It's frustrating as a user/developer. Go has it significantly easier by having just one central organising factor behind the ecosystem. If there were multiple Go implementations, some moving faster on the spec (or even ahead of it) than others, then you would find the same pain there also.
deleted 3y ago
[deleted]
mattlondon 3y ago
> ESM/commonjs mess that is modern javascript No - only a mess in the node/npm scope. JavaScript modules are just fine if you stay away from npm and node. Node and npm are a total dumpster fire, but that is not all of JavaScript.
- pseudosavant 3y ago
  Agree that node/npm are the dumpster fire of JS, but ESM is still going through growing pains too. I have switched off of Node over to Deno. It natively supports ES modules. But most of the time I try to consume an ESM the code was designed to only load in a browser. It gets especially complicated if the ES module is using something like WASM - using FFMPEG via an ESM using WASM is the current use case I'm working on.
latchkey 3y ago
I've been maintaining a fairly popular (~40k downloads/mo) react component library for about 4 years now. It is a clusterf'ck to keep things up to date with changes over time. React itself has broken things several times. I knew in advance that this would be a challenge, so when I started the project, I wrote a lot of unit tests. The first test for each component was just a snapshot output of it. Then I had other tests for functionality and have added tests over time for bugs. That has saved my ass so many times. I don't know how anyone maintains a JS project without comprehensive tests. Actually, I do... as you said, they never upgrade anything.

cookiengineer 3y ago

Babel was the most enterprise thing that could happen to the JS ecosystem. Gone are the simple distribution channels, and all build pipelines have 100s of megabytes of legacy crap that nobody actually ever executes. If you want to tell me your page is working in IE6, you're lying. It will break apart in all places. Anybody remember bower and pikapkg? That was the peak in my opinion.

nobleach 3y ago
Oh my.... yes. For me, that would have been Angular 1.x days. And while it was neat having a tool that could pull a deterministic flat list of dependencies, I wouldn't go back to those days. I do wholeheartedly agree that injecting core-js into every single build, in the rarest of cases that you'd need to support a browser that doesn't support generators, or some other featured added around 2015, is just plain silly. I cringe when I look at a dependency graph and see all those polyfills in my builds!!

joshstrange 3y ago

In your position I'd probably do the same thing and no doubt the ESM/commonJS mess is a mess and huge PITA. All that said I'll probably continue with my TypeScript/NodeJS backends since I just absolutely love writing TypeScript and I love sharing code between the front and backend. I use JS/TS in my day job (frontend only) as well so it's super nice to be able to benefit from that knowledge/practice. I also use TypeScript to write a few apps (some for work, some for my side project, some for personal use) so staying in the TypeScript ecosystem for almost everything I do is really nice. Again, I'm not defending that annoying/bad parts of TS and certainly not saying I've escaped the ESM/commonJS hell unscathed, just that I use TS everywhere and I generally have a lot of fun writing/running it.

madeofpalk 3y ago

The whole Nodejs ESM thing is the result of a bunch of different parties - Node, Typescript, Babel/Webpack/etc - with a lot of influence over the ecosysten with conflicting priorities. This is the price of truely "open" standards. One of the reasons why it's such a mess was due to bending over backwards maintain backwards compatibility. It's a mess. It's frustrating as a user/developer. Go has it significantly easier by having just one central organising factor behind the ecosystem. If there were multiple Go implementations, some moving faster on the spec (or even ahead of it) than others, then you would find the same pain there also.

deleted 3y ago

[deleted]

mattlondon 3y ago

> ESM/commonjs mess that is modern javascript No - only a mess in the node/npm scope. JavaScript modules are just fine if you stay away from npm and node. Node and npm are a total dumpster fire, but that is not all of JavaScript.

pseudosavant 3y ago
Agree that node/npm are the dumpster fire of JS, but ESM is still going through growing pains too. I have switched off of Node over to Deno. It natively supports ES modules. But most of the time I try to consume an ESM the code was designed to only load in a browser. It gets especially complicated if the ES module is using something like WASM - using FFMPEG via an ESM using WASM is the current use case I'm working on.

latchkey 3y ago

I've been maintaining a fairly popular (~40k downloads/mo) react component library for about 4 years now. It is a clusterf'ck to keep things up to date with changes over time. React itself has broken things several times. I knew in advance that this would be a challenge, so when I started the project, I wrote a lot of unit tests. The first test for each component was just a snapshot output of it. Then I had other tests for functionality and have added tests over time for bugs. That has saved my ass so many times. I don't know how anyone maintains a JS project without comprehensive tests. Actually, I do... as you said, they never upgrade anything.