11 ms·

Tamagui 1.0 – Cross-platform React apps in less time, with better performance

373 points by redbar0n 4y ago

nsonha 4y ago
Is this the same as using react-native-web, which in turn was implemented with styled-components cross platform?
- redbar0n 4y ago
  You could think of it as using React Native Web (RNW), but better. Tamagui is using a trimmed down version of it called react-native-web-lite which is trimmed for bundle size and perfomance: https://www.npmjs.com/package/react-native-web-lite https://www.npmjs.com/package/react-native-web-lite RNW was independent of styled components, but you could use them together.
  - udfalkso 4y ago
    Can I use styled components with Tamagui?
    - nwienert 4y ago
      It’s more of a replacement for them, you could use them together during a transition to Tamagui though.
- fernandorojo 4y ago
  Somewhat, but it's better. It's like forking React Native Web and solving all of its styling shortcomings.
  - p2hari 4y ago
    Hey Fernando, thanks for all your work on dripsy, moti and solito. So nice to hear things from you about this library.
    - fernandorojo 4y ago
      Of course, happy it's helpful.
cyber_kinetist 4y ago
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…
- redbar0n 4y ago
  it works in iOS Safari here.
  - Firmwarrior 4y ago
    It worked for me too, I wonder if that guy has a content blocker at the router level or something Edit: Glad I'm not a web developer.. good luck dudes, haha. I'm running iOS 16.2 (20C65) FWIW
    - johnfn 4y ago
      I’m seeing this issue too. No content blocker.
      - nwienert 4y ago
        I can’t replicate, trying various devices in simulator and private tabs… I’ll keep checking
        fernandorojo 4y ago
        LambdaTest is helpful for these cases FWIW
- deleted 4y ago
  [deleted]
- poxrud 4y ago
  It’s crashing on Safari on my iPhone 13. “ Application error: a client-side exception has occurred (see the browser console for more information).”
fabiospampinato 4y ago
2x performance in what benchmark? 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. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- nwienert 4y ago
  It’s anywhere from 2-10x faster than a “universal” aka shared-code app that today would use React Native + React Native Web. It’s about 2x better render time over something like emotion or styled components as well when it does flattening, which is a good amount of the time, plus faster at startup etc. Basically it’s hard to be fully precise, but if anything 2x rounds down in the big picture.
  - fabiospampinato 4y ago
    I'd like to see how it performs in js-framework-benchmark. That it's faster than emotion or styled-components don't really mean anything when comparing the frameworks themselves, and much faster css-in-js solutions can be written for any framework basically.
    - nwienert 4y ago
      There’s benchmarks and code example both on this post and on the rest of the site showing this, the tree flattening is novel and what really makes a huge difference. On the site homepage it fully removes over 600 components from having to render at all. https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks
      - fabiospampinato 4y ago
        Thanks for the link, interesting. I'd still recommend making a submission for js-framework-benchmark, otherwise it's kinda like preact signals, where the performance aspect of them is kind of a marketing aspect really, and they don't actually improve the score much at all in js-framework-benchmark, hence, presumably, why they haven't submitted an implementation yet. The more data the fewer doubts.
15155 4y ago
When I look at this site, it's unobvious what my GUI is going to look like. I don't see any screenshots, so I presume it's the entire site?
- redbar0n 4y ago
  scroll down to see the components :) the entire site is also made with Tamagui, so the landing page uses a lot of it, and you can see visuals and code of all the components in the docs.
XiZhao 4y ago
This is the best made component library I’ve seen in a long time, very thoughtfully designed
scary-size 4y ago
What’s „native“ here? iOS and Android? Desktop?
- deleted 4y ago
  [deleted]
- system2 4y ago
  I think they mean React Native API. "<17kb, 0-dependency. Every React Native API, typed, without bloat on the web."
- redbar0n 4y ago
  React Native, so yes to all: iOS, Android, Windows, macOS, tvOS, Web etc.
mwood23 4y ago
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.
- jsherrard 4y ago
  Same here! Ridiculous amount of code-sharing possible now. As far as I know there's no alternative for cross-platform styling and SSR. Love the variants API and responsive styles for native too.
rjzzleep 4y ago
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.
- deleted 4y ago
  [deleted]
- lucideer 4y ago
  > port this to linux The problem with porting gui libs to Linux is - what is "Linux GUI"? Likely you would want to port it to either Qt or GTK; other routes might be a bigger lift. Fwiw, React Native for Windows targets WinUI & for macOS targets UIKit (though Microsoft's work here builds a lot on Facebook's work targeting iOS).
  - dylan604 4y ago
    >what is "Linux GUI"? ahem, CLI. anything else is just bumpers in the bowling alley gutters and training wheels on your bike. (I only partially jest)
    - lucideer 4y ago
      A TUI target for React-Native would be nice, but Ink gets pretty close (it builds on Facebook's Yoga lib to provide React terminal components - it's not a full "menu/window/view managing" type TUI lib but Yoga is the CSS Flexbox re-implementation behind React-Native, so building a layout is pretty straightforward).
  - aylmao 4y ago
    I personally don't think this is "the problem". Every platform has more than one UI library: on macOS you have AppKit, UIKit and SwiftUI. Windows seems like the worst offender with WinUI, WinForms, WPF, Blazor, .NET MAUI, etc [1]. I do think it's just a incentive issue. Supporting a platform on React Native takes plenty of effort, so without a big app as both the motivation and test-bed figuring this out there's little reason to invest in it. [1]: Not really a reference, but just a thread with people's thoughts on this whole mess: https://www.reddit.com/r/csharp/comments/vc3e2l/winui_3_or_wpf/ https://www.reddit.com/r/csharp/comments/vc3e2l/winui_3_or_w...
brap 4y ago
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. 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. I wish we could finally get there. Maybe WASM will help shake things up a bit.
- deleted 4y ago
  [deleted]
- moojd 4y ago
  This sums up my feelings about the js ecosystem entirely. Lots of growing pains. I've felt for a long time that every industry shift on the long road from simple server-side rendered monoliths to client-side heavy js SPAs we have taken a step forward in what is possible while taking multiple steps back in so many other dimensions (simplicity, security, dx, etc.) I think by the end we will be in a better place across all of these but it feels like we have been crawling out of a hole we dug ourselves to get there.
  - cutler 4y ago
    Sadly, I don't share your optimism. If the current state of JS isn't proof enough that it is doomed to be forever reinventing itself I don't know what is. Layer upon layer is a recipe for disaster which soon becomes apparent with these new toys once you require more than "Hello Word". I'd rather be saddled with Spring Boot than have to wade through the quagmire of current JS frameworks.
- jsherrard 4y ago
  It's very close. Some of us Tamagui-ers have Expo - Handles app routing of screens Next.js - Handles web routing of screens (SSR Works) React Query - Handles data fetching and hooks (Expo + Next) (Others are using TRPC with clients in Expo and Next) Zustand - Handles gllobal state (Expo + Next) Tamagui - Component libary (Expo + Next) Performance on the web with SSR rendering, React-Query pre-caching, and Next.js static builds is insanely good. You have to bring your data fetching, and state, but `create-tamagui-app` is pretty amazing if you get stuck into it for a couple of hours. I imagine in a few months there will be a monorepo starter with: Expo Next Prisma / Supabase auth and database Data fetching with TRPC Tamagui Design System Zustand client-state Someone's probably working on it right now
sokoloff 4y ago
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.)
dylan604 4y ago
[flagged]
yesimahuman 4y ago
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.
- fernandorojo 4y ago
  I wouldn't let its native support pigeonhole it as a React Native-only library. In my experience, it rivals other web-only libraries, especially with the compiler.
- nikodunk 4y ago
  Didn't know Capacitor! Very cool. This is still such a problem - as a small startup we still have two completely separate code bases that we need to maintain with a tiny team (though we share Redux and Tailwind thanks to https://www.npmjs.com/package/twrnc https://www.npmjs.com/package/twrnc). If we could "flutterize" our apps and make them run everywhere like this lib allows us to that'd save a huge amount of time. Wrote an essay about our current solution here: https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-efficiency https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-e...
  - 411111111111111 4y ago
    Ionic uses capacitor by default, you might know that one.
    - echelon 4y ago
      I've never done mobile, but I'm learning so much here. Thank you everyone! We need to launch a mobile app because someone started impersonating our web app and abusing our API. Their Google Play app has 100k+ installs, and it's rapidly growing. They're giving us a bad name too by injecting ads and degrading performance. We have a React/TypeScript app (in a monorepo if that matters) and need to launch something on Android to get rid of these copycats. Us: https://FakeYou.com https://FakeYou.com Not us: https://play.google.com/store/apps/details?id=com.headbreyz.hear.fakeyou https://play.google.com/store/apps/details?id=com.headbreyz.... (NB: I'd love to contract or hire someone to do this, in case anyone on HN is interested.)
fernandorojo 4y ago
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, and that it works on iOS and Android is novel. 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.
- nickreese 4y ago
  I feel like I missing where data fetching logic/state management fits. Those seem mostly non-reusable?
  - fernandorojo 4y ago
    What do you mean? Tamagui is only concerned with UI. Data and state management live in the react world using hooks.
    - nickreese 4y ago
      Haha. Pardon the naivety. Have lived in the Svelte world too long. Hooks had just come out last time I used react. I’ll get to reading.
      - fernandorojo 4y ago
        Ah, makes sense. Tamagui basically solves the part of styling + rendering UI. It works on both web and native. As for logic/data fetching...this has gotten far, far better in React over the past few years. For data fetching, assuming you're using REST, @tanstack/react-query is incredible. It gives you a "hook" to wrap any async function, and returns loading states, errors, etc. In the past, people used Redux, but it's out of fashion now. I prefer a library called zustand whenever I need non-data related global state management.
        jsherrard 4y ago
rmorey 4y ago
very interesting! if OP is here, there's a typo: https://tamagui.dev/blog/version-one#:~:text=.%20Core%20will-,alway,-merges%20styles%20based https://tamagui.dev/blog/version-one#:~:text=.%20Core%20will...
eyelidlessness 4y ago
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 hacked. 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.
- redbar0n 4y ago
  Then you’ll be happy to read this from Facebook’s lead engineer for their (unreleased) style library StyleX: https://twitter.com/naman34/status/1599581414487359489 https://twitter.com/naman34/status/1599581414487359489
mdaniel 4y ago
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" Want to see something else neat? Open the dev-tools and just wave your cursor 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
- nwienert 4y ago
  This is a demo blog post that loads every demo across the site, so it won’t be light. Making claims like this is like claiming SpaceX can’t go to space because their lobby isn’t aerodynamic. Also the prefetching is Next.js standard practice, not only does it have nothing to do with Tamagui but it’s is good for performance. The homepage gets excellent lighthouse scores despite being an order of magnitude more complex than your average app due to showing off every feature in the library.
  - mdaniel 4y ago
    It was my understanding that the site itself was written in the framework, so if I have that experience while reading the docs, it's not a great selling point, right? I can see we just have different expectations for a website, so I wish you all the best with your project
    - nwienert 4y ago
      There’s a difference between a blog post showing off every feature of something vs the thing itself in practice - but even then, I think you’re wrong. Even this super long blog post showing much more than your average app/site would is fast and has a >80 Lighthouse score. If you want to dispute the performance claims please do! But don’t spread FUD. You mis-construed prefetching for some sort of accidental performance mis-step when it’s the opposite and improves performance, without seeming to even realize what it is.
2Gkashmiri 4y ago
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?
- cfu28 4y ago
  Obsidian is an example of an app built with capacitor
shaneos 4y ago
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. 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
- nwienert 4y ago
  There’s nothing at all magical, I’m not sure what you’re thinking is exactly. That’s actually a huge benefit of Tamagui over something like Tailwind for example. You just pass in props and use props just like normal. If you’re talking about the styled() helper, that is something many React style libraries have standardized on from Emotion to Styled Components to Stitches. And actually it’s very important for an optimizing compiler because it limits you down to a statically analyzable subset that focuses just on styles. There’s no magic there either - React Native itself has a similar API with StyleSheet.create, except it won’t optimize even with a future compiler when you start nesting multiple things. That’s where styled() shines.
  - ricardobeat 4y ago
    It's always a surprise to see comment like yours - it's obvious that there is a huge gap in how each developer circle sees complexity. In the examples, you need to use the provided Stack component, special props like $gtSm, theme values like $2, the styled() function, variants, and then stuff like useMediaPropsActive() if you want to build your own components. That's plenty of magic. The exact same conversations were had when JSX came along, react-native-web, etc. We just keep on piling up more and more abstractions.
    - djur 4y ago
satvikpendem 4y ago
Nice site, love the interactivity and color schemes. I'm going to add it to my list of nice dark mode sites: https://darkmodes.com https://darkmodes.com
- fernandorojo 4y ago
  That's a cool site. I like the use of iframes.
  - satvikpendem 4y ago
    Hah, I might change it soon to images or videos of the site. iframes are taking up way too much of my bandwidth limit.
    - MaxLeiter 4y ago
      Cache the webpages daily and serve them locally?
      - satvikpendem 4y ago
        I already cache them but the pages themselves are huge due to JS tracking and such.
TobyTheDog123 4y ago
As a former JS-head and newly-Flutter/Dart-head, this is certainly a step forward for JS frameworks. 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. 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.
cutler 4y ago
And there I was all set to get started with Solito.
- jsherrard 4y ago
  The Tamagui starter uses Solito, and Fernando (of Solito and Dripsy fame) is using Tamagui.
- skyriverbend 4y ago
  No worries! `npm create tamagui` gives you a Solito app with Tamagui as the UI: https://github.com/tamagui/tamagui/tree/master/starters/next-expo-solito https://github.com/tamagui/tamagui/tree/master/starters/next...
  - jstummbillig 4y ago
    I feel this is mostly a good display of the confusion around what the heck is even doing what at this point. You can count me in this camp. And I am terribly interested to know.
ecuaflo 4y ago
I get “ Application error: a client-side exception has occurred (see the browser console for more information).” when viewing the site on iOS Chrome..
- nwienert 4y ago
  Weird I get some reports of this but very rare. I’ve tested now in iOS 15, 16 and desktop across a bunch of devices. Can’t replicate with me or close friends. I’ll download chrome for iOS.
duxup 4y ago
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.
- nwienert 4y ago
  It has a ton of DX features that I think are underrated: both the debug prop and pragma, and compile time data-attributes to help link your files to DOM.
teg4n_ 4y ago
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
- redbar0n 4y ago
  The great thing about it is that it basically gives you the benefits of CSS-in-JS on the web, but without the downsides, since it compiles away to atomic CSS (even ternaries!). It’s true that it’s marginally less performant than vanilla React Native (within 10%, looks like 1.9%): https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks But that is actually no small feat for a native component library, see f.ex. Nativebase’s longstanding unresolved performance issues: https://github.com/GeekyAnts/NativeBase/issues/4302 https://github.com/GeekyAnts/NativeBase/issues/4302 And for that tiny difference on native, you in return get close to 100% code sharing between native and web. As opposed to writing vanilla React Native and then writing it again for vanilla React.
  - teg4n_ 4y ago
    you get very similar code sharing with react-native-web and StyleSheet.create… I guess i am just much more interested in making the native side faster. I have never had issues making something in React Native and then having the web side be the slow part.
    - nwienert 4y ago
      Web is the much more performance sensitive side, where it improves most. If you do pseudo styles or responsive styles with RNW your web app will absolutely tank in all metrics, runtime/lighthouse/load/layout. Tamagui fixes all four. That normally prevents code share for anything more than small apps or totally performance insensitive use cases, otherwise Tamagui makes a big difference.
cusx 4y ago
Hmm, based on the docs I still don't know if I can use this for the web only, and if I could, what is the bundle size of this package?
- redbar0n 4y ago
  You can. It says 20 kB gzipped in the blog post, with path to be reduced to under 10 kB in later versions.
Existenceblinks 4y ago
The highlight says it's < 17kB but bundlephobia says it's 30.1kB 92.5 kB Minified 30.1 kB Minified + Gzipped https://bundlephobia.com/package/@tamagui/core@1.0.1 https://bundlephobia.com/package/@tamagui/core@1.0.1 > Works completely at runtime, no compiler necessary. So is the style part comptime or runtime? Because runtime is definitely undesirable.
- nwienert 4y ago
  Styles extracted at build time, but fall back to runtime. This is necessary for many things, animations being one, but in the future there’s a potential for compiling fully way for limited use cases. I’ll check the bundle size, I think two things happening there but not at my laptop to check.
Galanwe 4y ago
Is size really that much of a problem with React? With some chunk splitting and a good hosting, it has always seemed reasonable to me. 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. 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?
- redbar0n 4y ago
  Bundle size? Yes, esp with third party code. See https://qwik.builder.io https://qwik.builder.io for arguments why. On the value of MUI and what senior front end devs care about, you’d find this interesting (esp the linked youtube of Theo): https://twitter.com/magnemg/status/1608634824591544320 https://twitter.com/magnemg/status/1608634824591544320
charrondev 4y ago
This seems cool, but the performance is absolutely abysmal on the web, at least on my iPhone 13+. There is significant latency when interacting with the components and animations seem to render at ~10fps.
- nwienert 4y ago
  Which ones? Feel free to reach out privately.
kritr 4y ago
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).
- redbar0n 4y ago
  Same here. It seems to get slightly better in light mode (at least the horizontal one), so it’s probably related to style calculations under various themes. Luckily I’m confident it will be fixed pretty rapidly, judging by the steady release cycles and impressively pace of improvements by the author.
yosito 4y ago
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: > 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. > 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. 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. 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.
- nwienert 4y ago
  It’s a good point that the docs can be clearer here, but all your conclusions are off - all styles work on buttons and everything renders native and web the same, it says that all over the place.
shadyr 4y ago
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. Keen to hear from anyone else who's used both Tamagui and Nativewind as well.
Svarto 4y ago
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. 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. Would this solve that problem, to be able to easily move a React Native mobile app to web?
- redbar0n 4y ago
  Not really, unless you redesign your app using Tamagui. Your best bet is using React Native Web and removing dependency on the packages that don’t support web: remove/treeshake them, shim them (like RNW does with RN), or detect the platform using a conditional and then exclude the troublesome package/component in favor of a web compatible one. Alternatively: Keep the web app separate from the native one, and simply share logic and some shared components (RNW) in a monorepo. Could be the easiest path forward, but will give some duplication of code. My two cents, FWIW. Someone who has done the transition themselves, or has more insight to your particular case could probably offer even better advice.
  - Svarto 4y ago
    Thanks a lot, super helpful to hear the ways to remove/treeshake, shim or conditional to handle mobile Vs web. This was something I struggled to find explained how to do properly, except create files with different extensions - but that felt a bit like using a sledgehammer when a smaller hammer would suffice (in some cases)
- gorbypark 4y ago
  It probably won’t help with native dependencies on the web. I’ve done a few projects that were android/iOS and then later on we added react-native-web support. The best way is to go through your package.json dependencies one by one, figure out which support web and which don’t, then go into your project and make an empty component (eg: file.web.js) for any component that doesn’t work on the web. Once you have your app up and running on the web (even with a ton of “blank” web components), start the work of finding web equivalents for the missing functionality. Be diligent that the props for the native component and web component are the same or at least compatible, so that the component calling the now web compatible component needs no changes. In my experience it’s super important to keep “platform specific” code isolated into its own component. General layout and the skeleton of your app should remain cross platform. In-line use of Platform.OS should be kept to a minimum.
jstummbillig 4y ago
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.
- redbar0n 4y ago
  Tamagui is always fully agnostic to backend choice, since it is specifically for UI styling/animation. Remix.run and RedwoodJS are two fullstack React frameworks that comes from old RoR folks who aim to recreate the Rails/Laravel experience for JS/TS. Remix is SSR and progressive enhancement / web standards focused, and RedwoodJS is CSR and GraphQL focused and brings a larger and more opinionated suite of tools (testing etc.). Coming from Rails myself, RedwoodJS gave me the most Rails-like feel, but YMMV. NextJS is the market leader for a fullstack React framework, ofc (and Solito.dev that bridges NextJS and Expo works well with Tamagui). But if you want more freedom, and a Vite based setup with ‘blazingly fast’ DX, then try vite-plugin-ssr.com BlitzJS is «the missing fullstack toolkit for NextJS» also made by a RoR guy trying to make NextJS come closer to the Rails DX we knew and loved. For data loading in particular, that works crossplatform, with both NextJS and React Native, I recommend: tRPC, as a favored choice amongst many, to call backend functions directly from the frontend (it uses React Query under the hood to handle caching, retries etc.), and gives the mich loved full stack TypeScript type inference. If you decide you need GraphQL - like if you need to expose your API to third parties, or have strict frontend/backend team separation - then I recommend: GQty.dev on the client, for inferred queries/mutations. Rapid dev speed. Move to URQL or Relay at scale. pothos-graphql.dev on the server, for auto building the schema from your TS code (aka. code-first). Better than Nexus. That will give you fullstack type inference with GraphQL like with tRPC, and either will give your the fastest dev speed, closest possible to Rails. That’s the gist of it. Hope it helps!
  - nickreese 4y ago
    Thank you so much for pulling all of this together in a single place.

373 points by redbar0n 4y ago

nsonha 4y ago

Is this the same as using react-native-web, which in turn was implemented with styled-components cross platform?

redbar0n 4y ago
You could think of it as using React Native Web (RNW), but better. Tamagui is using a trimmed down version of it called react-native-web-lite which is trimmed for bundle size and perfomance: https://www.npmjs.com/package/react-native-web-lite https://www.npmjs.com/package/react-native-web-lite RNW was independent of styled components, but you could use them together.
- udfalkso 4y ago
  Can I use styled components with Tamagui?
  - nwienert 4y ago
    It’s more of a replacement for them, you could use them together during a transition to Tamagui though.
fernandorojo 4y ago
Somewhat, but it's better. It's like forking React Native Web and solving all of its styling shortcomings.
- p2hari 4y ago
  Hey Fernando, thanks for all your work on dripsy, moti and solito. So nice to hear things from you about this library.
  - fernandorojo 4y ago
    Of course, happy it's helpful.

cyber_kinetist 4y ago

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…

redbar0n 4y ago
it works in iOS Safari here.
- Firmwarrior 4y ago
  It worked for me too, I wonder if that guy has a content blocker at the router level or something Edit: Glad I'm not a web developer.. good luck dudes, haha. I'm running iOS 16.2 (20C65) FWIW
  - johnfn 4y ago
    I’m seeing this issue too. No content blocker.
    - nwienert 4y ago
      I can’t replicate, trying various devices in simulator and private tabs… I’ll keep checking
      - fernandorojo 4y ago
        LambdaTest is helpful for these cases FWIW
deleted 4y ago
[deleted]
poxrud 4y ago
It’s crashing on Safari on my iPhone 13. “ Application error: a client-side exception has occurred (see the browser console for more information).”

fabiospampinato 4y ago

2x performance in what benchmark? 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. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...

nwienert 4y ago
It’s anywhere from 2-10x faster than a “universal” aka shared-code app that today would use React Native + React Native Web. It’s about 2x better render time over something like emotion or styled components as well when it does flattening, which is a good amount of the time, plus faster at startup etc. Basically it’s hard to be fully precise, but if anything 2x rounds down in the big picture.
- fabiospampinato 4y ago
  I'd like to see how it performs in js-framework-benchmark. That it's faster than emotion or styled-components don't really mean anything when comparing the frameworks themselves, and much faster css-in-js solutions can be written for any framework basically.
  - nwienert 4y ago
    There’s benchmarks and code example both on this post and on the rest of the site showing this, the tree flattening is novel and what really makes a huge difference. On the site homepage it fully removes over 600 components from having to render at all. https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks
    - fabiospampinato 4y ago
      Thanks for the link, interesting. I'd still recommend making a submission for js-framework-benchmark, otherwise it's kinda like preact signals, where the performance aspect of them is kind of a marketing aspect really, and they don't actually improve the score much at all in js-framework-benchmark, hence, presumably, why they haven't submitted an implementation yet. The more data the fewer doubts.

15155 4y ago

When I look at this site, it's unobvious what my GUI is going to look like. I don't see any screenshots, so I presume it's the entire site?

redbar0n 4y ago
scroll down to see the components :) the entire site is also made with Tamagui, so the landing page uses a lot of it, and you can see visuals and code of all the components in the docs.

XiZhao 4y ago

This is the best made component library I’ve seen in a long time, very thoughtfully designed

scary-size 4y ago

What’s „native“ here? iOS and Android? Desktop?

deleted 4y ago
[deleted]
system2 4y ago
I think they mean React Native API. "<17kb, 0-dependency. Every React Native API, typed, without bloat on the web."
redbar0n 4y ago
React Native, so yes to all: iOS, Android, Windows, macOS, tvOS, Web etc.

mwood23 4y ago

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.

jsherrard 4y ago
Same here! Ridiculous amount of code-sharing possible now. As far as I know there's no alternative for cross-platform styling and SSR. Love the variants API and responsive styles for native too.

rjzzleep 4y ago

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.

deleted 4y ago
[deleted]
lucideer 4y ago
> port this to linux The problem with porting gui libs to Linux is - what is "Linux GUI"? Likely you would want to port it to either Qt or GTK; other routes might be a bigger lift. Fwiw, React Native for Windows targets WinUI & for macOS targets UIKit (though Microsoft's work here builds a lot on Facebook's work targeting iOS).
- dylan604 4y ago
  >what is "Linux GUI"? ahem, CLI. anything else is just bumpers in the bowling alley gutters and training wheels on your bike. (I only partially jest)
  - lucideer 4y ago
    A TUI target for React-Native would be nice, but Ink gets pretty close (it builds on Facebook's Yoga lib to provide React terminal components - it's not a full "menu/window/view managing" type TUI lib but Yoga is the CSS Flexbox re-implementation behind React-Native, so building a layout is pretty straightforward).
- aylmao 4y ago
  I personally don't think this is "the problem". Every platform has more than one UI library: on macOS you have AppKit, UIKit and SwiftUI. Windows seems like the worst offender with WinUI, WinForms, WPF, Blazor, .NET MAUI, etc [1]. I do think it's just a incentive issue. Supporting a platform on React Native takes plenty of effort, so without a big app as both the motivation and test-bed figuring this out there's little reason to invest in it. [1]: Not really a reference, but just a thread with people's thoughts on this whole mess: https://www.reddit.com/r/csharp/comments/vc3e2l/winui_3_or_wpf/ https://www.reddit.com/r/csharp/comments/vc3e2l/winui_3_or_w...

brap 4y ago

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. 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. I wish we could finally get there. Maybe WASM will help shake things up a bit.

deleted 4y ago
[deleted]
moojd 4y ago
This sums up my feelings about the js ecosystem entirely. Lots of growing pains. I've felt for a long time that every industry shift on the long road from simple server-side rendered monoliths to client-side heavy js SPAs we have taken a step forward in what is possible while taking multiple steps back in so many other dimensions (simplicity, security, dx, etc.) I think by the end we will be in a better place across all of these but it feels like we have been crawling out of a hole we dug ourselves to get there.
- cutler 4y ago
  Sadly, I don't share your optimism. If the current state of JS isn't proof enough that it is doomed to be forever reinventing itself I don't know what is. Layer upon layer is a recipe for disaster which soon becomes apparent with these new toys once you require more than "Hello Word". I'd rather be saddled with Spring Boot than have to wade through the quagmire of current JS frameworks.
jsherrard 4y ago
It's very close. Some of us Tamagui-ers have Expo - Handles app routing of screens Next.js - Handles web routing of screens (SSR Works) React Query - Handles data fetching and hooks (Expo + Next) (Others are using TRPC with clients in Expo and Next) Zustand - Handles gllobal state (Expo + Next) Tamagui - Component libary (Expo + Next) Performance on the web with SSR rendering, React-Query pre-caching, and Next.js static builds is insanely good. You have to bring your data fetching, and state, but `create-tamagui-app` is pretty amazing if you get stuck into it for a couple of hours. I imagine in a few months there will be a monorepo starter with: Expo Next Prisma / Supabase auth and database Data fetching with TRPC Tamagui Design System Zustand client-state Someone's probably working on it right now

sokoloff 4y ago

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.)

dylan604 4y ago

[flagged]

yesimahuman 4y ago

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.

fernandorojo 4y ago
I wouldn't let its native support pigeonhole it as a React Native-only library. In my experience, it rivals other web-only libraries, especially with the compiler.
nikodunk 4y ago
Didn't know Capacitor! Very cool. This is still such a problem - as a small startup we still have two completely separate code bases that we need to maintain with a tiny team (though we share Redux and Tailwind thanks to https://www.npmjs.com/package/twrnc https://www.npmjs.com/package/twrnc). If we could "flutterize" our apps and make them run everywhere like this lib allows us to that'd save a huge amount of time. Wrote an essay about our current solution here: https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-efficiency https://nikodunk.com/2022-05-10-the-tech-stack-for-maximum-e...
- 411111111111111 4y ago
  Ionic uses capacitor by default, you might know that one.
  - echelon 4y ago
    I've never done mobile, but I'm learning so much here. Thank you everyone! We need to launch a mobile app because someone started impersonating our web app and abusing our API. Their Google Play app has 100k+ installs, and it's rapidly growing. They're giving us a bad name too by injecting ads and degrading performance. We have a React/TypeScript app (in a monorepo if that matters) and need to launch something on Android to get rid of these copycats. Us: https://FakeYou.com https://FakeYou.com Not us: https://play.google.com/store/apps/details?id=com.headbreyz.hear.fakeyou https://play.google.com/store/apps/details?id=com.headbreyz.... (NB: I'd love to contract or hire someone to do this, in case anyone on HN is interested.)

fernandorojo 4y ago

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, and that it works on iOS and Android is novel. 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.

nickreese 4y ago
I feel like I missing where data fetching logic/state management fits. Those seem mostly non-reusable?
- fernandorojo 4y ago
  What do you mean? Tamagui is only concerned with UI. Data and state management live in the react world using hooks.
  - nickreese 4y ago
    Haha. Pardon the naivety. Have lived in the Svelte world too long. Hooks had just come out last time I used react. I’ll get to reading.
    - fernandorojo 4y ago
      Ah, makes sense. Tamagui basically solves the part of styling + rendering UI. It works on both web and native. As for logic/data fetching...this has gotten far, far better in React over the past few years. For data fetching, assuming you're using REST, @tanstack/react-query is incredible. It gives you a "hook" to wrap any async function, and returns loading states, errors, etc. In the past, people used Redux, but it's out of fashion now. I prefer a library called zustand whenever I need non-data related global state management.
      - jsherrard 4y ago

rmorey 4y ago

very interesting! if OP is here, there's a typo: https://tamagui.dev/blog/version-one#:~:text=.%20Core%20will-,alway,-merges%20styles%20based https://tamagui.dev/blog/version-one#:~:text=.%20Core%20will...

eyelidlessness 4y ago

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 hacked. 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.

redbar0n 4y ago
Then you’ll be happy to read this from Facebook’s lead engineer for their (unreleased) style library StyleX: https://twitter.com/naman34/status/1599581414487359489 https://twitter.com/naman34/status/1599581414487359489

mdaniel 4y ago

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" Want to see something else neat? Open the dev-tools and just wave your cursor 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

nwienert 4y ago
This is a demo blog post that loads every demo across the site, so it won’t be light. Making claims like this is like claiming SpaceX can’t go to space because their lobby isn’t aerodynamic. Also the prefetching is Next.js standard practice, not only does it have nothing to do with Tamagui but it’s is good for performance. The homepage gets excellent lighthouse scores despite being an order of magnitude more complex than your average app due to showing off every feature in the library.
- mdaniel 4y ago
  It was my understanding that the site itself was written in the framework, so if I have that experience while reading the docs, it's not a great selling point, right? I can see we just have different expectations for a website, so I wish you all the best with your project
  - nwienert 4y ago
    There’s a difference between a blog post showing off every feature of something vs the thing itself in practice - but even then, I think you’re wrong. Even this super long blog post showing much more than your average app/site would is fast and has a >80 Lighthouse score. If you want to dispute the performance claims please do! But don’t spread FUD. You mis-construed prefetching for some sort of accidental performance mis-step when it’s the opposite and improves performance, without seeming to even realize what it is.

2Gkashmiri 4y ago

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?

cfu28 4y ago
Obsidian is an example of an app built with capacitor

shaneos 4y ago

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. 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

nwienert 4y ago
There’s nothing at all magical, I’m not sure what you’re thinking is exactly. That’s actually a huge benefit of Tamagui over something like Tailwind for example. You just pass in props and use props just like normal. If you’re talking about the styled() helper, that is something many React style libraries have standardized on from Emotion to Styled Components to Stitches. And actually it’s very important for an optimizing compiler because it limits you down to a statically analyzable subset that focuses just on styles. There’s no magic there either - React Native itself has a similar API with StyleSheet.create, except it won’t optimize even with a future compiler when you start nesting multiple things. That’s where styled() shines.
- ricardobeat 4y ago
  It's always a surprise to see comment like yours - it's obvious that there is a huge gap in how each developer circle sees complexity. In the examples, you need to use the provided Stack component, special props like $gtSm, theme values like $2, the styled() function, variants, and then stuff like useMediaPropsActive() if you want to build your own components. That's plenty of magic. The exact same conversations were had when JSX came along, react-native-web, etc. We just keep on piling up more and more abstractions.
  - djur 4y ago

satvikpendem 4y ago

Nice site, love the interactivity and color schemes. I'm going to add it to my list of nice dark mode sites: https://darkmodes.com https://darkmodes.com

fernandorojo 4y ago
That's a cool site. I like the use of iframes.
- satvikpendem 4y ago
  Hah, I might change it soon to images or videos of the site. iframes are taking up way too much of my bandwidth limit.
  - MaxLeiter 4y ago
    Cache the webpages daily and serve them locally?
    - satvikpendem 4y ago
      I already cache them but the pages themselves are huge due to JS tracking and such.

TobyTheDog123 4y ago

As a former JS-head and newly-Flutter/Dart-head, this is certainly a step forward for JS frameworks. 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. 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.

cutler 4y ago

And there I was all set to get started with Solito.

jsherrard 4y ago
The Tamagui starter uses Solito, and Fernando (of Solito and Dripsy fame) is using Tamagui.
skyriverbend 4y ago
No worries! `npm create tamagui` gives you a Solito app with Tamagui as the UI: https://github.com/tamagui/tamagui/tree/master/starters/next-expo-solito https://github.com/tamagui/tamagui/tree/master/starters/next...
- jstummbillig 4y ago
  I feel this is mostly a good display of the confusion around what the heck is even doing what at this point. You can count me in this camp. And I am terribly interested to know.

ecuaflo 4y ago

I get “ Application error: a client-side exception has occurred (see the browser console for more information).” when viewing the site on iOS Chrome..

nwienert 4y ago
Weird I get some reports of this but very rare. I’ve tested now in iOS 15, 16 and desktop across a bunch of devices. Can’t replicate with me or close friends. I’ll download chrome for iOS.

duxup 4y ago

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.

nwienert 4y ago
It has a ton of DX features that I think are underrated: both the debug prop and pragma, and compile time data-attributes to help link your files to DOM.

teg4n_ 4y ago

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

redbar0n 4y ago
The great thing about it is that it basically gives you the benefits of CSS-in-JS on the web, but without the downsides, since it compiles away to atomic CSS (even ternaries!). It’s true that it’s marginally less performant than vanilla React Native (within 10%, looks like 1.9%): https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks But that is actually no small feat for a native component library, see f.ex. Nativebase’s longstanding unresolved performance issues: https://github.com/GeekyAnts/NativeBase/issues/4302 https://github.com/GeekyAnts/NativeBase/issues/4302 And for that tiny difference on native, you in return get close to 100% code sharing between native and web. As opposed to writing vanilla React Native and then writing it again for vanilla React.
- teg4n_ 4y ago
  you get very similar code sharing with react-native-web and StyleSheet.create… I guess i am just much more interested in making the native side faster. I have never had issues making something in React Native and then having the web side be the slow part.
  - nwienert 4y ago
    Web is the much more performance sensitive side, where it improves most. If you do pseudo styles or responsive styles with RNW your web app will absolutely tank in all metrics, runtime/lighthouse/load/layout. Tamagui fixes all four. That normally prevents code share for anything more than small apps or totally performance insensitive use cases, otherwise Tamagui makes a big difference.

cusx 4y ago

Hmm, based on the docs I still don't know if I can use this for the web only, and if I could, what is the bundle size of this package?

redbar0n 4y ago
You can. It says 20 kB gzipped in the blog post, with path to be reduced to under 10 kB in later versions.

Existenceblinks 4y ago

The highlight says it's < 17kB but bundlephobia says it's 30.1kB 92.5 kB Minified 30.1 kB Minified + Gzipped https://bundlephobia.com/package/@tamagui/core@1.0.1 https://bundlephobia.com/package/@tamagui/core@1.0.1 > Works completely at runtime, no compiler necessary. So is the style part comptime or runtime? Because runtime is definitely undesirable.

nwienert 4y ago
Styles extracted at build time, but fall back to runtime. This is necessary for many things, animations being one, but in the future there’s a potential for compiling fully way for limited use cases. I’ll check the bundle size, I think two things happening there but not at my laptop to check.

Galanwe 4y ago

Is size really that much of a problem with React? With some chunk splitting and a good hosting, it has always seemed reasonable to me. 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. 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?

redbar0n 4y ago
Bundle size? Yes, esp with third party code. See https://qwik.builder.io https://qwik.builder.io for arguments why. On the value of MUI and what senior front end devs care about, you’d find this interesting (esp the linked youtube of Theo): https://twitter.com/magnemg/status/1608634824591544320 https://twitter.com/magnemg/status/1608634824591544320

charrondev 4y ago

This seems cool, but the performance is absolutely abysmal on the web, at least on my iPhone 13+. There is significant latency when interacting with the components and animations seem to render at ~10fps.

nwienert 4y ago
Which ones? Feel free to reach out privately.

kritr 4y ago

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).

redbar0n 4y ago
Same here. It seems to get slightly better in light mode (at least the horizontal one), so it’s probably related to style calculations under various themes. Luckily I’m confident it will be fixed pretty rapidly, judging by the steady release cycles and impressively pace of improvements by the author.

yosito 4y ago

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: > 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. > 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. 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. 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.

nwienert 4y ago
It’s a good point that the docs can be clearer here, but all your conclusions are off - all styles work on buttons and everything renders native and web the same, it says that all over the place.

shadyr 4y ago

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. Keen to hear from anyone else who's used both Tamagui and Nativewind as well.

Svarto 4y ago

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. 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. Would this solve that problem, to be able to easily move a React Native mobile app to web?

redbar0n 4y ago
Not really, unless you redesign your app using Tamagui. Your best bet is using React Native Web and removing dependency on the packages that don’t support web: remove/treeshake them, shim them (like RNW does with RN), or detect the platform using a conditional and then exclude the troublesome package/component in favor of a web compatible one. Alternatively: Keep the web app separate from the native one, and simply share logic and some shared components (RNW) in a monorepo. Could be the easiest path forward, but will give some duplication of code. My two cents, FWIW. Someone who has done the transition themselves, or has more insight to your particular case could probably offer even better advice.
- Svarto 4y ago
  Thanks a lot, super helpful to hear the ways to remove/treeshake, shim or conditional to handle mobile Vs web. This was something I struggled to find explained how to do properly, except create files with different extensions - but that felt a bit like using a sledgehammer when a smaller hammer would suffice (in some cases)
gorbypark 4y ago
It probably won’t help with native dependencies on the web. I’ve done a few projects that were android/iOS and then later on we added react-native-web support. The best way is to go through your package.json dependencies one by one, figure out which support web and which don’t, then go into your project and make an empty component (eg: file.web.js) for any component that doesn’t work on the web. Once you have your app up and running on the web (even with a ton of “blank” web components), start the work of finding web equivalents for the missing functionality. Be diligent that the props for the native component and web component are the same or at least compatible, so that the component calling the now web compatible component needs no changes. In my experience it’s super important to keep “platform specific” code isolated into its own component. General layout and the skeleton of your app should remain cross platform. In-line use of Platform.OS should be kept to a minimum.

jstummbillig 4y ago

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.

redbar0n 4y ago
Tamagui is always fully agnostic to backend choice, since it is specifically for UI styling/animation. Remix.run and RedwoodJS are two fullstack React frameworks that comes from old RoR folks who aim to recreate the Rails/Laravel experience for JS/TS. Remix is SSR and progressive enhancement / web standards focused, and RedwoodJS is CSR and GraphQL focused and brings a larger and more opinionated suite of tools (testing etc.). Coming from Rails myself, RedwoodJS gave me the most Rails-like feel, but YMMV. NextJS is the market leader for a fullstack React framework, ofc (and Solito.dev that bridges NextJS and Expo works well with Tamagui). But if you want more freedom, and a Vite based setup with ‘blazingly fast’ DX, then try vite-plugin-ssr.com BlitzJS is «the missing fullstack toolkit for NextJS» also made by a RoR guy trying to make NextJS come closer to the Rails DX we knew and loved. For data loading in particular, that works crossplatform, with both NextJS and React Native, I recommend: tRPC, as a favored choice amongst many, to call backend functions directly from the frontend (it uses React Query under the hood to handle caching, retries etc.), and gives the mich loved full stack TypeScript type inference. If you decide you need GraphQL - like if you need to expose your API to third parties, or have strict frontend/backend team separation - then I recommend: GQty.dev on the client, for inferred queries/mutations. Rapid dev speed. Move to URQL or Relay at scale. pothos-graphql.dev on the server, for auto building the schema from your TS code (aka. code-first). Better than Nexus. That will give you fullstack type inference with GraphQL like with tRPC, and either will give your the fastest dev speed, closest possible to Rails. That’s the gist of it. Hope it helps!
- nickreese 4y ago
  Thank you so much for pulling all of this together in a single place.