{"id":377169,"date":"2023-02-09T11:45:48","date_gmt":"2023-02-09T19:45:48","guid":{"rendered":"https:\/\/css-tricks.com\/?p=377169"},"modified":"2023-02-09T11:45:53","modified_gmt":"2023-02-09T19:45:53","slug":"healthcare-selling-lemons-and-the-price-of-developer-experience","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/healthcare-selling-lemons-and-the-price-of-developer-experience\/","title":{"rendered":"Healthcare, Selling Lemons, and the Price of Developer Experience"},"content":{"rendered":"\n
Every now and then, a one blog post is published and it spurs a reaction or response in others that are, in turn, published as blogs posts, and a theme starts to emerge. That’s what happened this past week and the theme developed around the cost of JavaScript frameworks \u2014 a cost that, in this case, reveals just how darn important it is to use JavaScript responsibly<\/a>.<\/p>\n\n\n\n\n\n\n This is where the story begins. Eric goes to a health service provider website to book an appointment and gets… a blank screen.<\/p>\n\n\n\n In addition to a terrifying amount of telemetry<\/a>, Modern Health\u2019s customer-facing experience is delivered using React and Webpack.<\/p>\n\n\n\n If you are familiar with how the web is built, what happened is pretty obvious: A website that over-relies on JavaScript to power its experience had its logic collide with one or more other errant pieces of logic that it summons. This created a deadlock.<\/p>\n\n\n\n If you do not make digital experiences for a living, what happened is not obvious at all. All you see is a tiny fake loading spinner that never stops.<\/p>\n<\/blockquote>\n\n\n\n D’oh.<\/em> This might be mere nuisance \u2014 or even laughable \u2014 in some situations, but not when someone’s health is on the line:<\/p>\n\n\n\n A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A\/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit<\/a> if the person using the thing they built can\u2019t actually get what they need.<\/p>\n<\/blockquote>\n\n\n\n This is the big smack of reality. What happens when our tooling and reporting \u2014 the very things that are supposed to make our work more effective \u2014 get in the way of the user experience? These are tools that provide insights that can help us anticipate a user’s needs, especially in a time of need<\/a>.<\/p>\n\n\n\n I realize that pointing the finger at JavaScript frameworks is already divisive. But this goes beyond whether you use React or framework d’jour<\/em>. It’s about business priorities and developer experience conflicting with user experiences.<\/p>\n\n\n Partisans for slow, complex frameworks have successfully marketed lemons as the hot new thing, despite the pervasive failures in their wake, crowding out higher-quality options in the process.<\/p>\n\n\n\n These technologies were initially pitched on the back of “better user experiences”<\/em>, but have utterly failed<\/a> to deliver on that promise outside of the high-management-maturity organisations<\/a> in which they were born. Transplanted into the wider web, these new stacks have proven to be expensive duds<\/a>.<\/p>\n<\/blockquote>\n\n\n\n There’s the rub. Alex ain’t mincing words, but notice that the onus is on the way frameworks haved been marketed to developers than developers themselves. The sales pitch?<\/p>\n\n\n\n Once the lemon sellers embed the data-light idea that improved “Developer Experience” (“DX”) leads to better user outcomes, improving “DX” became and end unto itself, and many who knew better felt forced to play along. The long lead times in falsifying trickle-down UX was a feature, not a bug; they don’t need you to succeed, only to keep buying.<\/p>\n\n\n\n As marketing goes, the “DX” bait-and-switch<\/a> is brilliant, but the tech isn’t delivering for anyone but<\/em> developers.<\/p>\n<\/blockquote>\n\n\n\n Tough to stomach, right? No one wants to be duped, and it’s tough to admit a sunken cost when there is one. It gets downright personal if you’ve invested time in a specific piece of tech and effort integrating it into your stack. Development workflows are hard and settling into one is sorta like settling into a house you plan on living in a little while. But you’d want to know if your house was built on what Alex calls a “sandy foundation”<\/a>.<\/p>\n\n\n\n I’d just like to pause here a moment to say I have no skin in this debate. As a web generalist, I tend to adopt new tools early for familiarity then drop them fast, relegating them to my toolshed until I find a good use for them. In other words, my knowledge is wide<\/em> but not very deep<\/em> in one area or thing. HTML, CSS, and JavaScript is my go-to cocktail<\/a>, but I do care a great deal about user experience and know when to reach for a tool to solve a particular thing.<\/p>\n\n\n\n And let’s acknowledge that not everyone has a say in the matter. Many of us work on managed teams that are prescribed the tools we use. Alex says as much, which I think is important to call out because it’s clear this isn’t meant to be personal. It’s a statement on our priorities and making sure they along to user expectations.<\/p>\n\n\n\n Let’s alow Chris to steer us back to the story…<\/p>\n\n\nEric Bailey: Modern Health, frameworks, performance, and harm<\/a><\/h3>\n\n\n
\n
\n
Alex Russell: The Market for Lemons<\/a><\/h3>\n\n\n
\n
\n
Chris Coyier: End-To-End Tests with Content Blockers?<\/a><\/h3>\n\n\n