thedavidprice

I (we) have seen these pieces before: replay, time-travel debugging, tracing, APM, event sourcing, etc. What I haven’t seen is the whole thing work as described in a production setting. I.e. capture enough of a production run that you can replay it locally, get the same inputs/results, and then trace a bad value back to where it came from.

Has anyone seen prior tech that got this whole combination viably working? Or is there true (potential) novelty here in the combination of production replay + value provenance + usable workflow?

How do you foresee region/country playing a part in the startups you choose to invest in?

I appreciate the term "existential round" as it highlights your intention.

Are there other individuals, angels, firms, etc. that communicate a similar focus and intention specifically for software? Maybe this is more common than I previously realized.

Tape.sh runs an Electron desktop app as one of it's 4 clients.

GraphQL is a multi-client solution. Is there something more you're specifically looking for?

Thank you for the reply. This is an interesting topic. I think at the core a comparison to Next is still apples to oranges imho and unnecessary here. But that's probably a distraction from the concepts at hand.

> Are they making simple spelling changes? Are they making changes to core languages (i.e. Typescript vs Markdown, etc.)? Are they adding a lot of new code and so forth.

I think what you're trying to get at here is answering the question, "Is PR A of greater quality or value than PR B?" I've decided that doesn't matter as much as:

- How easy is it for anyone to open and merge a PR of any kind?

- Once someone opens a PR, do they open another?

- What's the preexisting skill level of someone opening a PR relative to the difficulty of the PR they're attempting?

Trends. Over time. I can't tell you how many contributors start with simple doc updates (which, by the way, are as important as code for the Redwood community) and then follow up with a monster PR. Momentum builds momomentum. Collaboration leads to more collaboration. For the most part, "is A better than B?" is a distraction.

Again, all from my experience and not demonstrable otherwise.

> 4 months for both Next and Redwood and as it currently stands Redwood had 55 unique contributors and Next had 210

One of the reasons this likely feels low to me (in the case of # of Redwood contribs) is that we separate concerns across repos. Is this for the org or the repo?

It would be impossible to find an accurate number, but I'd be much more interested in the ratio of (unique contributors) / (project installations or downloads) and how that ratio trends over time.

For a metric like that, how might the Redwood vs. Next comparison play out?

;)

I've been living and breathing this project for over two years. From an "is the project healthy" perspective, your explanation of what you interpret from these analytics makes no sense to me. I suspect there's some pre-existing bias as well. (I.E. yes, Next is a very popular front-end React framework and it's been around for a few more years.)

Note: I love analytics. I just think this is, well, weird reasoning from the face of it.

I'll counter with this — here are the metrics I focus on as a measure of "is our open source project healthy"?

- How many unique contributors are there per release? && Is the number growing, steady, or decreasing?

- How many new contributors are there on a monthly basis && Is the number growing, steady, or decreasing?

tl;dr:

Redwood is healthy

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.

:)

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.

You make some great points here!

> I think the real benefit is an increase in the chance that you build your app in a way that's sustainable

Yes, indeed! We discuss "long-term maintainability" often in the project README and during interviews. This is one of the primary lessons Tom learned when building GitHub on Rails.

> ossifies your platform into a fixed point in the hype cycle

We are learning how to communicate these things better, but conventions, tight integration, and a "golden path" do not equate to lock-in of any kind.

If you read through other comments, you'll find a lot of examples where devs are using alternatives for the API as well as front-end libraries.

Tell me more about "obsolete", because I don't think you mean what that word means?