flexbugs VS js-framework-benchmark

For old features yes, for new ones it depends.

https://github.com/philipwalton/flexbugs

First, we read all the articles that showed us how to use it. Then we need to understand the axes. After that, we needed to wait for browser support. In the meantime, some of us brave enough used float fallbacks. On top of all that, we needed to deal with bugs. Those were the happy times, but they got us to this point in the frontend development phase.

To actually contribute, there's some flexbox bugs here which are still valid. https://github.com/philipwalton/flexbugs

If you find yourself in a situation when you have to solve a flexbox related layout bug for IE11, you might want to have a look at this collection of known issues and workarounds which helped me a great deal in the past.

For functional stuff, sure, but I don't think this is achievable within the UI domain. CSS rules have implementation details that change how you write it, for example there's a documented set of issues in flex implementations maintained here: https://github.com/philipwalton/flexbugs

It might be practical and possible to become mainstream for some domains, but it's doubtful for others.

For example, I've regularly ran into flexbox issues that are Safari-specific. I've discovered these by testing in other browsers and confirming that the issue only shows up in Safari. A good reference of Flexbox browser-specific bugs is Philip Walton's flexbugs repo.

JavaScript benchmarks are instruments for measuring the speed and effectiveness with which a JavaScript engine—such as the ones found in web browsers—can complete particular tasks. Benchmarks are used by developers and browser vendors to evaluate various engines, find places in the code where improvements are needed, and make sure JavaScript standards are being followed.

Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark

Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation.

And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?

It literally says at the bottom "Data from https://krausest.github.io/js-framework-benchmark/"

The standard benchmark for js frameworks would be best: https://github.com/krausest/js-framework-benchmark