I used Tamagui to build a number of screens for a new product we're working on, and I saw 90+ lighthouse scores on every page. The fact that I can get that, with SSR support, inline styles, psuedo selectors, typed themes, <i>and</i> that it works on iOS and Android is novel.<p>I built the first library for React Native that supported Web/responsive design (Dripsy), so it's cool for me to see Tamagui taking this idea to the extreme.
Reading the docs, there seems to be a large amount of magical component creation going on that I find difficult to read. A key benefit of React is the simplicity of a component accepting props and using them in its render function. This library seems to dynamically create a component with a custom configuration language such that it requires a lot of thought to understand what is actually going on. It defines newly available props and their usage differently to other React components, reducing readability considerably.<p>Of course a person can get used to these things, but I question whether it scales to non-tiny teams. There’s a real smell of ye olde dynamic class creation here which React moved away from for very good reasons
This looks very interesting. I still question whether teams need this or React Native when they could just bring their existing React web app to mobile with Capacitor. The benefit to that approach is being able to use React web frameworks like Next or Tailwind, without having to use a system specifically designed for native mobile or React Native. Regardless, different solutions work for different teams and this looks like a very interesting project that I need to spend some time with.
2x performance in what benchmark?<p>React seems less than 2x slower than painfully optimized vanilla code in js-framework-benchmark, even considering the "swap rows" test, which is not that important but where React does terribly in. <a href="https://krausest.github.io/js-framework-benchmark/current.html" rel="nofollow">https://krausest.github.io/js-framework-benchmark/current.ht...</a>
Tamagui looks cool. I was evaluating it to see if I could use it in my projects. I got stuck on this bit of the documentation:<p>> Button only supports a limited subset of text props directly, and doesn't accept hoverStyle text props. If you need more control, you can do a simple customization using some exported helpers.<p>> Please note that this pattern is a bit antithetical to the multiple-components APIs that Tamagui generally prefers. In a future release we hope to fix this, but that change should be easy to migrate to.<p>I don't understand what any of that means, but it sounds like Tamagui doesn't support hover styles on Button components out of the box. That's a huge deal breaker for me. The docs give an example of what they mean by "simple customization", but the code is completely unintelligible to me, and far from simple.<p>I also haven't seen an example of Tamagui being able to render web and native React components from the same code. So it seems to me that either calling it "cross-platform" is a stretch, or the documentation is just very terrible.
I had given up on universal apps before finding tamagui. We’re rebuilding our app experience with this now and seeing the optimizing compiler work is beautiful. Native feels speedy, and the flattened classes it produces for web makes the experience feel first class. SSR friendly to boot.
As a former JS-head and newly-Flutter/Dart-head, this is certainly a step forward for JS frameworks.<p>However, one thing notably absent from the page and a quick Google search are layout animations. React-Native has this in the (poorly-supported and almost-niche) form of LayoutAnimation, however support is notably missing in React-Native-Web and other frameworks attempting to bring true cross-platform support.<p>As for me (not that anyone cares), this is a very cool advancement, but doesn't change many of the complaints against the current (and numerous) set of issues with JS, and will be sticking with Flutter.
So many things try to sell me on speed. That’s nice but the developer experience and debugging, examples and documentation is what sells me on a thing.
The highlight says it's < 17kB but bundlephobia says it's 30.1kB<p><pre><code> 92.5 kB Minified
30.1 kB Minified + Gzipped
</code></pre>
<a href="https://bundlephobia.com/package/@tamagui/core@1.0.1" rel="nofollow">https://bundlephobia.com/package/@tamagui/core@1.0.1</a><p>> Works completely at runtime, no compiler necessary.<p>So is the style part comptime or runtime? Because runtime is definitely undesirable.
Trying to wrap my head around this as a React Native developer, my biggest issue right now is that we developed mobile first and now need to create a web app.<p>Using react-native-web is not as straight forward as it first sounds, as there a lot of packages that don't support web and just crash when trying to run the RN app on web.<p>Would this solve that problem, to be able to easily move a React Native mobile app to web?
Looks interesting. It looks to be under MIT license (great) but the landing page doesn’t mention that. You might as well maximize the benefit of open-sourcing the code by claiming that on the landing page. (It’s true that most anyone actually interested will go look [as I did], so not that big a deal perhaps.)
First time hearing about Tamagui. I literally just set up a new project with Nativewind, but I might try writing a few components using Tamagui as well to compare the two.<p>Keen to hear from anyone else who's used both Tamagui and Nativewind as well.
Nice site, love the interactivity and color schemes. I'm going to add it to my list of nice dark mode sites: <a href="https://darkmodes.com" rel="nofollow">https://darkmodes.com</a>
This seems cool, but the performance is absolutely abysmal on the web, at least on my iPhone 13+.<p>There is significant latency when interacting with the components and animations seem to render at ~10fps.
Is size really that much of a problem with React?<p>With some chunk splitting and a good hosting, it has always seemed reasonable to me.<p>The main argument for me when choosing a front end framework is the availability of ready-made UI components, and React has always been ahead thanks to MUI.<p>I'm just an amateur/hobbyist at front end development though, curious what real front end developers care about most in a framework. Especially, isn't that a huge pain not to have access to all the wonderful MUI components when leaving react?
I’m not particularly interested in the cross-platform/React aspects of this (although they’re impressive too!). But I’m quite interested in the way it optimizes styles! I hacked something similar together with Fela and an early partial hydration solution, emphasis on <i>hacked</i>. And the DX of my solution is great… until there are a lot of styles, and then builds slow to a crawl. I’m looking forward to giving this a try, and digging into the source to see how it’s done.
Anyone here develop apps with something like capacitor? Their ionic appflow seems like a closed in ci/CD when we could do so in github. Any alternatives? Foss?
Sweet. Is there any recommended backend to complement a Tamagui powered application, that gets us closer to the comfort a Rails/Laravel app has to offer? Or does Tamagui mostly not care about backend integration, and never will? Offering a NextJS integration seems to hint there is at least
some interest in merging both parts.
When I look at this site, it's unobvious what my GUI is going to look like.<p>I don't see any screenshots, so I presume it's the entire site?
very interesting! if OP is here, there's a typo: <a href="https://tamagui.dev/blog/version-one#:~:text=.%20Core%20will-,alway,-merges%20styles%20based" rel="nofollow">https://tamagui.dev/blog/version-one#:~:text=.%20Core%20will...</a>
Tamagui seems to hype performance but it seems like it’s adds a lot of complexity to optimize web styles which are already very fast. The difference when talking about native (not react-native on web) is tiny IIRC
I played around with all the UI components and they’re pretty nice, my only issue is the slider is pretty unresponsive on iOS 16.1 Safari (iPhone 13 Pro).
I don't know how in the world anyone can claim "2x performance" when clicking on a navigation element, saying out loud "one Mississippi, two Mississippi" and then having the content show up counts as "performance"<p>Want to see something else neat? Open the dev-tools and just <i>wave your cursor</i> over the navigation elements and watch the browser spray GET requests to some json files. I guess they made it Cloudflare's problem, but ... I'm glad I didn't try to view this on mobile
I feel like, in the last few years, we're making huge progress towards being able to easily build performant, cross-platform UIs with great dev ergonomics and minimal code, yet we're not quite there yet, despite web development existing for decades.<p>Every time I try one of those new shiny things it always looks great at first, but then when "hello world" meets the real world you always hit some wall (be it routing, SSR, styling, state management, data fetching, performance, etc), beyond which things can get pretty messy. I've never seen a real UI codebase that actually looks good.<p>I wish we could finally get there. Maybe WASM will help shake things up a bit.
The site’s crashing on iOS Safari before loading finishes (client site exception), so I can’t see the contents. The library doesn’t look too good so far…
A little off-topic, but having used Raycast a little on a mac, I have to say that I wish there was react-native on Linux. It seems likes the react-native desktop project is maintained by microsoft, so there is no incentive for them to port this to linux, but what would it take to do that? Does anyone know? It seems to hinge on GTK and QT being hard to integrate with.