[herrkanin]

I'm so sick of these performance benchmarks. I understand it's easy to spin them up to show that one framework is faster than another, but in general all these frameworks are fast enough for 99.9% of use cases.

Where frameworks lack today, in my opinion, are in providing the right tools further optimize the UX of interacting with web sites. It's a constant struggle of loading spinners and flicker and loss of scroll positions.

The only framework I see that actually tries to resolve these very hard problems is React, through their work on new asynchronous primitives like startTransition. Yes, they are currently hard to understand how to properly use, but I so wish the discourse would be around how to best resolve these actual UX issues than who can create 50M divs the fastest.

[candiddevmike]

IMO, we desperately need standards or tooling to make frameworks easier to swap out and interoperate. Web Components was supposed to be this, but it's not quite there yet and requires awkward wrappers around everything.

No framework will stand the test of time. I encourage everyone to, at the very least, own your state and router libraries, as you'll be able to extend them when you want to jump ship in a more incremental fashion. Going all in on a single framework's state, router, and view libraries will create a ton of inertia...

[Imustaskforhelp]

At this point just ditch the browser and instead have a browser with html css and lua, maybe that will help the world (satire but I genuinely want the world to somehow move to this if it ever becomes popular)

Would this make me a bad guy if I tried but couldn't find the link? oof. wait for sometime so that I see the list of my github stars because its hidden somewhere in there...

Edit: found it! https://github.com/outpoot/gurted

Here's a video as well which I found later through the github username and some yt searches later

https://www.youtube.com/watch?v=37ISfJ2NSXQ

[smj-edison]

To me the only framework that has really pulled this off is Phoenix live view and spinoffs, because they solve the fundamental problem: pipelined latency. The frontend has to request object A, wait for the result, then it has to request object B, then wait, etc, etc. There's too many combinations of objects, so it would be impossible to have an endpoint per specific request (I suppose graphql has sort of done this, but it's still not flexible enough for complicated transforms). Live view solves this problem by not really solving the problem, but moving everything server-side so pipelined latency is dramatically lower.

[bpicolo]

Vue has great tools for a lot of this: https://vuejs.org/guide/built-ins/transition

[IshKebab]

Yeah I agree, these benchmarks are basically meaningless. E.g. they acclaim Vue's binding based approach as being faster, but it also leads to spaghetti code. React was specifically designed to avoid that so you can build big apps that aren't buggy.

Also isn't Preact meant to be a faster option if you really need performance?

[yurishimo]

Arent buggy? React had to introduce a compiler because the masses only write buggy code. The reason they likely waited so long to do it is because they felt like it was a waste to write software to fix something that theoretically has “no flaws” because it’s “just JavaScript”.

Literally every other JS framework figured this out years and years ago and some over a decade ago. Compilers help to raise the floor for everyone so we don’t need to worry about making a dumb mistake and drastically slowing down our programs. Compilers are the evolution of software.

[ergocoder]

> I'm so sick of these performance benchmarks. I understand it's easy to spin them up to show that one framework is faster than another, but in general all these frameworks are fast enough for 99.9% of use cases.

Yes, any framework is fast enough. At this point, everybody probably knows already. Nobody would ever say React is not appropriate because it's slower than Svelte. No sane person would ever argue for a migration from React to Svelte based on this benchmark.

But being against the performance benchmark is such a weird take. It's so strange that many times there are hidden agendas.

Many times because a person advocates for X over Y at Company Z. Then, there's some random benchmark saying Y is faster. Now the person needs some way to cope. The best way is to refute the benchmark in some ways, but this would take a huge amount of time and effort. The second best way is to simply say "it doesn't matter. I hate this useless benchmark. There are more important problems to solve!"... as if everyone on the planet has to always solve the most important problem first ... only one problem and no more. Haha

[fancyswimtime]

yes because these benchmarks are not akin to the real world; rendering a large list of data? You'd use a virtualized list etc

[andrewmcwatters]

Most of that latency is coming from back ends across most major sites, anyway, so it's the wrong place to test.

As an addition to the general commentary here, "The Toilet Paper" is an unfortunate choice of label for this article, and maybe also indicative of the quality of the writing.

[herrkanin]

It really isn't - a ui framework should be able to properly handle backend latency and provide a great experience while waiting for a backend response with no flicker while not locking the entire ui. It's just way harder to set up good benchmarks for this.

[andrewmcwatters]

That's not handling latency.