3 ms·

The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't bu

The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening. And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer. And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? Webpack, Vite, blah blah.

realusername 3y ago
> You install a package today. In 3 months, that code won't build. And you are even generous, if you force upgrade every package you have in a month, I'm pretty sure you will have broken stuff.
LaGrange 3y ago
> You install a package today. In 3 months, that code won't build. Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine. > And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? ..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.
- progmetaldev 3y ago
  Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. I still tend to build out classic MVC applications, and use JavaScript only for progressive enhancement. I've been able to move from .NET Framework to the different versions of .NET Core, and now just .NET. I just follow the documentation, Microsoft has great documentation on how to upgrade. It just sounds like you are more familiar with working with front-end tech, and I would hazard a guess that you are actually much better at it than you either let on, or believe you are (Impostor syndrome, I get it all the time until it's crunch time, and then you just get things done). I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. This is coming from someone that still uses Grunt for their front-end build pipeline. It's not the newest, but it's still well supported, and I know it very well and can pull off a lot with it.
  - LaGrange 3y ago
    > Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. What front-end tech, everything is typescript. Also not upgrading. I need to read the readme file because I didn't run the software in 3 months. Point is, it will _still run_. It might need a few updates for security reason, but it will _not_ magically stop working. > It just sounds like you are more familiar with working with front-end tech, No. I'm a full-stacker, but very much focused on backend, and actually mostly in Python. But nodejs + typescript actually works well enough that, even with _decades_ of Python experience, I now need a proper reason to pick it over typescript for a new thing. > I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. Yep. Maybe the reason why some folks struggle so hard with running their old JS stacks, rather than some .net superiority?

realusername 3y ago

> You install a package today. In 3 months, that code won't build. And you are even generous, if you force upgrade every package you have in a month, I'm pretty sure you will have broken stuff.

LaGrange 3y ago

> You install a package today. In 3 months, that code won't build. Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine. > And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? ..."webpack.config.ts", "package.json" and "package-lock.json" is not 100s. I mean I've seen places with, like, _a dozen_, but those folks could do the same to bash scripts and Python, some people are just messy about it.

progmetaldev 3y ago
Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. I still tend to build out classic MVC applications, and use JavaScript only for progressive enhancement. I've been able to move from .NET Framework to the different versions of .NET Core, and now just .NET. I just follow the documentation, Microsoft has great documentation on how to upgrade. It just sounds like you are more familiar with working with front-end tech, and I would hazard a guess that you are actually much better at it than you either let on, or believe you are (Impostor syndrome, I get it all the time until it's crunch time, and then you just get things done). I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. This is coming from someone that still uses Grunt for their front-end build pipeline. It's not the newest, but it's still well supported, and I know it very well and can pull off a lot with it.
- LaGrange 3y ago
  > Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. What front-end tech, everything is typescript. Also not upgrading. I need to read the readme file because I didn't run the software in 3 months. Point is, it will _still run_. It might need a few updates for security reason, but it will _not_ magically stop working. > It just sounds like you are more familiar with working with front-end tech, No. I'm a full-stacker, but very much focused on backend, and actually mostly in Python. But nodejs + typescript actually works well enough that, even with _decades_ of Python experience, I now need a proper reason to pick it over typescript for a new thing. > I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. Yep. Maybe the reason why some folks struggle so hard with running their old JS stacks, rather than some .net superiority?