davidbgk
/
larlet-fr-david-cache

title: Trust
url: https://adactio.com/journal/19021
hash_url: 8981770b1b5be8044fd201739e67c60d

<p>I’ve noticed a strange mindset amongst front-end/full-stack developers. At least it seems strange to me. But maybe I’m the one with the strange mindset and everyone else knows something I don’t.</p>

<p>It’s to do with trust and suspicion.</p>

<p>I’ve made no secret of the fact that I’m suspicious of <a href="https://adactio.com/articles/18676">third-party code</a> and dependencies in general. Every dependency you add to a project is one more potential single point of failure. You have to trust that the strangers who wrote that code knew what they were doing. I’m still somewhat flabbergasted that developers regularly add dependencies—via npm or yarn or whatever—that then pull in <em>even more dependencies</em>, all while assuming good faith and competence on the part of every person involved.</p>

<p>It’s a touching expression of faith in your fellow humans, but I’m not keen on the idea of faith-based development.</p>

<p>I’m much more trusting of native browser features—HTML elements, CSS features, and JavaScript APIs. They’re not always perfect, but a <em>lot</em> of thought goes into their development. By the time they land in browsers, a whole lot of smart people have kicked the tyres and considered many different angles. As a bonus, I don’t need to install them. Even better, end users don’t need to install them.</p>

<p>And yet, the mindset I’ve noticed is that many developers are <em>suspicious</em> of browser features but <em>trusting</em> of third-party libraries.</p>

<p>When I <a href="https://abookapart.com/products/going-offline">write</a> and <a href="https://www.youtube.com/watch?v=RVdW-P_oAJ0&amp;list=PLgaHsrPMLcFBD8kHNmgeBstA3zOxY_x-j&amp;index=7">talk</a> about using <a href="https://adactio.com/journal/tags/serviceworkers">service workers</a>, I often come across scepticism from developers about writing the service worker code. “Is there a library I can use?” they ask. “Well, yes” I reply, “but then you’ve got to understand the library, and the time it takes you to do that could be spent understanding the native code.” So even though a library might not offer any new functionality—just a different idion—many developers are more likely to trust the third-party library than they are to trust the underlying code that the third-party library is abstracting!</p>

<p>Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.</p>

<p>On the one hand, I get it. Bootstrap and React are very popular. That popularity speaks volumes. If lots of people use a technology, it must be a safe bet, right?</p>

<p>But if we’re talking about popularity, every single browser today ships with support for features like grid, custom properties, service workers and web components. No third-party framework can even come close to that install base.</p>

<p>And the fact that these technologies have shipped in stable browsers means they’re vetted. They’ve been through a rigourous testing phase. They’ve effectively got a seal of approval from each individual browser maker. To me, that seems like a much bigger signal of trustworthiness than the popularity of a third-party library or framework.</p>

<p>So I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.</p>

<p>Is it because of the job market? When recruiters are looking for developers, their laundry list is usually third-party technologies: React, Vue, Bootstrap, etc. It’s rare to find a job ad that lists native browser technologies: flexbox, grid, service workers, web components.</p>

<p>I would love it if someone could explain why they avoid native browser features but use third-party code.</p>

<p>Until then, I shall remain perplexed.</p>