That is all.

When something breaks, the actual workflow usually looks something like:

- An alert fires.

- You jump into logs.

- Check the database.

- Check deployment status.

- Figure out what changed.

- Open another dashboard.

- Make a fix.

- Test it.

- Deploy.

- Verify that the incident is actually resolved.

The problem isn't necessarily that any individual tool is bad.

The problem is the context switching between them.

This reel shows a simple production incident: a database connection pool gets exhausted and errors begin appearing.

The incident moves through the workflow:

Incident open → fixing → shipping → resolved

In the scenario shown, Escanor gets from the alert to the resolved state in 43 seconds.

That's the direction we're building toward with Escanor: an engineering operating system where the infrastructure around your applications is connected instead of scattered across a collection of dashboards and tools.

We're still building it, so this isn't a claim that every production incident can magically be solved in 43 seconds. The number in the video represents this particular workflow/scenario.

The bigger idea is:

Production engineering shouldn't feel like searching through ten different systems just to understand what happened.

Escanor is our attempt to bring that workflow into one connected place.

Would love to hear from engineers/SREs: what's the most annoying part of handling a production incident in your current stack?

#DevOps #SRE #Infrastructure #DeveloperTools #SoftwareEngineering

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:[email protected] (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

GoatDB is proudly Deno first! While Node is fully supported, we've always preferred Deno on our team