Trust

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.

It’s to do with trust and suspicion.

I’ve made no secret of the fact that I’m suspicious of third-party code 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 even more dependencies, all while assuming good faith and competence on the part of every person involved.

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

I’m much more trusting of native browser features—HTML elements, CSS features, and JavaScript APIs. They’re not always perfect, but a lot 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.

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

When I write and talk about using service workers, 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!

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.

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?

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.

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.

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

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.

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

Until then, I shall remain perplexed.

Have you published a response to this? :

Responses

blog.jim-nielsen.com

Jeremy wrote a piece on trust, which I read before starting the dishes.

Then I started the dishes and couldn’t stop thinking about it. So I stopped to get these thoughts out of my brain.

So here we are. Let’s start with Jeremy’s piece.

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

He ends by asking: why this tendency avoid browser-native features but openly use third-party code (which, often, can merely be an abstraction of browser-native features)?

There are likely many influences at play here: the state of web dev education, the open-ended, low-level nature of (some) browser primitives, culture, even just human nature.

But when Jeremy asked the question of “why?”, the first thing that popped into my mind was a historically-shaped caused: browser compatibility.

We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.

For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently[1]. In some ways, it was similar to Electron: write once, run on any platform. That’s the promise of many frameworks.

Turns out, I wasn’t the only one who thought this lack of trust in the browser came from historical compatibility issues. Charles Harries had similar thoughts.

I think this perspective of trust has been hammered into developers…based almost exclusively on inequality of browser feature support…

Browser compatibility is one of the underlying promises that libraries…make to developers.

I think we’ll always have libraries and frameworks around because they are proving grounds for browser-native feature candidates. As I’ve written previously, that’s how we’ve chosen to do innovation on the web.

It seems platform answers will always lag behind library answers. How could it be any other way? That’s the route we’ve chosen to go on the web…We decided it’s better to discover new platform APIs in userland and port them back into the platform.

In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).

This trust in, and primary dependence on, the web platform could benefit developers a lot more than we might think. It can free you from learning transient idioms as frameworks come and go. Learn web platform features and carry that knowledge with you between frameworks (whether client or server).

I’m optimistic that trust in browser-native features and APIs is being restored. Libraries, frameworks, and tools (like Remix and Deno) are converging on standardization across the client and server and they’re choosing browser APIs to do it. I ventured a few predictions on this point.

Rather than create [their] own conventions and APIs that deviate from web standards, [they are] converging towards the idea of a single web platform with a unified set of APIs, no matter the environment or runtime. For example, eschew the variety of different APIs for doing async HTTP requests and instead standardized around the fetch API everywhere.

Look no further than node 18 recently shipping the fetch API (Deno already had it). And Remix is pushing in a similar direction, standardizing (and recommending usage of) browser-native APIs like fetch, Headers, Request, and Response, regardless of your deployment target.

I like to think this kind of standardization (and recommended posture towards usage) means it won’t be long until browser-native features and APIs become the only logical starting point for any code on the web.

Maybe stating a general principle for web development could help? Something along the lines of: where available, default to browser-native features over third party code, abstractions, or idioms.[2]

  1. jQuery’s actual tagline was: “write less, do more”.
  2. There’s nuance to everything, so I’d caveat that by saying: if you can articulate a good rationale for going against a general principle, go for it.

# Wednesday, April 27th, 2022 at 7:00pm

adactio.com

I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:

I would love it if someone could explain why they’re avoid native browser features but use third-party code.

Chris obliged:

I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.

Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!

Charles Harries takes on my question in his post Libraries over browser features:

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.

So again, it’s browser incompatibilities that made libraries attractive.

Jim Nielsen responds with the same message in his post Trusting Browsers:

We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.

For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.

Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.

I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.

Charles again:

This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.

I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.

Jim is glass-half-full kind of guy:

I’m optimistic that trust in browser-native features and APIs is being restored.

He also points to a very sensible mindset when it comes to third-party libraries and frameworks:

In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).

Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).

I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.

I like Jim’s proposed design princple:

Where available, default to browser-native features over third party code, abstractions, or idioms.

(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)

# Thursday, April 28th, 2022 at 11:33am

Philip Renich

Generally, I agree with @adactio on JS takes, but in Trust adactio.com/journal/19021 it feels like he’s comparing apples & oranges. Struggling to put down in words exactly what feels off for me in this (esp as someone usually advocating for less JS!)

Hyeonseok Shin 🤔

브라우저보다 서드파티 라이브러리를 더 신뢰하는 개발자들, 브라우저 호환성때문에 그렇게 훈련되었다고는 하지만, 이제 라이브러리는 폴리필로 두고 브라우저의 기능에 무게를 실어도 좋지 않을까 adactio.com/journal/19021

Chris Heilmann

👉🏼 “Trust” 🔗 adactio.com/journal/19021 Interesting thought piece by @adactio about full stack developers happily trusting a third party library (Bootstrap, React…) instead of the web platform. It is odd, but I think it might be a marketing issue more than a technical one.

Guille Paz

“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.” — @adactioJournal adactio.com/journal/19021

# Posted by Guille Paz on Saturday, May 21st, 2022 at 11:23am

2 Likes

# Liked by Dominik Schwind on Wednesday, April 27th, 2022 at 11:26am

# Liked by Marty McGuire on Wednesday, April 27th, 2022 at 2:51pm

3 Bookmarks

# Wednesday, April 27th, 2022 at 5:15pm

# Bookmarked by James' Coffee Blog on Thursday, May 5th, 2022 at 2:29pm

# Bookmarked by James' Coffee Blog on Thursday, May 5th, 2022 at 2:30pm

Previously on this day

2 years ago I wrote Principles and priorities

Using design principles to embody your priorities.

7 years ago I wrote 100 words 036

Day thirty six.

7 years ago I wrote The shape of Responsive Day Out 3: The Final Breakpoint

Bringing the conference series to a close with a bang!

10 years ago I wrote Conditional CSS

The results are in. Here’s what you came up with to solve the problem of conditional loading with CSS.

11 years ago I wrote Content First

In which I repeatedly hammer home the point that it’s all about the content.

13 years ago I wrote All Our Yesterdays

Opening up Bamboo Juice 2009.

15 years ago I wrote POSH Patterns

Not everything has to be a microformat.

15 years ago I wrote The Dunbar number of the beast

My invisible friend has a bigger Dunbar number than your invisible friend.

16 years ago I wrote Natural language hCard

You can use the hCard microformat in plain English sentences.

18 years ago I wrote Irish spring break

I’m back in Brighton after my short break in Ireland. For those of you uninterested in travelogues and holiday snaps, look away now.

19 years ago I wrote About this site

I’ve updated the "About" section of this site to include a new page about this site and how it was made.

20 years ago I wrote surRealpolitik

Ah, France.