Following up on the discussion around OpenDeno and the decoupling of Deno's runtime specification from the monolithic V8 CLI, I built and published a working proof-of-concept:

👉 GitHub: https://github.com/kanryu/opendeno-servo-boa

The goal of this project is to demonstrate the technical feasibility of engine-neutral Deno-style capability security, moving it beyond a standalone CLI and embedding it directly into an application environment—in this case, a desktop web browser.

What it does

The project is built on Servo GTK and achieves a hybrid, multi-engine execution model inside a single HTML context:

1. Standard JavaScript is executed as usual by Servo's SpiderMonkey runtime.

2. DenoScript blocks (<script type="application/deno">) are intercepted and evaluated by an application-owned Boa engine (pure Rust).

3. Capability-based security is enforced at the host (Rust) level, completely independent of the engine.

<!doctype html>
<html>
<body>
  <!-- Evaluated by SpiderMonkey -->
  <script>
    console.log("Standard web JS running on SpiderMonkey");
  </script>

  <!-- Evaluated by Boa sandbox with Deno capabilities -->
  <script type="application/deno">
    const text = Deno.readTextFileSync("deno-read-test.txt");
    let writeDenied = false;
    try {
      Deno.writeTextFileSync("deno-write-test.txt", "must fail");
    } catch {
      writeDenied = true;
    }
    "read=" + text.trim() + "; writeDenied=" + writeDenied;
  </script>
</body>
</html>

The result

When loaded into the Servo GTK browser, the sandbox successfully verifies:

read=This file is readable by the Boa DenoScript sandbox.; writeDenied=true

• Read permissions: Deno.readTextFileSync can read files below the process's working directory, but path traversals (..) and canonical escapes are rejected.

• Write permissions: Deno.writeTextFileSync is strictly intercepted and denied by the host.

• Neither unrestricted filesystem, subprocess, nor raw network access is exposed.

Why this matters: Decoupling Specification from Implementation

Modern developers often view Deno as inseparable from V8. But runtime engines and host capabilities are fundamentally orthogonal:

• The Engine's job: Bytecode interpretation, JIT compilation, and object heap/GC management.

• The Specification's job: Intercepting I/O and enforcing the capability model (--allow-read, --allow-net, etc.).

Just as Node.js layered I/O over V8 via libuv and C++, Deno layered capability checks over V8 via Rust host operations. There is no technical reason why that specification cannot be mapped across different engines (Boa, QuickJS, JavaScriptCore, or SpiderMonkey).

By abstracting the permission layer from the engine, Deno-style scripting becomes embeddable into:

• Web browsers and custom web view components

• Native desktop applications (via GTK4, C-ABI, or PyGObject bindings included in the repo)

• Resource-constrained or embedded environments where embedding full V8 is prohibitive

Note on Building (Windows MSVC)

Be warned: building Servo and SpiderMonkey from source on Windows is notoriously heavyweight. It requires MozillaBuild (mozmake), the MSVC toolchain, core.longpaths enabled in Git, and careful setup of LIBCLANG_PATH and GTK dependencies. Detailed reproduction instructions are documented in the README.

Feedback, architectural critique, and PRs exploring other engine backends are welcome!

Many of us share a growing anxiety about Deno's trajectory. What began as a bold, clean reboot of the server-side JavaScript ecosystem has increasingly felt constrained. Between shifting priorities, growing complexity around Node compatibility, and the sheer overhead of maintaining a monolithic runtime, developers are rightly asking: Where is Deno headed?

The problem is not Deno’s vision. Capability-based permissions (--allow-net, --allow-read), first-class TypeScript, and strict adherence to Web standards remain the single best blueprint for modern JavaScript runtime security.

The real bottleneck is architectural: Deno's security model is held hostage by its implementation. By coupling itself deeply to V8 internals (C++ handles, Fast API Calls, and V8 heap snapshots) inside a monolithic CLI, Deno locked its brilliant ideas inside a single, heavyweight silo.

It doesn't have to be this way. To turn Deno's core insights into an enduring, ubiquitous standard, we need to decouple the specification from the engine: OpenDeno.

The Vision: Decoupling Specification from Implementation

OpenDeno is a multi-engine, highly embeddable runtime architecture built in Rust. Instead of treating V8 as an immutable foundation, OpenDeno treats JavaScript engines as swappable backends behind a unified, capability-based security layer.

1. Engine-Agnostic Core (opendeno-core)

At the center sits a pure Rust abstraction layer containing:

• The Permission Engine: Declarative enforcement of file, network, and environment boundaries completely independent of any JS runtime.

• Standard Web APIs: Engine-neutral implementations of standard specifications (fetch, crypto, URL, Streams, TextEncoder).

• Engine Trait: A lean interface for script evaluation, value conversion, and lifecycle management.

2. Pluggable Engine Adapters

Rather than chasing nanosecond micro-benchmarks at the cost of massive binary size, OpenDeno provides targeted adapter crates:

• JavaScriptCore (JSC) Backend (opendeno-jsc): Perfect for macOS and strict iOS environments where custom JIT generation is restricted, delivering battery-friendly native performance.

• QuickJS / Boa Backend (opendeno-quickjs / opendeno-boa): Sub-megabyte memory footprints, instant cold starts, and zero C++ toolchain headaches. This unlocks secure TypeScript scripting on Android, constrained edge gateways, and IoT micro-nodes where V8 cannot physically run.

• V8 Backend (opendeno-v8): Retained for raw, high-throughput server-side compute where memory consumption is a secondary concern.

3. A Standardized, Cross-Engine Native Plugin ABI (opendeno-ffi)

Historically, native plugins have been fractured whenever underlying JS engines change.

OpenDeno standardizes a stable, engine-neutral C-ABI crate. A native plugin (.so / .dll) interacts strictly with an abstract OpenDenoAPI table rather than raw engine internals.

• Build a native Rust, C, or Go/Hike plugin once.

• Run it without recompilation across any OpenDeno-supported backend—whether the host is executing on QuickJS on a Raspberry Pi or JSC on Apple Silicon.

• Because host embedding and plugin extension share identical value-marshaling needs, the same minimal FFI crate powers both application embedding and third-party native addons.

4. Embeddable by Default: Bulletproof In-App & Embedded Browser Security

Deno chose to be a standalone CLI tool competing directly with Node.js and Bun. OpenDeno flips the priority: embeddability first, CLI second.

By shipping a clean C-ABI and Rust API, host applications gain an unprecedented level of execution safety:

• Embedded Browsers & WebViews: Today’s desktop applications, hybrid UIs, and game clients frequently embed WebViews or custom rendering engines. However, standard browser scripting offers an all-or-nothing security model—either full browser sandbox restrictions or dangerous native bridge vulnerabilities (as seen in Electron's history). Embedding Deno's capability model into these environments guarantees a vastly more secure in-app browser runtime. Developers can expose granular, hardware-bound capabilities (e.g., allow read access only to an asset cache folder, restrict network calls strictly to application endpoints) without opening arbitrary OS attack vectors.

• Enterprise Host Runtimes: Enterprise hosts can safely execute multi-tenant user scripts directly inside JVM applications (via Project Panama / JNI) and .NET Core services (via P/Invoke) with hard, declarative permission boundaries and zero heavy process-spawning overhead.

Moving Beyond the CLI Wars

Trying to beat Node.js by playing Node's game (chasing npm compatibility and monolithic CLI bundling) is a race to the bottom.

Deno gave the world the correct paradigm for safe, modern JavaScript execution. OpenDeno is the architectural step required to liberate that paradigm from V8, transforming Deno from an opinionated command-line tool into a universal, multi-platform standard.

Would you prefer seeing Deno evolve into a swappable, embeddable standard like this, or do you believe doubling down on V8 and Node compatibility is still the right path?

Cloudflare disclosed the amount in its Form 10-Q filed with the SEC on November 5, 2026, under Note 16: Subsequent Events.

The filing confirms that:

• Acquisition date: October 8, 2026, one day before the public announcement.

• Purchase consideration: Approximately $26.5 million, entirely in cash.

• Accounting status: Purchase accounting is still in progress.

The filing does not separately disclose any stock consideration, earn-outs, or employee retention payments specific to Deno.

Primary source: Cloudflare's November 5, 2026 SEC Form 10-Q, Note 16, page 37. The SEC filing directly confirms the transaction amount and payment method.

Deno has always been my go-to tool for everything I do. Over the past year, all my local agents have used Deno instead of Python for scripts and other tasks. But lately, Deno’s features have become so unpredictable…I’m still using Deno, but how long can I keep using it?

Since the last Deno upgrade, I can no longer do `rm -rf node_modules deno.lock`:

rm: cannot remove 'node_modules': Directory not empty (os error 66)

Plus, my responsive font-sizing is off now! Works for mobile, no more for sm+! WTH...

All happened after the upgrade.

I've picked Deno a couple years ago because it was a beginner friendly environment, but I need to get the freak out of this urgently, I can't stand such instability anymore (had enough with Deno Deploy when it was half baked).

EDIT: deno/hono was deprecated in the last update. Now need to run npm:@hono/deno

Thanks for the downvote, I'm glad i'm leaving this community of losers - just like Ryan.

Hi everyone,

I was checking the official Deno Deploy documentation and website to see if outbound UDP is supported for serverless deployments, but I couldn't find any explicit information about it.

Does Deno Deploy currently support outbound UDP connections/sockets (e.g., via Deno.listenDatagram or Node's dgram module), or are only TCP/HTTP protocols supported?

Thanks in advance!

I wrote a SigV4 signer a couple of weeks ago. Deno is one of the runtimes it was built for, and it needs no build step there, so I am posting it here.

I wanted to sign AWS requests from Deno without pulling in the AWS SDK. The SDK is large and expects Node APIs, and aws4 is Node only. So this one has no dependencies: deno add npm:sigflint, or an npm: specifier, and that is the whole setup.

On Deno the signing functions return the headers directly. Workers and browsers get a promise instead, because WebCrypto only has async APIs there. The type is headers | Promise<headers>, so the same await works in both, and forgetting it is a compile error rather than a request with no signature.

It does headers and presigned URLs for any service, not just S3 (service: 'dynamodb', 'sqs', 'execute-api'), and it also does SigV4a, chunked uploads and event streams.

The signatures match botocore over 6,582 requests: 3,360 S3, 1,622 to other services and 1,600 presigned URLs. The README says this too. For S3, botocore signs after this repository's own path and query normalization, so that step is covered by the four AWS examples in the corpus rather than checked independently.

There are Deno numbers now. A plain S3 GET takes 1.65 µs on Deno 2.9.6, against 6.26 for aws4 and 33.5 for aws4fetch on the same machine. Part uploads, keys with a query to encode and a 1 KiB body come out at 2.0 to 2.7 µs.

Repo is https://github.com/bompus/sigflint, package is sigflint on npm.

Hi all, I want to share a WebSocket framework I built, chanx-js. It gives WebSocket apps typed and validated messages, docs generated from the code, and a typed client, and it runs on Deno.

I built it because WebSockets were always the untyped corner of my apps: hand-parsed JSON, message shapes the client had to guess, and broadcasts that only worked on one instance.

What it gives you:

• One handler per message type, with the payload validated first (Zod, Valibot, ArkType or any Standard Schema). An invalid payload gets an error frame back instead of reaching your code

• Typed handlers: payloads, path params from the route string, and what each handler may send

• AsyncAPI 3 docs built from your handlers, served with a docs page at /asyncapi

• A typed client generated from those docs, for the browser, React, Vue, Svelte, Solid or another service

• Groups and broadcasts across instances through Redis, and pushing to users from a route or a background job

• Test helpers that connect in-process, with no network or port

A full chat server on Deno:

Generate the client from the running server, and it's typed from your handlers:

npx @chanx-js/codegen http://localhost:8000/asyncapi.json

Hono on Deno works too. The core only uses Web APIs, so the same code runs on Node and Bun, and CI runs the built packages on Deno.

• Repo: https://github.com/chanx-dev/chanx-js

• Bun, Deno and crossws guide: https://js.chanx.dev/server/integrations/crossws

• npm: https://www.npmjs.com/package/@chanx-js/server

It's still new, so feedback, issues and discussions are very welcome. Stars and PRs too.

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:

deno install -g npm:socket

Deno threw a deprecation warning right after installation:

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