Aspnetcore: [Blazor WebAssembly] Create performance benchmarks for Blazor against other UI frameworks

[xrkolovos]

It would be nice to have performance benchmarks of blazor against

• Angular
• VueJs
• React

Some scenarios that it would be nice to be inclueded:

• Hello world test
• Same to Do app
• Http calls scenario
• Two-way data binding in a large form
• An app with a serious amount of components
• A component with a large table
• Some Routing scenario
• other ideas...?

What it needs to be measured:

• bootup time
• total kilobytes
• json serialization time
• memory needed
• time passed when renders complete
• DOM manipulation aspects
• http calls aspects
• other ideas...?

[xrkolovos]

Some work is being done here -> https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1

[xrkolovos]

Related #21085 #22432

[danroth27]

Hi @xrkolovos. Our focus with Blazor is to improve productivity by enabling a full stack .NET development experience. Blazor WebAssembly is currently based on a .NET IL interpreter, so we know it isn't going to win any speed competitions when compared with front end JavaScript frameworks like Angular/React/Vue. We are working to improve Blazor WebAssembly performance for .NET 5, and we plan to provide AoT compilation support in .NET 6 at which point it may make sense for us to revisit doing this kind of comparison benchmarking. If the community is interested in producing these benchmarks sooner, that's also completely reasonable.

[xrkolovos]

Hi @danroth27. You answer is perfectly understood.

I believe that every one that uses blazor sees and understands things that are missing in this technology (like dev experience, hot reload etc). Developers choose if they want to start developing with Blazor by measuring, first what this technology is offering (and it's a lot) together with what is missing. What is missing is answered by your next features timeline. It's clear that there are still things to be done. Every technology needs some years to mature and be feature complete.

It's important though, to help people that takes risks and choose the technologies their colleagues will develop with. In this direction, i think, is important to have more informations in the performance scope. We need to know how much behind blazor is, and what are the expectations. Based on your comment, I hope you will choose wisely when the right time is to start this measurements.

In the end is important to know if Web Assembly UI frameworks can be in the future equal or faster to javascript frameworks? Or they will always be left behind?

[srxqds]

@xrkolovos thank you, we use webassembly for making tool show view log, but we found that it may became ui freeze when more than 600 lines.
It is so sad, we want your help to solve it.
the code and problem show with it: https://github.com/dotnet/aspnetcore/issues/23701

[riesvriend]

It would be nice to look at the high level approach to create performant rendering of large dynamic data sets. Mobx (state tree) on react is nailing it and would also apply to Blazor.
It’s not only performance, but also ease of coding when the number of components and their data rendering dependencies get huge. With a MST style model, it stays simple. The components are ‘pure’ (no state and no NeedsRender logic), and renders are triggered only when really applicable. See the video here
https://mobx-state-tree.js.org/concepts/using-react

[simonpbond]

@danroth27 Would Microsoft ever run Microsoft.com (the public facing & landing pages) on Blazor? This should be the internal benchmark. At this point in time I guess the answer would be no, since there is a 'loading framework time' the end user needs to experience. Awesome for back-end sites, but I would love to see it eventually reach the level of being a contender for serious public facing sites & landing pages also.