Dunno, they don't invite me and my yarnie buddies to their parties.

Ha! My thoughts exactly. If I had more time it would make for an interesting post about all the lessons learned as we navigated the pains of Node.js in all its forms.

Lesson One — Building and Bundling are hard but don't make it harder.

We (by that I mean Peter and Danny) took a hard look at new tools, and, well, they let us down. We reverted a few steps that took us months to figure out. But we learned. And someday we'll make a move to different tooling. But in our opinion, those tools are not ready yet. (Side note: I read a tweet about how buggy SWC is with Next. Anecdotally, although we're stoked for the future of SWC, it remains as a draft PR yet to be merged in the Redwood Repo. We also reverted the primary part of our ESbuild implementation. So the tweet jived for me with our experience.)

The hype is all about speed and performance. But I think the reality is fairly simple:

- implementations become unintelligible spaghetti over time

- everyone has been burnt by having to manage this themselves

- poor implementations lead to diminishing performance

Turns out the existing tools are fairly robust. But to use them we spent an epic amount of time tuning and refactoring. It's complex. But it isn't broken. If you're willing to let good enough be good enough, set a benchmark, hit it, etch it in CI, and call it good.

Lesson Two — Let go but pin the packages

Note: We chose to have @redwood packages include all the dependencies and config and integration under the hood. Redwood apps have very little package overhead out of the box. This means we have to tame the dragon behind the scenes.

The "cool kids" seem to be moving to pnpm (and/or Yarn pnp). I've been burned many times by the monstrosity that is node_modules, but, to be fair, it's also fairly incredible what we're able to achieve. I don't think any one package manager is going to be the cure for what ails us. But I do think it's possible to MakeItWork regardless of what you choose:

- pin your packages because the dependency of your dependency is your enemy

- lean hard into CI; then lean harder

- stay current; give in and let Renovate update

Yarn 3 is a phenomenal tool. (Plus the core team is top-notch.) And we're not even using pnp yet. We do have a long way to go and yes, a faster install would be great and a smaller size on disk and etc. and etc. But, again, I think people have been burned by having to figure it out themselves and finding things unmaintainable in the long run.

---

I'm tired and likely not making much sense anymore. I might have lost the thread, but I think the overall point I was trying to get to is this --> zOMG I'm so tired of talking about build tools and package managers and chasing incremental performance gains and can't we just focus on features that move the needle and have fun again? Oh, and PIN your damn packages 'cause that "^" is nothing but trouble!

Thank you and good night.

:)

I don’t know much about rollup, it doesn’t seem to be that different, but some of the newer tools are rust and go based and better tuned for performance during development. JS tooling is generally slow and weirdly complex, and people seem to acknowledge these issues and improve on them.

that's just how our industry behaves. we like shiny new conveniences and tend to want to adopt them as soon as they're viable.

this moment with postgres, node, webpack, babel, scss, and react feels off in a way. there are genuinely more capable alternatives to all of those that take less time to learn and work effectively with, perform better, cost less, and are trusted by big institutions. rails never felt this entrenched when it was the leading default, for example.

there are a lot of positives to this that non-web engineers have seen for a long time--education becomes better and more accessible, people can have more stable and successful careers, and groups can take on more ambitious missions--it's just surprising from how i've seen web engineers approach their trade over the past 15 years