Recently, a series of blog posts have sparked heated discussions about the cost of JavaScript frameworks, highlighting the importance of using JavaScript responsibly.

Eric Bailey: Modern medical, framework, performance and damage

The story begins when Eric attempts to make an appointment on a medical provider's website, but encounters a blank screen.

Modern Healthcare's customer experience relies on React and Webpack, accompanied by a large amount of telemetry data.

For those familiar with web development, the reason is obvious: websites that rely too much on JavaScript, whose logic conflicts with other error logics called, resulting in deadlocks.

But for non-professionals, this is not obvious. All they see is the never-ending loading animation.

This may be a minor trouble in some cases, but the consequences are unimaginable when it comes to health issues:

People seeking help won't care about TypeScript, tree shaking, hot module replacement, A/B testing, burnout chart, NPS, OKR, KPI, or other entrepreneurial terms. If users cannot get the services they need, the developer experience is meaningless.

This is the impact of reality. What happens when our tools and reports—the tools that should be more productive—are in the way that hinder the user experience? These tools are supposed to provide insights that help us predict user needs, especially in emergencies.

I know that pointing the finger at the JavaScript framework itself is easy to cause controversy. But it's not just about using React or other frameworks, but a conflict between business priorities and developer experience and user experience.

Alex Russell: Lemon Market

The proponents of slow and complex frameworks have successfully packaged inefficient frameworks into trendy things, squeezing higher quality choices despite their flaws everywhere.

These technologies initially under the banner of "improving user experience", but outside of high-maturity organizations, they completely failed to fulfill their promises. In the wider web environment, these new technology stacks have proven to be expensive failures.

The problem is here. Alex is outspoken, but he points out that the responsibility lies in the way the framework is marketed, not the developers themselves. What is a marketing strategy?

Once lemon sellers instill in the concept that “improving developer experience (DX) leads to a better user experience”, “improving DX” becomes the purpose itself, and many people who know its disadvantages are forced to participate. It is a strategy to mask the negative effects of user experience for a long time, not a mistake; they don’t need you to succeed, they just need you to continue to buy.

From a marketing perspective, this "DX" bait and packing strategy is very clever, but the technology itself does not bring benefits to anyone, except for the developer.

It's hard to accept, right? No one wants to be deceived, and it is difficult to admit that sunk costs. It's even harder if you've invested your time and effort in a specific technology and integrated it into your technology stack. The development workflow is complex, and adapting to one process is like adapting to a house where you plan to live for a while. But you should know whether your house is built on what Alex calls "sand foundation".

I want to pause here to show that I have no personal position on this debate. As a web generalist, I tend to try new tools early to get familiar with them, then quickly give up and put them in my toolbox until I find the right purpose. In other words, I have a wide range of knowledge, but I don’t have a deep understanding in a specific field. HTML, CSS, and JavaScript are my common combinations, but I place great emphasis on user experience and know when to choose the right tool to solve a specific problem.

Moreover, we must admit that not everyone can make decisions on their own. Many of us work on managed teams and use tools pre-specified. Alex also mentioned this, and I think it's important because it clearly shows that it's not for individuals. This is a statement about our priorities and ensuring that they match the user's expectations.

Let's let Chris guide us back to the topic...

Chris Coyier: End-to-end testing using content interceptor?

So, maybe your application is built with React, and the reason is not important. There is still some work to ensure the reliability and accessibility of the application.

Just blocking a file shouldn't completely destroy a website, but it does it often! In JavaScript, this is probably because the developer writes first-party JavaScript (I usually block) that relies on third-party JavaScript (I usually block).

[…]

If I block resources from tracking-website.com, my first-party JavaScript throws an error. JavaScript does not ignore errors. If an error is thrown, it will not execute the lower JavaScript code in the file. If the lower-level code is transitionToOnboarding();—then it will not be executed.

Maybe it is worth revisiting your workflow and adjusting it to identify more failure points.

So, here's an idea: run your end-to-end tests in a browser with the popular content blocker installed and its default configuration.

Doing so may find some problems that will stop your customers, as well as those in need.

Good idea! Any way to help depict how an application is used more realistically is good. This clarity can emerge early in the process, perhaps before making development decisions. Get to know your users. Why do they use this app? How do they browse the web? Where is their geographical location? What problems could get in the way of them? Chris also gave a good speech on this.

The above is the detailed content of Healthcare, Selling Lemons, and the Price of Developer Experience. For more information, please follow other related articles on the PHP Chinese website!