/reader

As someone who has grown up through the tumult of the design profession in technology, that really resonates. I’ve worked on lots of projects where I got tired of continually justifying design decisions with language dressed in corporate rationality.

This is part of the allure of code. To most people, code either works or it doesn’t. However bad it might be, you can always justify it with “Yeah, but it’s working.”

But visual design is subjective forever. And that’s a difficult space to work in, where you need to forever justify your choices.

In that kind of environment, decisions are often made by whoever can come up with the best language to justify their choices, or whoever has the most senior job title.

Personally, I found it very exhausting.

As Radek points out, this homogenization justified through seemingly-profound language reveals something deeper about tech as an industry: folks are afraid to stand out too much.

Despite claims of innovation and disruption, there's tremendous pressure to look legitimate by conforming to established visual language.

In contrast to this stands the work of individual creators whose work I have always loved — whether its individual blogs, videos, websites, you name it. The individual (and I’ll throw small teams in there too) have a sense of taste that doesn’t dilute through the structure and processes of a larger organization.

No single person suggests making a logo that resembles an anus, but when everyone's feedback gets incorporated, that's what often emerges.

In other words, no individual would ever recommend what you get through corporate hierarchies.

That’s why I love the work of small teams and individuals. There’s still soul. You can still sense the individuals — their personalities, their values — oozing through the work. Reminds me of Jony Ive’s description of when he first encountered a Mac:

I was shocked that I had a sense for the people who made it. They could’ve been in the room. You really had a sense of what was on their minds, and their values, and their joy and exuberance in making something that they knew was helpful.

This is precisely why I love the websites of individuals because their visual language is as varied as the humans behind them — I mean, just look at the websites of these individuals and small teams. You immediately get a sense for the people behind them. I love it!

Reply via: Email · Mastodon · Bluesky

{
  "liabilities": {
    "react": "^19.0.0",
    "typescript": "^5.0.0"
  },
  "devLiabilities": {...}
}

But I digress, back to Andreas.

He points out that the context of your problems and the context of someone else’s problems do not overlap as often as we might think.

It’s so unlikely that someone else tried to solve exactly our same problem with exactly our same constraints that [their solution or abstraction] will be the most economical or the best choice for us. It might be ok, but it won’t be the best thing.

So while we immediately jump to tools built by others, the reality is that their tools were built for their problems and therefore won’t overlap with our problems as much or as often as we’re led to believe.

In Andreas’ example, rather than using a third-party library to parse JSON and turn it into something, he writes his own bespoke parser for the problem at hand. His parser ignores a whole swath of abstractions a more generalized parser solves for, and guess what? His is an order of magnitude faster!

Solving problems in the wrong domain and then glueing things together is always much, much worse [in terms of performance] than solving for what you actually need to solve.

It’s fun watching him step through the performance gains as he goes from a generalized solution to one more tailored to his own specific context.

What really resonates in his step-by-step process is how, as problems present themselves, you see how much easier it is to deal with performance issues for stuff you wrote vs. stuff others wrote. Not only that, but you can debug way faster!

(Just think of the last time you tried to debug a file 1) you wrote, vs. 2) one you vendored vs. 3) one you installed deep down in node_modules somewhere.)

Andreas goes from 41MB/s throughput to 1.25GB/s throughput without changing the behavior of the program. He merely removed a bunch of generalized abstractions he wasn’t using and didn’t need.

Surprise, surprise: not doing unnecessary things is faster!

You should always consider the unique context of your situation and weigh trade-offs. A “generic” solution means a solution “not tuned for your use case”.

Reply via: Email · Mastodon · Bluesky

“It’s Just JavaScript!” is probably a phrase you’ve heard before. I’ve used it myself a number of times.

It gets thrown around a lot, often to imply that a particular project is approachable because it can be achieved writing the same, ubiquitous, standardized scripting language we all know and love: JavaScript.

Take what you learned moving pixels around in a browser and apply that same language to running a server and querying a database. You can do both with the same language, It’s Just JavaScript!

But wait, what is JavaScript?

Is any code in a .js file “Just JavaScript”?

Let’s play a little game I shall call: “Is It JavaScript?”

Browser JavaScript

let el = document.querySelector("#root");
window.location = "https://jim-nielsen.com";

That’s DOM stuff, i.e. browser APIs. Is it JavaScript?

“If it runs in the browser, it’s JavaScript” seems like a pretty good rule of thumb. But can you say “It’s Just JavaScript” if it only runs in the browser?

What about the inverse: code that won’t run in the browser but will run elsewhere?

Server JavaScript

const fs = require('fs');
const content = fs.readFileSync('./data.txt', 'utf8');

That will run in Node — or something with Node compatibility, like Deno — but not in the browser.

Is it “Just JavaScript”?

Environment Variables

It’s very possible you’ve seen this in a .js file:

const apiUrl = process.env.API_URL;

But that’s following a Node convention which means that particular .js file probably won’t work as expected in a browser but will on a server.

Is it “Just JavaScript” if executes but will only work as expected with special knowledge of runtime conventions?

JSX

What about this file MyComponent.js

function MyComponent() {
  const handleClick = () => {/* do stuff */}
  return (
    <Button onClick={handleClick}>Click me</Button>
  )
}

That won’t run in a browser. It requires a compilation step to turn it into React.createElement(...) (or maybe even something else) which will run in a browser.

Or wait, that can also run on the server.

So it can run on a server or in the browser, but now requires a compilation step. Is it “Just JavaScript”?

Pragmas

What about this little nugget?

/** @jsx h */
import { h } from "preact";
const HelloWorld = () => <div>Hello</div>;

These are magic comments which affect the interpretation and compilation of JavaScript code (Tom MacWright has an excellent article on the subject).

If code has magic comments that direct how it is compiled and subsequently executed, is it “Just JavaScript”?

TypeScript

What about:

const name: string = "Hello world";

You see it everywhere and it seems almost synonymous with JavaScript, would you consider it “Just JavaScript”?

Imports

It’s very possible you’ve come across a .js file that looks like this at the top.

import icon from './icon.svg';
import data from './data.json';
import styles from './styles.css';
import foo from '~/foo.js';
import foo from 'bar:foo';

But a lot of that syntax is non-standard (I’ve written about this topic previously in more detail) and requires some kind of compilation — is this “Just JavaScript”?

Vanilla

Here’s a .js file:

var foo = 'bar';

I can run it here (in the browser).

I can run it there (on the server).

I can run it anywhere.

It requires no compiler, no magic syntax, no bundler, no transpiler, no runtime-specific syntax. It’ll run the same everywhere.

That seems like it is, in fact, Just JavaScript.

As Always, Context Is Everything

A lot of JavaScript you see every day is non-standard. Even though it might be rather ubiquitous — such as seeing process.env.* — lots of JS code requires you to be “in the know” to understand how it’s actually working because it’s not following any part of the ECMAScript standard.

There are a few vital pieces of context you need in order to understand a .js file, such as:

• Which runtime will this execute in? The browser? Something server-side like Node, Deno, or Bun? Or perhaps something else like Cloudflare Workers?
• What tools are required to compile this code before it can be executed in the runtime? (vite, esbuild, webpack, rollup typescript, etc.)
• What frameworks are implicit in the code? e.g. are there non-standard globals like Deno.* or special keyword exports like export function getServerSideProps(){...}?

When somebody says, “It’s Just JavaScript” what would be more clear is to say “It’s Just JavaScript for…”, e.g.

• It’s just JavaScript for the browser
• It’s just JavaScript for Node
• It’s just JavaScript for Next.js

So what would you call JavaScript that can run in any of the above contexts?

Well, I suppose you would call that “Just JavaScript”.

Reply via: Email · Mastodon · Bluesky