4 ms·

2x performance in what benchmark? React seems less than 2x slower than painfully optimized vanilla code in js-framework-benchmark, even considering the "swap r

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.
      - redbar0n 4y ago
        The standard benchmark mentioned (krausest) is for JS frameworks. But Tamagui is not a framework. (It uses React as the framework on web, so would have similar perfomance to that in krausest.) Tamagui is a style and component library (plus optimizing compiler). Do you know of any standard benchmarks for any of those?
        fabiospampinato 4y ago
        Ok, but then I don't understand the claim that it's faster than React while using React. I don't know of any more specific and good benchmarks for that.
        deleted 4y ago
        [deleted]
        redbar0n 4y ago
        Oh, that’s just mostly (afaik) the result of the tree flattening it does being an optimization of React, because it gives React less to handle in the first place. That’s why benchmarking framework render operations like krausest does doesn’t really apply. Because it is a nano benchmark of individual operations on the tree, not the size of it. You’d need a macro benchmark on a real world app to measure gains from reducing the DOM tree size. That would be very app-specific, and so the gains from that would also be very specific to how the app was designed. The closest you could get (that I’ve seen) is these micro benchmarks on a small custom DOM tree: https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks
    - simplotek 4y ago
      > 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.
      - tekknolagi 4y ago
        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 4y ago
        > 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 4y ago
        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.
        4y ago
- simplotek 4y ago
  > Basically it’s hard to be fully precise, (...) Not really. Just put together a benchmark and let it speak for itself.
  - nwienert 4y ago
    https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks The benchmarks speak for themselves.

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.
    - redbar0n 4y ago
      The standard benchmark mentioned (krausest) is for JS frameworks. But Tamagui is not a framework. (It uses React as the framework on web, so would have similar perfomance to that in krausest.) Tamagui is a style and component library (plus optimizing compiler). Do you know of any standard benchmarks for any of those?
      - fabiospampinato 4y ago
        Ok, but then I don't understand the claim that it's faster than React while using React. I don't know of any more specific and good benchmarks for that.
        deleted 4y ago
        [deleted]
        redbar0n 4y ago
        Oh, that’s just mostly (afaik) the result of the tree flattening it does being an optimization of React, because it gives React less to handle in the first place. That’s why benchmarking framework render operations like krausest does doesn’t really apply. Because it is a nano benchmark of individual operations on the tree, not the size of it. You’d need a macro benchmark on a real world app to measure gains from reducing the DOM tree size. That would be very app-specific, and so the gains from that would also be very specific to how the app was designed. The closest you could get (that I’ve seen) is these micro benchmarks on a small custom DOM tree: https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks
  - simplotek 4y ago
    > 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.
    - tekknolagi 4y ago
      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 4y ago
        > 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 4y ago
        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.
        4y ago
simplotek 4y ago
> Basically it’s hard to be fully precise, (...) Not really. Just put together a benchmark and let it speak for itself.
- nwienert 4y ago
  https://tamagui.dev/docs/intro/benchmarks https://tamagui.dev/docs/intro/benchmarks The benchmarks speak for themselves.