DEV Community

Discussion on: The True Delight of React’s Error and Warning Messages

Collapse
 
oenonono profile image
Junk • Edited

Some important history. Error has a specific meaning in general and in JavaScript and a fraught history on the web platform. React explicitly labels many of its errors you demonstrated as warnings. This is intentional and means something. An error is the highest level of problem. An error is something you throw in JavaScript and not all that long ago, an error would halt further JavaScript execution in IE without try/catch, which was simultaneously too abysmally slow to use. The web platform has long been a "forgiving" one, in part because "real programming languages" were an afterthought. It was a platform for users more than for developers and web browsers correspondingly went out of their way to make their best attempt with whatever code they were given. There are numerous syntactic mistakes a web browser will accept, parse, automatically correct or partially discard, and still spit out a functional web page. Once upon a time, as developers became a louder voice and larger base, draconian error handling was introduced to the web for the next generation web, envisioned as being XML-based. Stop spending developer time and processing cycles trying to be forgiving, people said. Instead, be specific about what the problem is so that the developer who caused the problem can fix it. After all, it was difficult to track down the cause of unexpected results from browsers' automatic corrections. But this was a bad experience for users, who could now be greeted with a web page that was just one big error. So effort instead went into more robust developer tooling in browsers, which developers could then make use of, and into improving JavaScript, and into JavaScript frameworks. Which made (and continue to make) their own mistakes in this respect. Contrast React with Angular 1. Many Angular 1 errors would interrupt application functionality entirely. While Angular went to the trouble of carefully crafted messages, elaborate stack traces, and even links for more information on each error, they nevertheless still mostly lacked specific information or examples that would help track down the root cause of a problem. Most errors were errors, the highest severity. It was mostly unforgiving, frequently draconian, and rarely improved user experience. It was, however, more like what programmers were used to. Its familiarity made it preferable to some web developers. Next, React. React provides warnings that attempt to forgive, continue to render a functional application, and yet give specific and actionable information to a developer. This is a huge improvement in JS frameworks and addresses the real developer issues caused by the way browsers work while not discarding the good parts in and reasons why browsers work that way. But does it, by necessity in its JavaScript runtime, also have errors that would result in broken experiences for users? How do you prevent that? What about the app you're writing? What did you learn from React's errors about error experiences for your app's users? Because that's the most important part of whole thing. It's the reason we get paid. Better end user experience means a better world. Better developer experience is just a means of getting there.