[HN Gopher] Tamagui 1.0 - Cross-platform React apps in less time...
___________________________________________________________________
Tamagui 1.0 - Cross-platform React apps in less time, with better
performance
Author : redbar0n
Score : 211 points
Date : 2022-12-30 16:45 UTC (6 hours ago)
(HTM) web link (tamagui.dev)
(TXT) w3m dump (tamagui.dev)
| XiZhao wrote:
| This is the best made component library I've seen in a long time,
| very thoughtfully designed
| TobyTheDog123 wrote:
| 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.
| ecuaflo wrote:
| I get " Application error: a client-side exception has occurred
| (see the browser console for more information)." when viewing the
| site on iOS Chrome..
| shaneos wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| What is "magic" about any of those? React components are
| functions, so `styled` would be a function that returns a
| function. The "special props" are just arguments to those
| functions. If these are all documented, where's the magic?
| yesimahuman wrote:
| 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.
| nikodunk wrote:
| 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). 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-e...
| 411111111111111 wrote:
| Ionic uses capacitor by default, you might know that one.
| fernandorojo wrote:
| 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.
| rjzzleep wrote:
| 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]
| lucideer wrote:
| > _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 wrote:
| >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 wrote:
| 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).
| waboremo wrote:
| They have the same incentive as with supporting mac with react-
| native-macos, more platforms to push their services onto. The
| limitation seems to be technical, as other react-native on QT
| projects seem to have been all abandoned (Valence Native being
| the big one mentioned on react-native docs).
| fernandorojo wrote:
| 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 wrote:
| I feel like I missing where data fetching logic/state
| management fits.
|
| Those seem mostly non-reusable?
| fernandorojo wrote:
| What do you mean? Tamagui is only concerned with UI. Data and
| state management live in the react world using hooks.
| nickreese wrote:
| 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 wrote:
| 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.
| eyelidlessness wrote:
| 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.
| rmorey wrote:
| very interesting! if OP is here, there's a typo:
| https://tamagui.dev/blog/version-one#:~:text=.%20Core%20will...
| cutler wrote:
| And there I was all set to get started with Solito.
| sokoloff wrote:
| 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.)
| scary-size wrote:
| What's ,,native" here? iOS and Android? Desktop?
| [deleted]
| system2 wrote:
| I think they mean React Native API.
|
| "<17kb, 0-dependency. Every React Native API, typed, without
| bloat on the web."
| redbar0n wrote:
| React Native, so yes to all: iOS, Android, Windows, macOS,
| tvOS, Web etc.
| satvikpendem wrote:
| 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
| fernandorojo wrote:
| That's a cool site. I like the use of iframes.
| satvikpendem wrote:
| Hah, I might change it soon to images or videos of the site.
| iframes are taking up way too much of my bandwidth limit.
| mdaniel wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nsonha wrote:
| Is this the same as using react-native-web, which in turn was
| implemented with styled-components cross platform?
| redbar0n wrote:
| 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
|
| RNW was independent of styled components, but you could use
| them together.
| udfalkso wrote:
| Can I use styled components with Tamagui?
| nwienert wrote:
| It's more of a replacement for them, you could use them
| together during a transition to Tamagui though.
| fernandorojo wrote:
| Somewhat, but it's better. It's like forking React Native Web
| and solving all of its styling shortcomings.
| p2hari wrote:
| Hey Fernando, thanks for all your work on dripsy, moti and
| solito. So nice to hear things from you about this library.
| fernandorojo wrote:
| Of course, happy it's helpful.
| brap wrote:
| 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.
| moojd wrote:
| 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.
| [deleted]
| 2Gkashmiri wrote:
| 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 wrote:
| Obsidian is an example of an app built with capacitor
| mwood23 wrote:
| 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 wrote:
| 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.
| cyber_kinetist wrote:
| 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 wrote:
| it works in iOS Safari here.
| Firmwarrior wrote:
| 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 wrote:
| I'm seeing this issue too. No content blocker.
| nwienert wrote:
| I can't replicate, trying various devices in simulator
| and private tabs... I'll keep checking
| fernandorojo wrote:
| LambdaTest is helpful for these cases FWIW
| [deleted]
| fabiospampinato wrote:
| 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.ht...
| nwienert wrote:
| 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 wrote:
| 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 wrote:
| 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
| fabiospampinato wrote:
| 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.
| simplotek wrote:
| > There's benchmarks and code example both on this post
| and on the rest of the site showing this (...)
|
| I feel this sort of approach lacks honesty and fails to
| be objective. Anyone can cherry-pick a customized test
| where their stuff comes out as the best of class, no
| matter how underperforming it is.
|
| To have a proper apples-to-apples comparison, standard
| benchmarks are the way to go. Everything else sounds like
| snake oil and hand-waving.
| nwienert wrote:
| There's no such thing as a standard benchmark, but I
| benchmarked 8 different setups using benchmark source
| from two competitor libraries. If you have a better idea
| let me know.
|
| In the ideal you'd have to benchmark a heavy screen that
| you'd have to write for every competitor, and then
| provide timings across many different facets - initial
| load, runtime, total time, window resize, etc. As far as
| I know no one does that for _anything_ , even backend
| stuff as it's just too much effort (even the TechEmpower
| benchmarks are micro and not like this).
|
| If anything though Tamagui will look even better there.
| I've open sourced the results, re-used benchmarks from
| rival libraries, shown my work, and even published the 3
| benchmarks that _don 't_ do as well for Tamagui. It's as
| Apples-to-Apples as it gets and it's not measuring
| anything weird this is straightforward stuff.
| nicoburns wrote:
| > There's no such thing as a standard benchmark
|
| There actually is for web frameworks
| https://github.com/krausest/js-framework-benchmark
| tekknolagi wrote:
| You, above:
|
| >> Basically it's hard to be fully precise, (...)
|
| > Not really. Just put together a benchmark and let it
| speak for itself.
|
| You seem a little bit split on this one :) Yes, creating
| a fair benchmark is hard. Yes, it's hard to get other
| people to evaluate their things using your benchmark.
| Yes, it's hard to do an apples-to-apples comparison.
| simplotek wrote:
| > You seem a little bit split on this one :)
|
| Not really. By "putting up a benchmark" I mean an
| objective and verifiable standard set of performance
| tests that everyone interested can contribute their best
| effort.
|
| I means nothing if you roll out a cherry-picked ad-hoc
| test that compares a corner case of your best effort to a
| half-assed underperforming implementation of a competitor
| you chose because it suits you best.
|
| There are standard benchmarks out there, which were
| already mentioned in this discussion. It takes virtually
| no effort to roll out Tamagui's best effort. Not using
| those actually requires more effort than using them,
| which casts doubt over the validity of self-serving
| cherry-picked ad-hoc tests.
| nwienert wrote:
| The benchmarks are open source and adopted from
| competitor libraries, standard tests that style libraries
| have used for a long time. Nothing deceptive.
|
| The other benchmark posted tests more framework level
| stuff, but could be repurposed to show a more "typical
| app screen" with some effort.
| simplotek wrote:
| > Basically it's hard to be fully precise, (...)
|
| Not really. Just put together a benchmark and let it speak
| for itself.
| dylan604 wrote:
| "Catch the fun 1.0 launch video by"
|
| by what definition of fun is this video fun? is there a snark
| definition I'm not familiar? i'm hesitant to even try any code
| out from this bit of piss poor marketing, yet i'm in the market
| to find a universal app like something.
| 15155 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2022-12-30 23:00 UTC)