Your post was something of a blast from the past for me: toolbars! I had forgotten about those. I used to spend a lot of time customizing those. Then Chrome was released which really was the end for browser toolbars.

Cool. Most of these were new to me too. I will likely forget them again until I read about them in another blog post but interesting nonetheless.

What an uninteresting (set) of posts on HN's frontpage..

I see the irony of my uninteresting comment too! This is just not the content I come to HN for at all.

I'm getting these recently too as Android notifications. It's very annoying and could be very unprofessional or hard-to-explain if one came in at the wrong time.

Me too, although FWIW on Android I opened Drive, then to "Settings" under the hamburger menu, then "Notification Settings", then I unchecked the "Shared items" notifications.

That may not work for you if you want shared item notifications, but I already get bombarded by a million different notifications for everything (sometimes I hate the modern world) and I sure as hell don't want shared item notifications - if something is important enough that I should read it, the person who shared it to me will email me about it.

The alternative here is that you DoItYourself from the start and never launch or burn company money _before_ you even have a product or users.

I think that's taking the extreme end. Couldn't someone use a larger framework, for example Spring? It's pretty productive with Spring boot, but also large enough that you can expand for your use case. I'm not advocating for Spring per se, as I think .Net core is equivalent.

I was talking in wider terms of not using a framework at all and not specifically about Redwoodjs.

I can't speak to whether RedwoodJS will lead you down a path of working around it.

I'm a Redwood user for my side project that I hope to launch in the next few days. For me Redwood has been great. I know React but was always frustrated with expanding past the UI layer e.g. data fetching, storing. I had tried NextJS in the past (didn't love the filename routing approach) but never actually got anything to production.

I'm in an architect role for work now and I get to code less and less during the day. RedwoodJS has enabled me to actually build something in my own time and (hopefully) launch it.

I didn't know GraphQL or Prisma before starting to use it but between the Redwood docs, Prisma docs and with some RW community help I've made good progress.

This is wind in our sails. Thank you for posting.

And please do show off what you've built! I'd love to see it.

What do the cool kids use instead of Yarn these days?

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.

:)

> Attractive men behave in the stereotypical alpha manner, very aggressive without any empathy.

I have rarely found that statement to be true.

Well then I have a great solution for you: don't pay for it. You're not in the market for this app. It's akin to crying because you can't afford an expensive car.

Have you considered moving from management back to engineering? It sounds like you were a software engineer previously. How did you find that?