How to avoid frontend tech making us resentful

A lot is being written about how confusing and overwhelming frontend has become (see as one the most recent ones).)

However, very quickly upon starting to build POCs, the developer realizes that a lot of tech offerings are advertised via "trust us, bro" argument.

Every new bit of technology that comes out of the framework kitchen tells a story of magnificent improvements, with fairly plastic demos showcasing them. But the reality is often far more messy, the benefits marginal, and yet the experimentation and migration very costly. The challenge is for every company and every team to reinvent the wheel and come up with ways of proving that there is in fact some utility for their particular case. A tremendous amount of resources and in-house expertise is required to holistically and exhaustively consider and test various options.

The healthy dynamics of the frontend ecosystem gets jeopardized when a company that shills Yet Another™ feature as The Now Best Thing Ever™, as evident by a Trust Me Bro™ claim, gets the developer to buy into it and put in the effort to migrate to it, only to discover that, indeed, , or I could be misinterpreting what Evan is saying). However, I believe the same company that builds some new tech should be the one that provides the tooling to verify its gains as well, because the incentives are on their side:

By building such a tooling that transparently reports on various metrics and differences between various implementations, a company building a new tech/framework, can first internally verify the progress and claims, and help itself understand the trade-offs and then optimize the right metrics. In that way, it keeps the company accountable and honest. So, the entire improvement feedback loop can happen internally, much before even reaching the public.

By then also delivering those same tools to the public, the company can avoid any risk of false claims and disappontment, and instead offer the ability for everyone to simply verify things for themselves, on their own projects. That would, in turn, generate even more trust and gratitude.

The company building the tech is also best positioned to build the tooling for it - it best understands its APIs and capabilities, and how much or how little of it is necessary to open up to make the tooling work (that being another way to keep the company honest and fair).

Ultimately, if the company wants to extend its business model by making that tooling paid, it could do so. (Currently, a similar approach usually manifests via contracting and direct involvement with client companies, however, tooling could make the entire thing far more self-served which could benefit all parties.)

Conclusion

We are in an era of competing technologies in which there's no single best solution, and architectural migrations on the projects that are becoming ever larger, are not cheap. To make it possible to decide and move smartly, a more comprehensive tooling and reporting is required, the one that guides and assesses decisions, changes and trade-offs continuously, and doesn't just report after everything has been done.

The companies building these new technologies and frameworks are the ones that would benefit the most from such tooling and are best positioned to build it.