How to avoid frontend tech making us resentful

A lot is being written about how confusing and overwhelming frontend has become (see JavaScript Frameworks - Heading into 2025 for one overview) and I believe it has a lot to do with the incentives for different parties, and I discuss what it takes to fill a hole that exists, and create a more healthy ecosystem.

The reality for a developer

When a frontend developer is considering different technologies, they need a way to convince the stakeholders (both business folks and their dev peers), and the only way to do that is by building things and measuring them, thus proving the benefits and managing the expectations. (The driver might be the need to build something completely new, improve an already existing thing, or maybe even just prove that no change is necessary and there is no benefit to be gained through an alternative, in a case where, say, external parties are putting the pressure for company to consider it.)

An example might be a developer that is considering utilizing more React Server Components (the focus is not on RSC itself, just as easily it can be something else, another framework or another piece of tech). They need to adapt their architecture to include a server, adopt new programming patterns, think about file organization with these new routers and directives, reason about constraints of all of those, educate people about all of this, align on internal best practices and needs, talk with customers and update SLAs and documentation,... This all is very costly and risky, so a decision must not be made lightly.

(This grueling and very costly process of comparing different technologies and doing architectural migrations is something that a good chunk of teams across the globe are going through. Just think of how many blog posts and videos have been there about failed promises of a piece of tech (You don't need Next.js – Why we migrated from Next to React 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, difficult problems are difficult to solve, and the ROI is not there. Over time, getting burned this way too many times leads to resentment, burnout, and an overall aversion to future risks.

The companies that are building these cool new technologies (and they really can be cool!) get surprised that people feel resentment, and can seem inconsiderate of the amount of work those kinds of efforts require and the inaccessibility of verifiable ways of telling what the realistic expectations might be. It can all look, well, dishonest.

The realization is that the companies building these new technologies have the burden of responsibility of proving that their tech works, not just via advertising, but by also providing developers with tools to guide their decisions and confirm the benefits for themselves.

The tools

So, what those tools look actually look like?

The tools would continuously report on the metrics that the developers care about (that can be objectively measured), holistically combined and correlated with changes that developers are making to help them understand the trade-offs:

• bundle sizes (exhaustive reporting on per-page and shared bundles, insights into additional bundles that would be loaded lazily (on interactions) and/or automatically (service workers, preloading and other warmups))
• over-the-network metrics (with more serialization, it's good to know what the actual savings are on the client, and how it impacts the communication between the server and the client)
• timing splits and performance (that include both server and client, e.g. how long it takes to render content and how much of that is on the server vs client, the network latency and transfer etc)
• web vitals (do we need more granular splits for different parts of webpages that get both loaded and rendered progressively? is having a one-off metrics only for the initial load sufficient anymore?)
• trends (over time) and correlations between all of these various metrics at the level of an entire project (so that a team can keep track of how things progress and avoid being unpleasantly surprised with performance degrading over time or introducing an edge case only in some places and some pages)

The things mentioned here are the same few things that any team would care about, yet the tooling to get to those kinds of insights seems difficult and convoluted to set up, and sometimes practically impossible when dealing with frameworks that behave like a black box.

Incentives

This kind of tooling doesn't necessarily need to be provided by the same companies that develop these new techs themselves, but could also by built by a different company (there might be hints of similar considerations already ? Evan You - Vue, Vite, VoidZero and the Future of JavaScript Tooling, 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.

The above is the detailed content of How to avoid frontend tech making us resentful. For more information, please follow other related articles on the PHP Chinese website!