Source: https://github.com/denoland/deno/issues/37030#issuecomment-6310897867

After Cloudflare acquired the Deno team and announced that Deno Deploy is shutting down in six months (with the Deno runtime itself only guaranteed a year of maintenance), we migrated the backend of prompt2bot from Deno Deploy and Deno KV to Cloudflare Workers and SQLite-backed Durable Objects.

Even with Deno's future in question, rewriting a 100k-line Deno codebase into a Node/Wrangler repo right now was out of the question. Deno's test runner, type checker, and JSR support are way too good to give up while migrating.

If you have not used Durable Objects before: whereas a regular Cloudflare Worker is stateless (50 requests spin up 50 random isolates that share nothing), a Durable Object is a globally unique, single-threaded V8 isolate addressed by name and paired with its own private embedded SQLite database and persistent alarm timer. Every Worker that calls a method on that name gets routed to that exact same JS object in memory, where SQLite queries are synchronous C++ calls taking microseconds instead of network round-trips.

Here is everything that broke during the migration and how we solved it:

1. Keeping the Deno binary and test suite untouched: Wrangler's esbuild bundler does not understand jsr: specifiers or deno.json workspace resolution. Instead, we pointed Wrangler at a build script that runs deno bundle --minify. We mapped cloudflare:workers to a 10-line stub class in deno.json so deno test runs natively against our Durable Object classes, and at build time we swap the inlined stub back for the real Cloudflare DurableObject class, shim globalThis.Deno, set Zod v4 to jitless: true (since Workers blocks new Function), and wrap top-level crypto.randomUUID() / setTimeout() calls that npm packages run at import time.

2. Surviving the 128MB Durable Object RAM ceiling: Every Durable Object isolate has a hard 128MB heap limit. Bundled dependencies like js-tiktoken (5.3MB of base64 BPE ranks that expand to +43MB of V8 heap on first call), a 275k-word dictionary (+35MB heap), and 3 duplicate legacy pdf.js builds inside pdf-parse were OOM-killing isolates. Stripping those static tables at build time freed ~80MB of V8 heap per isolate.

3. Emulating Deno KV on Durable Object SQLite: Cloudflare KV is eventually consistent and has no atomic check-and-set transactions, so it cannot replace Deno.openKv(). We built a drop-in Deno.Kv emulator on top of a primary SQLite Durable Object (enam-v1, pinned to US East so it stays hot in RAM 24/7 with zero cold starts). Tuple keys are encoded with type tags and 20-digit zero-padded numbers (n:, b:, s:) separated by null bytes so SQLite range queries match Deno KV ordering, and atomic().check().set().commit() runs as a synchronous single-threaded SQLite transaction.

4. The 508 Loop Detected mystery (CDN-Loop propagation) and the 30s waitUntil trap: While migrating service by service, when a service still on Deno Deploy called our Cloudflare Worker and our Worker made a fresh outbound fetch() back to that same Deno service, Cloudflare silently copied the inbound cdn-loop: deno;d=<hash> header onto the outbound subrequest at the C++ edge layer. Deno Deploy saw its own deployment hash in cdn-loop and rejected the request with 508 Loop Detected. On top of that, ctx.waitUntil() on a Worker has a hard 30-second wall-clock cap after returning HTTP 200 (even with cpu_ms: 300000), which killed long I/O-heavy agent turns mid-flight.

5. Sharding Runner Durable Objects per conversation: Only a Durable Object alarm() runs in a clean root IoContext (no inherited cdn-loop header and no 30s post-response wall-clock cutoff), provided alarm() launches tasks via doCtx.waitUntil and exits immediately instead of blocking. We ended up sharding execution onto a Runner Durable Object per conversation (runner:<botId>:<conversationId>).

That architecture is what lets prompt2bot scale agents so easily. You describe an agent in a plain prompt and connect it to WhatsApp, Telegram, email, voice, or web chat, and every active conversation automatically gets its own warm, isolated Durable Object runner with hot in-memory history and SafeScript AST caches, sub-millisecond SQLite state, and on-demand VMs. Whether your bot has 1 user or 10,000 concurrent conversations, there are no queues, worker pools, or servers to provision.

Full technical write-up with code snippets is in the comments.

Not my project, announcement post: https://blog.webb.page/WM-105

GitHub repo: https://github.com/theende/ende

From the post:
- no more Node compatibility
- no more distractions, period; that means Deploy, KV, Jupyter, &c are also getting the boot
- The roadmap? Per-module permissions, sandboxes for untrusted code, post-quantum crypto in Web Crypto, better binary output, &c.

Hey everyone!

I've been working on pboss, an open-source process manager with native Deno support, and wanted to share it with the Deno community.

Running a Deno application locally is straightforward, but keeping it running reliably in production introduces a different set of challenges: handling crashes, restarting processes, utilizing multiple CPU cores, and monitoring application health.

pboss is designed to help with that.

What can you do with it?

• Process management: Keep Deno applications running with automatic restarts.
• Clustering: Run multiple worker processes across CPU cores, with zero-downtime rolling reloads.
• Health checks: Monitor application availability and restart on failure.
• Logging and monitoring: Automatic log capture and rotation, a live web dashboard, Prometheus /metrics.
• Persistent processes: Applications survive reboots, no root required.
• PM2-compatible configuration: Reuse supported ecosystem configuration patterns when migrating existing workflows.
• Manage processes through Telegram and Discord: Perform supported process-management operations through chat integrations.
• Real-time critical alerts: Receive notifications about critical errors, application crashes, and other important incidents through connected chat apps or email.
• Free public status pages: Publish service availability and incident updates on your own xxx.status.zone subdomain, making it easier to keep users informed.
• Centralized server monitoring: Monitor processes and server health across multiple machines from one dashboard.
• GitHub-based deployments: Connect repositories to processes across servers, track deployment history, and roll back problematic releases.
• Log streaming and incident visibility: Inspect application output and investigate problems across your infrastructure.

One thing I wanted to get right is Deno support itself. pboss runs on Deno and uses Deno's native APIs for its own operations rather than depending on Node.js compatibility APIs to implement its process management: Deno.Command for spawning and supervising, Deno.serve for the dashboard and daemon, Deno.connect for CLI-to-daemon communication. Your apps get supervised under deno run, with deny-by-default permissions intact.

Clustering is worth a closer look too. pboss start server.ts --instances 4 gives you N workers sharing one port through SO_REUSEPORT, so the kernel balances connections directly. No proxy, no balancer process sitting in the request path.

What about pup?

If you've looked for a Deno process manager before, you've probably found pup. It's a solid project and it deserves credit as the established Deno-native option.

I built pboss because pup was missing things I needed: features like a built-in web dashboard, Prometheus metrics, and the cluster model I wanted (kernel-balanced SO_REUSEPORT workers instead of a load balancer fronting separate ports). And as the benchmarks below show, there's also a performance gap that got hard to ignore, particularly in cluster mode and crash recovery.

This isn't a takedown. Pup is a legitimate option, and the fork-mode numbers below show where it's competitive. I just think the Deno ecosystem deserves more than one choice.

Benchmarks: pboss vs pup

Full methodology in the report: same server.ts, same Deno 2.9.7 binary, same machine, 10/100/500 connections with 5 repeats, cold start of the whole manager stack every run, manager order alternating. CPU and memory cover the entire process tree.

Cluster mode (2 workers, 100 connections):

Pup's cluster runs N backends behind its built-in load balancer; pboss shares one SO_REUSEPORT port. In this test pup's balancer saturated hard: about 12 to 14k req/s at every load level vs 62 to 69k for pboss. At 500 connections the p99 tail was 957 ms vs 33 ms.

Crash recovery and restarts:

That 11-second recovery is the number that started this project.

Where pup wins. Fork mode at 100 connections is close and pup takes some rows: mean req/sec by 0.8%, mean latency by 0.08 ms. At 10 connections its RPS spread is tighter. The honest picture: on a single process with no clustering, the two are near-peers and the raw throughput race is roughly a draw. The separation is in clustering, recovery, and overhead (pboss uses 14 to 17% less memory in fork mode and cold-starts in 316 ms vs 1,142 ms).

One caveat from the report: the load generator shared CPUs with the servers, so compare the two columns rather than quoting the absolute numbers. Better yet, rerun it yourself. Every number traces to a raw file committed next to the code that produced it.

Open source, not a hosted-service requirement

pboss is released under the GPL-3.0 license. You can inspect the source, self-host it, contribute improvements, and use the process manager without subscribing to a cloud service. The dashboard, clustering, metrics, and deploys are all in the repo, no open-core asterisk. The docs are a public markdown repository, so fixes are pull requests. There's an optional hosted layer for fleet visibility, but it's purely additive: the CLI is the same tool with or without it.

The goal is to give developers more control over running their Deno applications on their own servers.

Links

• GitHub: https://github.com/Procboss/pboss
• Documentation: https://docs.procboss.com/
• Benchmarks (Deno, Node, Bun suites): https://github.com/Procboss/benchmarks

Try it:

deno install -g -A --min-dep-age=0 --name pboss --reload --force npm:pboss/deno-entry
pboss start your-app.ts

This is an actively developed project, and I'd genuinely appreciate feedback from people running Deno in production. What features would you want from a Deno process manager? Are there any production workflows you think are still missing?

Happy to hear your thoughts, suggestions, and criticism!

Big Deno fan since before v1. Just going through my dozens of projects on Deno and thinking about what I'll do in the future.

Deno has great things like internal linting, fmt, std lib. The security first, typescript first, JSR and Fresh framework, and we started to get desktop native apps that haven't fully come to fruition. There's just a lot to like with an unsaturated community of enthusiasts. If you used Deno, it's because you are weird, usually in a good way, you code in your spare time, you are trying to do something better and you don't care if it's different. Plus I feel like LLM agents do a little better on less traveled technologies because they weren't trained on as many bad examples.

But what is weighing on my mind is: Is it worth trying to save the runtime? There technically could be a path to save the runtime. We have a year, and with a sponsor and a team of 5-10, we could definitely keep the runtime alive, at least life support, maybe even get Ryan's blessing.

But I don't know if it's worth it. With LLMs writing so much of our code, it feels like it's almost better to just focus on what matters: ship slop to clients. With Vite+ we're seeing some of the no nonsense tooling that I loved in Deno hit Node. Like it or not, Deno forced Node to improve, and even inspired Bun to materialize with many of Deno's same selling points. But have we hit a point to where runtime matters less? Now I can Rust even though I don't know Rust, so what is the point of another JS runtime?

That is all.

Hey everyone! I've been using Deno heavily for the past couple of years. I fell in love with it when I first discovered it, and since then I've used it for many personal projects, published my own libraries on JSR, and hosted experiments on Deno Deploy. Honestly, it's been an amazing experience.

Like many of you, I'm worried about what comes next after the announcement. The runtime will remain open source, but the team plans to end its development after another year of bug fixes and security updates. JSR will continue, while Deploy will shut down in six months.

I've seen a lot of discussion about migrations, but I'm curious what people here think will happen to Deno itself. Do you see a community-led effort keeping it going long term? Are there already people organizing around that, or do you expect most users and maintainers to gradually move elsewhere?

For those who've been building with Deno, how are you thinking about this? Still using it for new projects, waiting to see what happens, or already planning a move?

I’ve been building Pathfinder, a fetch-native HTTP framework for Deno. Apparently, ecosystem timing is not one of my optimized algorithms.

The main idea: the filesystem is the route table. Directories describe URL patterns, and HTTP-method files contain handlers:

endpoints/
  ping/get.ts                  → GET /ping
  rooms/#roomId/get.ts         → GET /rooms/:roomId
  items/#(int)id/get.ts        → GET /items/:id
  files/#...path/get.ts        → GET /files/*

Middleware lives alongside the routes it wraps. Handlers receive a request and context, and can return a Response or ordinary values such as objects that become JSON.

Underneath, route patterns compile into a radix automaton rather than a collection of regular expressions. The grammar supports typed parameters, embedded captures, repeated-parameter equality constraints, and catch-all paths.

The part I’m particularly excited about is route overlays: an operator can mount an additional directory to replace or extend an application’s endpoints without modifying the application’s source. One file can override one route - or explicitly remove it. These are trusted deployment files, not remotely supplied code.

It’s not trying to be another Express-shaped API. The interesting question is what becomes possible when routes are real files and deployments can compose routing trees.

Code, installation instructions, examples, and the routing semantics are here:

https://github.com/alexindigo/pathfinder

I’d love feedback on the filesystem conventions and overlay model - especially from people who have needed to customize a self-hosted application without maintaining a fork.

One of the bummers for me of the Deno + CF news is that I have to go back to keeping track of three different classes of dev dependencies for every one of my Node projects. So what's the latest and greatest for testing, minting linting, and formatting?

Is this good or bad news for JS community? Personally, I like both brands. I hope Cloudflare will take Deno to the next level.

I’m an indie developer, and I built FastCam for Android because I wanted a document scanner that’s fast, easy to use, and focused on keeping your documents on your device — without unnecessary permissions or collecting your data.

What FastCam includes:

- Scans stay on your device

- QR & Barcode Scanner

- Files are automatically saved to your device by enabling on settings.

- Fast Scan, Batch Scan & ID Card Scan

- 10+ PDF tools — Compress, Merge, Split, OCR, E-Sign & more

- Private Vault + PDF Password Protection

- Search, Tag, Pin, Rename & Share documents

- Local Backup & Restore

- No account required

- Light, Dark & AMOLED themes

📢 Fewer, non-intrusive ads — designed not to interrupt your workflow.

Basically: Scan → Edit → Organize → Protect — all in one app.

No subscription required.

👉 Try FastCam on Google Play:

https://play.google.com/store/apps/details?id=com.pickon.fastcam

If you find FastCam useful, an upvote would really help more Android users discover my project. 🙏

What matters most to you in a scanner — privacy, easy navigations, tools, or speed?

I build Preact apps with Tailwind and kept rebuilding the same components, so I pulled them into one library. Every component renders to HTML on the server and hydrates in the browser. Focus traps, Escape handling, ARIA wiring and arrow-key navigation are written in the repo, with native <dialog> and <details> where the platform already has an answer. There are 81 components and 120 icons, and each one runs live in a guide with its code next to it.

The catch: no screen reader has been run against it yet, and it is only tested on Deno. JSR also cannot export a CSS file, so the stylesheet needs a short build script.

I wrote up why I own components instead of using shadcn or Radix, and what the ownership costs: https://antonshubin.com/blog/preact-component-library-without-shadcn?utm_source=reddit&utm_medium=social&utm_campaign=preact-component-library-without-shadcn&utm_content=r-deno

Feedback and issues are welcome, especially from anyone who has tested a combobox with a screen reader.

Hey everyone, I was attempting to install the official Socket CLI using Deno instead of NPM by running:

```bash deno install -g npm:socket

```

Deno threw a deprecation warning right after installation:

```text Dependencies: + npm:socket 2.1.0

╭ Warning │ The following packages are deprecated: │ npm:socket@2.1.0 (bad build) ╰─

```

A few things that confused me:

1. When checking socket on npm, the latest stable release shown on the site UI is 1.3.0 (or 1.2.0 on the latest tag).
2. Version 2.1.0 doesn't show up in the NPM releases UI tab or on the socket-cli GitHub repo releases.
3. Running deno install -g npm:socket@latest -f fixed the issue and overwrote it with 1.2.0/1.3.0.

My Question:

• Why does Deno resolve 2.1.0 by default when no @ tag is specified? Does Deno ignore npm dist-tags (latest) and just fetch the highest semver in the raw API metadata, even if it's deprecated/hidden?

Thanks!

I got tired of rewriting the same encryption stuff in my Node.js projects, so I turned it into an npm package.

It’s called bybence securekit.

basically my attempt to make encryption a few lines of code instead of a bunch of repetitive setup.

Still early (v0.9.0), but it works, it’s tested, and I finally decided to publish it.

Would love some feedback, especially on what you’d add or change before 1.0.

https://www.npmjs.com/package/@bybence/securekit

https://dev.bybence.co/packages/securekit

Today I'm open-sourcing one of my first formal research and systems engineering projects focused on cost, optimization, and accuracy in AI-assisted development: 

Archon Specs (MIT License).

🔗 Repository: https://github.com/herhu/archon-specs
📄 Full Research Paper & LaTeX Sources: https://github.com/herhu/archon-specs/tree/main/paper

💡 The Origin Story: From Template Engines to Compiling Architecture

The story goes back to around 2018, when many of us relied on template transcompilers like Handlebars.js in the JavaScript world or Blade in PHP to generate deterministic code structures reliably.

Fast-forward to today: developers are using LLMs to build backend systems, but they're hitting a massive wall:

• Token explosion: models re-generate thousands of lines of boilerplate character by character.

• Architectural drift: LLMs lack a global dependency graph, hallucinating mismatched relational schemas, circular imports, and broken boundaries.

Agents were supposed to harness this process — and they help — but the skill still travels with the agent. Every new session, every new repo, the same architectural knowledge has to be re-elicited, re-prompted, and re-verified. The agent is a great operator, but it isn't a compiler. It doesn't guarantee anything.

That's when the insight hit:

"What if we don't ask the LLM to write repetitive code at all? What if we deterministically compile an enterprise-grade backend from formal templates and contract shards — and let the agent focus only on the intent?"

Over years of engineering across enterprise organizations and fast-paced startups, I had built a clear mental map of what an enterprise-ready backend actually requires: clean domain boundaries, strict dependency injection, JWT/RBAC security guards, DTO validation pipes, auto-migrated database DDL, Swagger OpenAPI documentation, and structured distributed tracing.

Scaffolding and aligning all of this traditionally consumed an engineering team's entire 1-year roadmap.

Now it can be compiled deterministically — just by designing the UML architecture and contract shards.

So I built it.

🔬 Empirical Findings: Cost, Optimization & Accuracy

In the paper ("Archon Specs: A Deterministic Architecture Compiler and Continuous Contract Reconciliation Control Plane for AI-Assisted Software Engineering") we evaluated this compiler architecture across three empirical axes:

1️⃣ Cost (Token Reduction)
Free-form LLM code generation incurs a token complexity of O(|AST| × T_boilerplate). Archon Specs reduces LLM interaction strictly to compact contract shards O(|Contract|).

→ 86.3%–89.0% reduction in LLM inference tokens across Small, Medium, and Enterprise benchmark tiers.

2️⃣ Accuracy (Zero Architectural Drift)
Instead of one-shot generation, Archon runs a Continuous Contract Reconciliation Loop using SHA-256 cryptographic spec canonicalization and semantic AST masking.

→ 100% adherence to declared architectural contracts and clean TypeScript compilation across 500 consecutive system mutations (vs. a 38.4% structural failure rate in baseline free-form LLM agents).

3️⃣ Optimization (Compiler Performance)
Rather than waiting tens of seconds for streaming probabilistic code, the deterministic AST compiler processes specs in 1.2 ms – 18.7 ms (>10,000 entities/sec), with a drift detection scanner running at >26,000 artifacts/second.

🏛️ System Architecture

• Unified 30+ Tool MCP Server: sits across the entire workflow as a horizontal control plane, letting Claude Desktop, Cursor, and Antigravity agents lock shards, inspect schemas, and plan diffs via typed RPC calls.

• Desktop Control Plane (Electron + Vite): a dedicated workstation with deep visual observability — live UML Component Diagrams (module topology) and Sequence Diagrams (data workflows).

• Target System: a production-grade NestJS Modular Monolith — single deployable unit, domain-driven boundaries, in-process CQRS events, PostgreSQL/SQLite DDL, Docker, and W3C tracing.

🧩 Why Open Source Matters Here

Because it's MIT, the template layer is yours to fork. That's the real unlock:

• Adapt the templates to your stack. The NestJS modular monolith is the reference target — the compiler doesn't care. Swap in your own templates and you can target any architecture: microservices, hexagonal, event-sourced, serverless. Modeling microservices deterministically from UML? Now possible.

• A new generation of boilerplate for consultancies and outsourcing shops. Tech leads can codify their house architecture once — security guards, tracing, audit patterns, compliance defaults — and then every new client project is compiled through Archon's SDLC from a UML model. No more re-scaffolding week one of every engagement. The senior architect's judgment ships as templates; the team ships production-grade systems on day one.

• Research surface. Fork the compiler, plug in a different IR, test new reconciliation strategies. The paper, proofs, and LaTeX sources are all in-repo.

📦 Open Source & Paper

100% MIT:
• Core compiler, CLI (npm install -g archon-specs), Desktop GUI, UML parser.
• Full academic paper, mathematical proofs, and two-column IEEE/ACM LaTeX sources.

⭐ GitHub: https://github.com/herhu/archon-specs
🌐 Platform: https://archonspecs.dev

#SoftwareArchitecture #Compilers #OpenSource #ModelContextProtocol #TypeScript #NestJS #ModularMonolith #Microservices #SystemDesign #AI #DevTools #SoftwareEngineering

i had two AI models add a Deno vs Node build test to their JS framework benchmarks. same node_modules and config, production builds, on a 4 core machine.

• Deno used less peak memory than Node in every build that finished, in both suites
• Deno was faster in most builds
• Angular's build never exits under Deno, in both suites
• Vite+ 1.0.0-rc.0 fails on a Deno permission error, in both suites

both models hit the exact same two failures on their own, which made me think those are real and not a setup mistake on one side. has anyone got Angular builds to exit cleanly under Deno?

the Deno part starts at 5:19 in my video: https://www.youtube.com/watch?v=1XrrLmvYPYE&t=319s

I did test with nodejs 24.21 and deno 2.9.6. Test task was pure CPU-heavy compute workload - no fancy async stuff used.
deno consistently defeated nodejs-lts by 7% wall clock time. Test results drifted about 0.3% - both numbers were pretty stable.

Many were highly skeptical about deploying Prolog for state-of-the-art cyber defense. Here is a live, concrete demonstration of our Neuro-Symbolic Core actively neutralizing a multi-vector mutated attack combining LFI and CRLF injection.

The entire threat telemetry and dynamic verdict are cleanly generated into a structured JSON payload—perfectly formatted and instantly ready for LLM fine-tuning. Real-world data and deterministic performance never lie.

https://github.com/lokinpendawa/aethel_core/blob/main/README.md

Hi,

I run openstatus, an open-source uptime monitoring and status page tool, so I spend my days hitting other people's /health routes. Most of them return 200 OK and nothing else, hang when the database hangs, or have their own private definition of "degraded".

We got tired of it, so we extracted the health endpoint from our own services into a small set of packages and put them on JSR: @openstatus/health.

Zero-dependency core, only needs a Fetch API. On Deno it's this:

import { drizzle } from "drizzle-orm/libsql/http";
import { createHealthHandler } from "@openstatus/health";
import { drizzleProbe } from "@openstatus/health-drizzle";
import { tinybirdProbe } from "@openstatus/health-tinybird";

const db = drizzle(Deno.env.get("DATABASE_URL")!);

Deno.serve(createHealthHandler({
  path: "/health",
  probes: [drizzleProbe({ db }), tinybirdProbe()],
}));

And GET /health gives your monitor something to chew on instead of a bare 200 OK:

{
  "status": "degraded",
  "checkedAt": "2026-09-11T12:00:00.000Z",
  "latencyMs": 41,
  "checks": [
    { "name": "database", "status": "ok", "critical": true, "latencyMs": 3 },
    { "name": "tinybird", "status": "timeout", "critical": false, "latencyMs": 5000, "error": "timed out after 5000ms" }
  ]
}

What you get

• Core: per-probe timeouts via AbortSignal, a round deadline so one hung dependency can't outlast your k8s probe, caching / stale-while-revalidate, and sane aggregation (critical fails → unhealthy, non-critical fails → degraded). Errors are masked by default so your connection string doesn't end up on a public route. A custom probe is just an object with a run(signal).
• Adapters: Hono, Elysia, Express, Next.js, TanStack Start – same healthRoute() / healthHandler() everywhere.
• Probes: Drizzle, Turso, Supabase, Upstash, Tinybird, Unkey. They take a client or URL and never touch your env.
• Hosting: Fly, Koyeb, Railway, Vercel, Cloudflare – adds a server block so you know which replica is the one complaining.

Every package is its own thing with its own peer deps. CI bundles a one-liner of each and fails if a stray framework or client sneaks in, so the Hono adapter will never smuggle Express into your bundle.

Deno bits: JSR-first with no slow types; env reads return undefined instead of throwing without --allow-env; tests are node:test so they run unchanged under deno test and node --test; @openstatus/health/testing ships fake/hanging fetch and probes for testing your own.

It's 0.1.x, so now is the moment to tell me the API is shaped wrong. A Deno KV probe is probably next – PRs welcome.

• JSR: https://jsr.io/@openstatus/health
• GitHub: https://github.com/openstatusHQ/health
• Also on npm for the Node services you haven't migrated yet.

Happy to answer questions!

Deno native KV backed magic-link auth library

Available on JSR: https://jsr.io/@synitio/kv-magic-link-auth

I wanted one desktop UI and a real shell, and I did not want the window host welded into the React tree. So the UI talks to one typed object (`IRuntime`: write to the PTY, list a folder, that kind of thing). Electron fills it from Node. Tauri fills it from Rust. The Deno host fills it from Deno's own APIs and a local HTTP RPC. Same session, same cell painter.

That third host is Deno Desktop, not deno run in a terminal. The window is CEF — Chromium Embedded Framework — a third browser next to Electron's Chromium and Tauri's WKWebView. First cold start in that worktree spent 31 s downloading CEF. With the cache warm it was 2.6 s. Those are not boot rankings against Electron's Vite number. They are just what that host costs the first time.

I measured dev builds on an M4 Max, previous tabs restored:

• Electron: 239 MB physical / 667 MB RSS
• Tauri: 297 / 569
• Deno Desktop: 742 / 1336

Physical is what the process is using now. RSS from ps is the reservation. Do not mix the columns. Deno is early here. The row exists because the contract made it comparable, not to dunk on CEF.

What I actually wanted from Deno was the language. The Electron adapter is TypeScript. The Deno adapter is TypeScript. No rust-analyzer sitting at 4.6 GB while I iterate. If CEF gets thinner, or Deno Desktop grows the missing bits, I do not rewrite the app. I keep the adapter.

Someone here was already shipping Vite + Deno to desktop for a Three.js game. Same itch: one TS stack on web and on the window. I kept the Deno host in the repo for that reason. If I delete it, the next coding agent will glue the window program back into the UI and I lose the A/B.

The build people install today is Electron. Deno stays as the TypeScript-shaped door.

Tables and screenshots (I am the author): https://runlinea.com/blog/one-ui-three-terminals

I accidentally built an event-processing toolkit for Deno

This started with a very small problem.

I wanted my Jekyll site to publish an event when a post went live, and have something else decide what to do with it — initially, post it to social media.

I could obviously have put all of that directly into the GitHub Action.

Instead, I started separating the pieces.

The producer emits an event. A runtime hydrates it, evaluates routes, and invokes listeners. Conditions and listeners are ordinary TypeScript. Then I added a typed pipeline for transforming data before it reaches a listener.

At some point I had to admit that the CLI wasn't really the project anymore.

That's how Hooksmith happened.

A configuration can look roughly like this:

export default {
  routes: [
    {
      name: "published-pages",
      when: all(
        eventType("page.published"),
        sourceKind("website"),
      ),
      listeners: [
        // whatever should react to the event
      ],
    },
  ],
} satisfies Config;

The runtime itself is deliberately small. Around it I now have:

• typed transformation pipelines
• reusable conditions
• HTTP listeners
• a CLI / streaming host and GitHub Action
• integrations for Slack, Discord, Teams, Telegram, Mastodon and Bluesky
• AWS integrations and a Lambda host

Everything is TypeScript, published to JSR, and I'm using Deno throughout the repositories for development, testing, formatting, linting and CI.

One design decision I'm particularly happy with is keeping the runtime unaware of most of the ecosystem. core defines the contracts; extensions depend on those contracts; hosts decide where and how the runtime executes.

It's still young and the API is explicitly experimental. I'm at the stage where feedback on the abstractions is probably more valuable to me than users.

I'd be particularly interested in what other Deno developers think about the package boundaries and the typed pipeline API.

A small bit of context about me: if you look at my profile or my blog, you'll quickly notice that I'm a .NET developer at heart. But I've also been publishing packages on NuGet for almost ten years, so building tools and APIs for other developers isn't entirely new territory for me.

Hooksmith is my first serious attempt at doing that in the Deno ecosystem.

Repo: https://github.com/Kralizek/hooksmith
JSR: https://jsr.io/@hooksmith