Listen, I really am sorry that you guys had trouble, and I really appreciate the support you gave. Did you come to me when you had these regressions? If there's one thing it's that I am responsive to issues, especially with sponsors.
Ehsan is a decent developer, and I'm not sure what you mean by "to release takeout". But I don't appreciate the end of your comment, I'm being pretty frank here and admitting we had regressions.
It feels a bit more like you want to offload a failure entirely to me. I don't think it's a smart strategy to be updating hundreds of dependencies many times within a few month period. Tamagui has generally been stable and we have tons of success stories, and I get thanks literally daily from people.
Again, I don't deny that we have had regressions and instability, especially around January when we had a bug slip through that we missed for a week, and that was hard to fix due to a change that was merged after it. That was one of the worst two weeks of my life - I spent an entire period of 4 days over a weekend with 3 hours of sleep on average each night fixing that issue.
But I think the real and true story is that Tamagui has been generally stable for quite a long time, and if you compare it to the 50+ libraries you'd need to glue together to make up a similar surface area it likely would be more stable.
Tamagui is impressive, but TBH it's sounding like this is a bug, not a feature.
> So I don’t think it’s surprising if you have regressions when upgrading 200+ packages for any project, and I also don’t think you should upgrade it honestly more than once every six months.
In my experience it gets exponentially harder to upgrade packages the longer you let them get out of date.
On the second part - I think that's true if you're upgrading across many minors, or a major. But we've not released a major in nearly 2 years. For the most part you can upgrade pretty big gaps in Tamagui. And again, we're incredibly responsive to people who give us a reproduction of any issue.
So I don’t think it’s surprising if you have regressions when upgrading 200+ packages for any project, and I also don’t think you should upgrade it honestly more than once every six months.
Second point is that we also moved (and had to move) much faster than a typical project. Because we had so many packages and were solving very hard problems, we had a lot of ground to cover. We never broke any API surfaces in a minor or patch, but we weren’t afraid to improve our underlying code because if we didn’t, on a project of that scale, we’d have quickly succumb to tech debt. A good chunk of our UI kit was under the “beta” tag until recently.
That said I’ll take responsibility for it. I wonder when this was that you adopted it, I think we’ve gotten a lot better over time as things have stabilized. We stopped adding features over a year ago now, and have entirely focused on stability, performance and documentation since.
A final note is that I have never been full-time on Tamagui, it’s always been a side project of mine while I had a full time job. We have a large test suite, but again, the surface area of the project is simply massive.
Now that I am full time on One and Tamagui, I am looking forward to proving that we know what we’re doing. We’ve hired great developers and have greatly expanded testing even just in the last few months.
One is a lot simpler than Tamagui. Like… not 10x simpler, closer to 1000x simpler. I keep telling people: a universal framework is surprisingly simple compared to a universal style library + UI kit.
Editing to add one more point of context. One of the best and pickiest developers I know - Fernando Rojo - has been using Tamagui since the beginning. He even wrote his own style library before Tamagui. He recently started on a new side project that he wants to turn into a real venture down the road, and he is using Tamagui for it. It’s actually one of my most proud accomplishments. It’s an extremely strong signal imo, as someone who is known for NIH and being very picky to choose such a big dependency like Tamagui again.