[nickreese]

We were an early adopter and sponsor of Tamagui. Impressive tech but massively unstable even on minor version bumps. We even had a core team member working on the project and the breakage was every version. Lost more than 6 months of time relying on it. Ultimately we killed the project because of the decision to go with Tamagui. Just an FYI for those considering this. Abstractions on unstable abstractions is a good way to hate your project.

[seec]

I feel sorry for your problems, but to be honest I'm reading the discussion here to understand what others think and who exactly can buy in that sort of "too good to be true" ideal solution.

Because to me it just looks like another shiny thing that tries to be everything to everyone and ends up doing nothing good. They seem to be good salesmen, but less competent devs, at least when it comes to creating real innovation, not repacking old code/ideas.

I'm saying that because, both of their websites are so bad that they create problems in Chrome, something that is rather rare nowadays with an adblocker; the Tamagui one repeatedly eats memory and crash in tab and the One seem to have some rendering issues.

It did not investigate because I don't really care, but I'll say it doesn't inspire confidence at all and in my opinion, it is largely enough evidence to dismiss the whole thing as a toy project of semi competent devs.

In another comment, I have seen you drop the hypocrisy and be a bit mad about the support you gave for disappointing results. I think the one you are the maddest at is yourself, because you feel you should have known and to be honest, you probably should have. But we all learn everyday...

[nwienert]

That's a mean thing to say, but shows you lack the ability to judge skill. I've been doing this for a long time at the highest level, and I love doing it so I take care.

Our websites both get very high performance scores and if you profile them neither of them does anything at idle. Tamagui site does a ton of fun animations to show off how well it works, it's possible if you're on Linux or Windows with certain drivers causing issues, mind telling me any of that info?

I'm an old school web developer, I've spent a lot of time on performance. I'm proud of the sites, they weren't easy to pull off. I checked in Chrome again just now and things feel very smooth, and I don't see memory runaway. Do you have any other extensions?

[seec]

No problem I was mean first. And you are right, I don't have enough competency to judge skill in this particular field.

However, I was just relating what was happening on my computer, my experience. Out of the 30 or so tabs that were open at this moment, your site was the only one to cause problem, so I don't think it has anything to do with the particularities of my install (I do have many extensions, they just don't cause trouble on any of the many sites I browse).

Right now, I can't reproduce the issue so I can't say more nor investigate a bit with the dev tools (not that I care enough to, sorry).

I will close by saying that I do not need to be a 3-star chef to judge the quality of an expensive multi-course meal. You may want to argue that it is not the same thing or attack me personally but realistically it is much better to realize that your standards may be different and that for some people, your stuff isn't up to snuff.

I don't think your stuff is exceptionally bad but it's a relatively simple page, that loads a gazillion js/css and uses more memory than a YouTube page with buffered/playing video with fully loaded comments and sidebar. You may very well have some specific benchmark that tells you that it's fast but if it feels slow in use that's clearly a problem. Maybe you are not focusing on the right thing.

I don't think your approach is very valuable for useful products but I guess that's just my opinion, good luck for the future regardless!

[nwienert]

I loaded tamagui.dev, onestack.dev and a random youtube video (not playing): in order, 107Mb, 48Mb, and 219Mb of memory. Lighthouse scores are good. Profiling shows near 0 main thread work at all while scrolling or doing common actions, no memory leaks I can see after moving around the pages. Loading many JS files is not bad so long as it doesn't waterfall, actually good practice to an extent, and we have no waterfalls and prefetch everything on hover.

I don't doubt you saw something, I'll keep an eye out for issues. I checked in Safari and it looks similarly fine there.

[mbforbes]

This comment single-handedly made me do an enthusiasm 180. I'd find it helpful if the developers responded to it.

Just to give a bit more meat to my comment: these experiences are really helpful when you're in the position to adopt a potential time-saving (stack-cutting/unifying) technology. I find I get a huge benefit from word-of-moth experiences from others who have tried such frameworks. Specifically compared to takes on the _idea_ of the technology.

[nwienert]

I responded in a sibling comment.

[nwienert]

Im sorry to hear that. Tamagui is one of the biggest projects you’ll find in terms of scope - it’s not one library, it’s over 200, and it’s targeting 4 platforms, 4 JS engines, and has a featureset that is unmatched.

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.

[nickreese]

Nate - We discussed the issues extensively on discord and you even did a video call with me and my team. The entire core theming structure changed multiple times and worked with Eshan (which you represented as being a great developer and contributor to Tamagui) to solve the issues… just to have them break again on a minor version for you to release takeout. Having donated over $1,000 to the project and spent a ton of time in the discord and messaged with you more than a handful of times I feel like this comment isn’t genuine but is to save face on HN.

[nwienert]

The theme API has not changed, we did refactor the logic behind it, and yes we've had regressions. It's a complex system. But we've always followed on with a fix, and we've added many, many tests in that area.

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.

[rlt]

> Tamagui is one of the biggest projects you’ll find in terms of scope - it’s not one library, it’s over 200, and it’s targeting 4 platforms, 4 JS engines, and has a featureset that is unmatched.

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.

[nwienert]

For the first part - what's the bug? It's certainly ambitious, and perhaps too much so, but I think we've managed to pull it off. To take more responsibility here - I think we should have waited longer to cut "1.0." One of the reasons we did was because we were already more feature-complete and generally stable than many competitors, but that's not a good enough reason.

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.

[account_created]

I am also an early adopter of Tamagui and can say that documentation has gone much better than it was before, but still needs lots of improvements. I myself struggle with many packages we have installed with Tamagui, and at this point I don't know which one to keep and which can be removed.

[nwienert]

We are working on documentation more actively than before. Please do reach out to me with any questions or feedback. Now that I'm full-time for the first time this is something I can actually focus on.

[account_created]

Thanks Nate! One immediate feedback I would like to give is to improve the configuration/setup documentation, like config/v1/v2/v3, packages like @tamagui/animations-react-native/babel-plugin/config/font-inter/react-native-media-driver etc. There is very less about these packages on the documentation or maybe not easily accessible.

[nwienert]

Thanks - noted to the team. We're moving a lot faster now that I'm full-time and I finally have two really great devs alongside. Look forward to improving this and having people say "actually it's really good now" in a few months time.