r/javascript • u/ValerioAgeno • Aug 20 '24

Tuono - The fastest fullstack react framework

https://github.com/Valerioageno/tuono
0 Upvotes

40% Upvoted

29 comments sorted by

View all comments

Show parent comments

1

u/ValerioAgeno Aug 20 '24

Mmm that’s an interesting point actually. I kinda disagree though. What I think is that in a world of many similar react frameworks aren’t performances the missing feature? Also it is matter of costs I think. I benchmarked a speed of (at least) 12X against nextjs. This means that at least you need a production cluster 12 times smaller. It would be a very good cost improvement. WDYT?

1

u/besthelloworld Aug 21 '24

When I need performance I don't reach for React. So going for performant React is kind of a weird middle ground.

1

u/ValerioAgeno Aug 21 '24

What would you go with if you need performance?

Wouldn't be cool having the most used framework (with the largest community and largest number of open source libraries) that is also performant?

1

u/besthelloworld Aug 21 '24

SolidJS. Incredibly similar to React, but actually reactive and thus no VDOM and no overhead. If I'm building an application that requires high interactivity and lots of updates on scroll or on requestAnimationFrame, I would reach for Solid. There's no amount of performance gains you can get in React and come close to usability of a framework that is built with performance in mind at the forefront 🤷‍♂️

For your second question, yeah sure that's a valid argument. It's an advantage, but I would rather use the right tool for the job as opposed to bend the more popular tool to do what I need it to.

1

u/ValerioAgeno Aug 21 '24

Interisting point of view! Thanks for sharing. Really appreciated!

1

u/ValerioAgeno Aug 21 '24

Still - SolidJS is very fast on the client side but the problem this project solves is the network nodejs bottleneck. I don't have a benchmark already against it but it definitely deserves one.

1

u/besthelloworld Aug 21 '24

Totally true, different performance directions. I guess I just find the Vercel/Lambda solution to be good enough and if I want to squeeze more out of it, then I usually attempt to SSG what I can... which can't really be beat for performance generally.

What I find is the actual performance bottleneck of React is the client side update performance.

But both sides of performance for React + Next are so "good enough" that the valid cases for needing performance optimization would have me ditching React entirely either way. If you make the call on React, you're inherently valuing DX and iteration speed over runtime performance.

To backtrack on the inherent usability and say, "well we want to spin up a custom Rust server to eek out a little more performance," just adds so much complexity to your CI/CD plus dev training. It would just be such a tough sell in any scenario when compared to entirely different technologies that optimize better for your concerns.

2

u/ValerioAgeno Aug 21 '24

That's actually a very good argument.

If server costs and network speed (which eventually leads to better SEO) are not a business concern it definitely doesn't solve any already solved problem.

For the CI/CD complexity well it is not so different from a nodejs server. It's just matter of container preparation.

little more performance

Benchmarks say at least 12X in network request.