For years I worked in Python and dreamed in Haskell on weekends. When I needed
a script, Python. When I wanted the type system to hold me accountable,
Haskell. Somewhere between the two sat TypeScript, and I knew it. Practical
where Haskell is austere, typed where Python isn't. But I kept my distance.
tsconfig.json, .eslintrc, .prettierrc, babel.config.js. Files you have
to create before you've written a single line of actual code. Every time I
thought about trying it, I looked at the list and gave up. The JavaScript
ecosystem always felt to me like an amusement park where you have to wait in a
long queue just to get inside.
Deno dissolved that queue. No configuration files, no node_modules, no
agonizing over which package manager to use. Just deno run main.ts. The first
time I actually wrote TypeScript properly, I couldn't understand why I'd put it
off so long. What I'd been avoiding wasn't TypeScript. It was the ritual
surrounding TypeScript.
What hooked me
At first I couldn't point to one killer feature. The appeal was that everything
seemed to be pulling in the same direction. The fetch() I used in browsers
worked the same way on the server. Web Crypto API was just there. MDN
effectively became Deno's documentation. Instead of installing packages, you
imported ESM by URL, thinking about dependencies in an entirely different way.
Having deno fmt, deno lint, deno test, deno bench, and deno check all
in a single binary was part of the same logic. No installing ESLint, no wiring
up Prettier, no untangling configuration conflicts between the two. That
convenience had an attitude behind it.
The pattern was obvious enough: build on web standards, then ship the boring
tools yourself.
Chasing Node.js
Today's Deno feels like it's drifting away from that.
npm: specifier support, node_modules back in play, node:* module
compatibility. Then in Deno 2.8, deno add without a specifier now adds an npm
package by default. JSR was introduced as an answer to npm's stagnation, as the
future of JavaScript packaging. These decisions make that announcement look
distant. I can understand each one in isolation. Put them together, though, and
the shape is hard to ignore: Deno is spending more and more of its energy
catching up to Node.js.
The OS/2 story comes to mind. IBM expected that building Windows compatibility
into OS/2 would pull Windows users across. What actually happened was the
opposite: developers realized they could target Windows and have it run on both
platforms, so there was no reason to learn the OS/2 API separately. Deno
pushing further toward Node.js compatibility has the same dynamic. The more
compatible Deno becomes, the less reason library authors have to think about it
specifically.
Early Deno set the agenda. Web standards, the permission model, URL imports,
JSR: Deno put these down and the ecosystem responded. What Deno is doing now
runs in the opposite direction, catching up to what the ecosystem already has.
On the defensive
There's a more specific frustration here. Deno had a fight it could have led
rather than chased.
What drove me away from the JavaScript ecosystem wasn't Node.js itself. It was
the full combination: Node.js + npm + TypeScript + Vite + ESLint + Prettier +
Vitest. That stack was the problem, and Deno was already doing well against it.
deno fmt, deno lint, deno test, deno bench, deno check, and in
2.4, deno bundle came back. It had been deprecated once and then
restored; that round trip is its own admission that the direction was right.
The most visible gap that remains is the dev server: HMR, live reload, an asset
pipeline, and the plugin ecosystem that accumulates on top of all that.
Fresh 2.0, Deno's own framework, chose not to fill that gap from within Deno and adopted Vite instead.
That disappointed me. Making Vite run well on Deno and making Deno a
self-sufficient development environment are two entirely different directions.
Once your own framework makes that choice, you can't expect the wider ecosystem
to go the other way.
But vertical integration alone might not have been enough. Individual component
quality matters too. If deno lint and deno fmt were clearly better than
ESLint and Prettier, developers would reach for them even in Node.js projects.
That could have been the Trojan horse. Once enough projects are using Deno's
tools without using the Deno runtime, the next question follows naturally.
ESLint and Prettier seemed unmovable, and yet Biome and the Ox series (Oxlint,
Oxfmt) are finding their footing. The market was always there. Better tools
just weren't. Deno could have gotten there first.
The clock I keep thinking about
Why didn't Deno hold the course? This is speculation, but here's my read.
The integrated toolchain path required patience. Getting developers to feel the
pain of configuration complexity, making Deno the place they move to, waiting
for the ecosystem to grow comfortable with Deno's way of doing things. All of
that takes time. Node.js is a community project under the OpenJS Foundation.
There's no investor clock pushing it, and the project doesn't wobble if the
ecosystem moves slowly.
Deno Land Inc. is different. A VC-backed company has a clock. How long that
clock allows for a patient fight is not the same as what a community project
can afford. Expanding Node.js compatibility produces visible results faster
than the slow alternative. From the outside, I can't tell when I'm seeing a
product decision and when I'm seeing a runway decision. What I can say is that
the urgency Deno has been showing doesn't sit well with the direction it
originally chose.
Even so
For all my griping, I still build most of my own libraries Deno-first. I
publish to JSR even when I also publish to npm. I try to depend only on web
standard APIs, and I use Deno's built-in tools for linting and formatting. I'm
still rooting for Deno.
But even I have retreated in places. I now rely on node:test and
node:assert/strict for testing, because it's the easiest way
to run the same tests across Deno, Node.js, and Bun without any special
dependencies. JSR was launched as an answer to npm's stagnation, and I've
started to feel JSR stagnating too. I often catch myself wondering whether to
drop it. I got excited about Deno KV and now I just use node:sqlite, which
runs fine on Deno anyway.
If someone like me is already making these retreats, I wonder what Deno looks
like to someone with no attachment to it at all. That worries me, because I
still want Deno to win some version of this fight. I'm just less sure lately
that Deno wants to win the same fight I signed up for.
Git GUI displaying a commit graph with branching and merge history, branch and tag labels, and a detailed view of the selected commit with file changes in light mode
ALT text
Git GUI displaying a commit graph with branching and merge history, branch and tag labels, and a detailed view of the selected commit with file changes in dark mode
聯合宇宙 처음 始作한 건 아마 2017年頃? 트剩餘에 計定 만들었다가 잘 適應 못 하고, mastodon.social로 갔던 것 같다. 그 뒤로 國漢文으로 글 쓰는데 사람들이 읽기 不便하다고 하니까 國漢文에 自動으로 <ruby>로 한글 讀音 붙게 하는 機能이 必要해서 直接 ActivityPub 소프트웨어 具顯할 생각을 했고… 그 뒤로는…
聯合宇宙 처음 始作한 건 아마 2017年頃? 트剩餘에 計定 만들었다가 잘 適應 못 하고, mastodon.social로 갔던 것 같다. 그 뒤로 國漢文으로 글 쓰는데 사람들이 읽기 不便하다고 하니까 國漢文에 自動으로 <ruby>로 한글 讀音 붙게 하는 機能이 必要해서 直接 ActivityPub 소프트웨어 具顯할 생각을 했고… 그 뒤로는…
There's a Matrix room for #Fedify contributors, open to anyone curious about how development happens. Feel free to drop in or lurk; small questions are fine too.
Are there any F/OSS alternatives to issue trackers like JIRA or Linear? I'd like something that's easy to use and works well for both engineering and non-engineering teams.
Due to recent regulation changes (전기통신사업법), the South Korean government is requiring internet communities and forum owners to scan every user uploaded images and videos on their website, by AI.The hardware to run these AI models are also not provided by government, website owners have to buy datacenter grade Nvidia GPUs by themselves, putting financial pressure to small businesses and forums.
Websites will need to implement these hardware and software features, starting immediately from July 1st, which is just next month.
Here is the original image provided from Korean government, specifying the hardware requirements for AI models. I also added English translated image, made with nano banana (sorry for using ai for this...)
Small fedi badge update: the service has moved to a new domain. Please update your badges to use fedi-badge.minhee.org instead of fedi-badge.deno.dev. The old domain will stop working in July.
I also shipped a couple of related changes. Badges can now show the logo of the software an instance is running, like Mastodon, Misskey, Pleroma, and a few others, detected via NodeInfo. If the software isn't recognized, it falls back to the generic fediverse logo.
The service also moved from Deno Deploy Classic, which is sunsetting, to Cloudflare Workers.
ALT text
Various types of fedi badges. New fedi badges have their software logos too.
Small fedi badge update: the service has moved to a new domain. Please update your badges to use fedi-badge.minhee.org instead of fedi-badge.deno.dev. The old domain will stop working in July.
I also shipped a couple of related changes. Badges can now show the logo of the software an instance is running, like Mastodon, Misskey, Pleroma, and a few others, detected via NodeInfo. If the software isn't recognized, it falls back to the generic fediverse logo.
The service also moved from Deno Deploy Classic, which is sunsetting, to Cloudflare Workers.
ALT text
Various types of fedi badges. New fedi badges have their software logos too.
The software is built with @fedify and uses Nuxt for the server and server-side rendering. This is my first bigger Fedify project, so I'm looking for improvements and best practices. The Fediverse data structure is built on top of: https://codeberg.org/fediverse/fep/src/branch/main/fep/0837/fep-0837.md. From the data point of view, this includes the proposal and resourceConformsTo field, which links to an URI. Like: https://mensa.mahlzeitheute.de/users/fl-ca1/menu-items/currywurst-currysosse-und-pommes. Behind this is a JSON LD with a description of the food. As someone who is gluten intolerant, the allergen information is quite relevant and interesting. I'm not sure if this is the best way, and I'm interested what others would do. [2/4]
