4 ms·

I've been working with Laravel since '13 and PHP since '99. Both just keeps becoming better and better to me. Recent years of needed improvement and feature de

by repox 2y ago

I've been working with Laravel since '13 and PHP since '99. Both just keeps becoming better and better to me. Recent years of needed improvement and feature development of PHP, keeps me happily invested in continuing with PHP as well. I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context.

anonzzzies 2y ago
> and leaving the community was the best decision for my mental health in a software development context. Undervalued sentiment.
jmnicolas 2y ago
> and leaving the community was the best decision for my mental health in a software development context. May I ask if it was for technical reason (JS ecosystem breaking constantly) or for people reason?
- repox 2y ago
  > May I ask if it was for technical reason (JS ecosystem breaking constantly) or for people reason? The "people" is the reason why the ecosystem keeps breaking and there's no consensus on how to do what; so the answer is both in a combination.
chipdart 2y ago
> I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context. That's an interesting statement, as it heavily contrasts with my personal experience. From the start, TypeScript felt as a breath of fresh air and the whole experience was very enjoyable. The only (and major) drawback was having to deal with JavaScript frameworks which required tsconfig.json/webpack voodoo to work at all, let alone with TypeScript, but once the project was sorted out everything was a pleasure. Can you point out the single most egregious thing you experienced with TypeScript?
- winrid 2y ago
  > once the project was sorted out The problem is this never happens. It's constant churn in that ecosystem to keep the build system working in any medium/large project, way more so than in any other backend runtime/package managers I've used. It's hard to quantify, maybe, but it just feels like constant stress. I've worked in bad Java shops where you wonder if the build will compile today. The average Node places are much worse in terms of the tooling and build system not working for whatever fancy reason on <insert day>. Recent example: Did someone at Google decide to merge a PR to a library two dependencies down? Because now shit won't compile, the compiler OOMs. Just what I wanted to figure out today, a crashing compiler on a minor library version change that nobody asked for.
  - noahtallen 2y ago
    It’s a challenge, but it’s not that bad. All the package managers have lock files, so no dependencies change daily until you update them. You could even have auto-update via dependabot or renovate and the smallest amount of CI would stop the breaking update from getting through. I’ve worked in a lot of node projects and never worried about whether they’ll compile today. Lock files have been standard/default practice for a long time. The hard part is actually doing the updates. So many breaking changes, so many new (often better) approaches, so many different tools that interact with each other in weird ways…
  - chipdart 2y ago
    > The problem is this never happens. It happens regularly to the point that it becomes the happy path. The trick is that you should pin all dependencies and not just let auto-updates happen, and instead treat even patch updates as if they could be major-version bumps. > It's hard to quantify, maybe, but it just feels like constant stress. I agree, but the key factor is auto-updates cause pain. Once you disable those you no longer experience any pain. For instance, no one needs to constantly upgrade dev dependencies, and even patch upgrades to TypeScript are hard to justify without full regression tests.
    - bguebert 2y ago

by repox 2y ago

anonzzzies 2y ago

> and leaving the community was the best decision for my mental health in a software development context. Undervalued sentiment.

jmnicolas 2y ago

> and leaving the community was the best decision for my mental health in a software development context. May I ask if it was for technical reason (JS ecosystem breaking constantly) or for people reason?

repox 2y ago
> May I ask if it was for technical reason (JS ecosystem breaking constantly) or for people reason? The "people" is the reason why the ecosystem keeps breaking and there's no consensus on how to do what; so the answer is both in a combination.

chipdart 2y ago

> I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context. That's an interesting statement, as it heavily contrasts with my personal experience. From the start, TypeScript felt as a breath of fresh air and the whole experience was very enjoyable. The only (and major) drawback was having to deal with JavaScript frameworks which required tsconfig.json/webpack voodoo to work at all, let alone with TypeScript, but once the project was sorted out everything was a pleasure. Can you point out the single most egregious thing you experienced with TypeScript?

winrid 2y ago
> once the project was sorted out The problem is this never happens. It's constant churn in that ecosystem to keep the build system working in any medium/large project, way more so than in any other backend runtime/package managers I've used. It's hard to quantify, maybe, but it just feels like constant stress. I've worked in bad Java shops where you wonder if the build will compile today. The average Node places are much worse in terms of the tooling and build system not working for whatever fancy reason on <insert day>. Recent example: Did someone at Google decide to merge a PR to a library two dependencies down? Because now shit won't compile, the compiler OOMs. Just what I wanted to figure out today, a crashing compiler on a minor library version change that nobody asked for.
- noahtallen 2y ago
  It’s a challenge, but it’s not that bad. All the package managers have lock files, so no dependencies change daily until you update them. You could even have auto-update via dependabot or renovate and the smallest amount of CI would stop the breaking update from getting through. I’ve worked in a lot of node projects and never worried about whether they’ll compile today. Lock files have been standard/default practice for a long time. The hard part is actually doing the updates. So many breaking changes, so many new (often better) approaches, so many different tools that interact with each other in weird ways…
- chipdart 2y ago
  > The problem is this never happens. It happens regularly to the point that it becomes the happy path. The trick is that you should pin all dependencies and not just let auto-updates happen, and instead treat even patch updates as if they could be major-version bumps. > It's hard to quantify, maybe, but it just feels like constant stress. I agree, but the key factor is auto-updates cause pain. Once you disable those you no longer experience any pain. For instance, no one needs to constantly upgrade dev dependencies, and even patch upgrades to TypeScript are hard to justify without full regression tests.
  - bguebert 2y ago