Examples of the Permeating Principles of the Web

Design principles are incredibly useful because they help people reach agreement on priorities.

The web platform has its own set of design principles. One of them is called the priority of constituencies. It says: always put user needs first^[1].

User needs come before the needs of web page authors, which come before the the needs of user agent implementors, which come before the the needs of specification writers, which come before theoretical purity.

I think it’s interesting to see how the design principles of the web seep into technologies and tools we use everyday, but only as much as those tools are willing to align themselves with the grain of the web. Once you deviate from the grain of the web, the principles of the web — which fiercely fight for the end user — can begin to dilute.

Two examples come to mind: deno and remix.

Deno

One of the difficult problems associated with node and npm stems from the empowerment of third-parties to run arbitrary code on your local machine with default access to the file system and network.

As a user of npm, merely installing dependencies gives third-parties hooks into running their code on your computer.

Quite frequently new stories surface of some malicious actor taking advantage of this feature of node/npm — a feature which favors people who author code over people who use (i.e. execute) code.

In the face of the problems arising from this dynamic comes deno. One of the interesting things about deno is its posture towards being webby. It strives to align itself with the web platform and use existing browser APIs and functionality wherever possible.

Given that the web has design principles governing issues like security — principles which favor the needs of users over authors — deno, in a sense, inherits these principles “for free” in its own design and functionality.

So, for example, when the web platform strives to make any GET safe for users, deno follows this lead by favoring the security of a code user over a code author.

This is why, at least in part, deno has explicit flags like --allow-net, --allow-read, and --allow-write when executing code: deno is secure by default and explicit overrides are required for scripts to have access to sensitive mechanics like a user’s network or file system.

In short: to achieve some features, node/npm favors the needs of code authors over the security of code users. Deno flips that dynamic, favoring the security of code users over the needs of code authors^[2].

Remix

Remix is a new framework I find compelling because it aligns itself with web standards. It embraces, encourages, and employs the use of web technologies such as fetch, <form>, URLSearchParams, and FormData. Additionally, progressive enhancement is a first-class citizen of the framework. Building a form? Remix says: start with a <form>. It works sans JavaScript and embraces the browser UX as a solid, robust starting point. From there, any “modern” UX you can imagine can be layered on as an enhancement to that core experience.

Remix is all about #useThePlatform. But #useThePlatform is about more than choosing to align yourself with the technologies of the web platform (HTML, CSS, JS, browser APIs, etc.). It’s also about choosing to align yourself with the principles of the web platform, principles which underlay the power dynamics of software on the web: the end user’s experience over the experience of others.

So, when a framework like Remix opts to align itself with the grain of the web, you’re not only getting consistent APIs — which has its own benefits in terms of portability and transferrable knowledge — you’re also getting the benefits of the principles which undergird the design of those technologies. You’re getting the web’s principles.

The more your technology aligns with the web platform, the more your own principles will. You too are opting for a priority of constituencies: users above all others.