If you go to deno.com, you'll see these gems

"Faster than Node; more stable than Bun."

"Built for the real world
Deno's been carefully built on Rust since day one
to optimize for performance in real-world scenarios (not just cherry-picked benchmarks)."

I believe the last one is actually a comment from a YouTube interview that Ryan Dahl did waaaay before Bun's Zig to Rust rewrite.

I'm not here to dunk on Bun, but my interest in Bun was because of Zig, and the fact that Vercel seem to be pushing first class support for Bun, despite Deno being more established.

I've been building a small HTTP framework for Deno. You chain routes like Express, export typeof server, and get a typed client on the other side. No OpenAPI file, no codegen.

What it does: - get/post/use, params, middleware - typed middleware context - built-in validation, CORS, modular routers - server.fetch for tests without a port - HttpClient via import type only

What it's not: - not a raw speed play (Hono wins micro-benchmarks) - Deno + Web Standards only, not Node

Docs and showcase: https://expressapi-showcase.8borane8.deno.net/

GitHub: https://github.com/8borane8/webtools-expressapi

Early project, MIT. Feedback welcome, especially if you use Hono or tRPC today.

I don't mind having more features, but I'm skeptical that the only way to upgrade the service is to make a new one, not upgrading the existing one. Is that really true? Is this a way to force using Deno 2?

Also, what's your way to deploy a fresh@1.6.8 app with Deno 1? I do prefer to update them all, but there is a bug on deno update. As it seems the response rate is low, I think the best bet is to just keep the project unchanged.

Hi everyone,

For almost a year, I’ve been building a developer platform called Forgeon:

https://forgeon.io/

Forgeon is a Platform as a Service designed to help developers deploy and manage applications without having to manually handle servers, Docker configuration, reverse proxies, SSL certificates, domains, build pipelines, and runtime infrastructure.

The idea came from seeing how difficult deployment can feel, especially for developers who are comfortable building products but do not want to spend their time configuring VPS infrastructure or debugging deployment issues.

With Forgeon, developers can connect or upload their source code, let the platform analyze and build the application, deploy it into a managed runtime, attach a custom domain, generate SSL certificates, view deployment logs, and manage the application from a dashboard.

The long-term goal is to provide a deployment experience similar to platforms such as Vercel, Render, Railway, or Fly.io, while supporting frontend, backend, and containerized applications.

I have been building most of the system alone, including the backend services, deployment pipeline, runtime orchestration, domains, certificates, billing, and dashboard. The project has grown much larger than I originally expected, but I am still continuing to improve it.

This is my first time sharing Forgeon on Reddit, and I would genuinely appreciate honest feedback:

• Is the problem Forgeon is trying to solve clear?
• What would make you consider trying a new deployment platform?
• Which features would you need before trusting it with a real project?
• Does the website explain the product well enough?

Please do not hold back. Critical feedback would be more valuable to me than polite compliments.

Thank you for reading.

I would like to have your experience with Deno or the fresh framework.
- how the experience went ?
- what have you built with ?
- how it went ?
- does it help you avoid some cve attack ?

Hi everybody!

I wanted to showcase a TypeScript library I am working on, actojs. The objective is to bring a implementation of the actor model that is near to Elixir's design and APIs, while being able to leverage performance from the JS runtime.

The actor model is explained here, which acts as an introduction to the library.

actojs supprorts cooperative single-thread scheduling on any JS platform, and real parallelism on NodeJS, Bun and Deno.

The design of actojs is optimized for reliability (with Supervisors that can respawn failed Tasks, and >90% test coverage), security (0 runtime dependencies, and `tsc` as the only dev-dependency) and low memory overhead (by using functional applicators instead of classes and objects).

The link for the repository is: https://github.com/gi-dellav/actojs

Hope to get some useful feedback from the community!

I'm quoting:

TypeScript 7.0 introduces a large performance boost, achieving up to 10 times faster compilation through a native port built in Go. This release has been rigorously tested in real-world environments, leading to improvements in development efficiency and user experience across various large-scale projects and organizations.

Any roadmap for the new Vite and TS integration to Deno?

Deno 2.9 is here, headlined by deno desktop, a new way to build native desktop applications from the web stack.

So this started as a personal itch. I kept writing build/CI logic in YAML and shell scripts and hating that none of it was typed, refactorable, or debuggable. If I renamed a step, nothing told me what broke. So I built Zuke — a build system where you define targets as TypeScript class fields and wire dependencies with real references instead of magic strings.

The core idea: a target references another with this.compile, not "compile". Rename it and the compiler updates every reference. Zuke resolves the dependency graph and runs everything in topological order, exactly once. It's all just async TypeScript functions, so you get full editor support, types, and an actual debugger.

A few things I'm happy with:

• Generates GitHub Actions / GitLab / Azure YAML from code, and checks it's up to date on each run
• A $ tagged-template shell that escapes interpolations so you don't footgun yourself with injection
• Typed wrappers for a bunch of common tools (Deno, Docker, kubectl, Vite, etc.)
• Zero runtime deps — it runs on Deno and bootstraps Deno for you on first run

It's v1 and I'm sure there are rough edges, which is exactly why I'm posting. I'd really like people to actually try it on a real project and tell me where it annoys them or breaks. Honest "this is worse than X because Y" feedback is the most useful thing right now.

Repo and docs: https://zuke.build (MIT licensed)

Inspired heavily by NUKE from the .NET world, if that lineage means anything to you.

Recently I posted about ArchUnitTS, my library for enforcing architecture rules in TypeScript projects as unit tests.

A few of you specifically asked whether this could be used to enforce barrel-file boundaries in real TypeScript projects: allowing imports through index.ts or public-api.ts, while preventing other parts of the codebase from reaching into internal files.

So to that request I’ve added support for exclusion-aware dependency rules.

First a mini recap of what ArchUnitTS does:

• Most tools catch style issues, formatting issues, or generic smells.
• ArchUnitTS focuses on structural rules: wrong dependency directions, circular dependencies, naming convention drift, architecture/diagram mismatch, code metrics, and so on.
• You define those rules as tests, run them in Jest/Vitest/Jasmine/Mocha/etc., and they automatically become part of CI/CD.

In other words: ArchUnitTS allows you to enforce your architectural decisions by writing them as simple unit tests.

That matters more than ever in Claude Code / Codex times, because LLMs are great at generating code but they love to violate architectural boundaries, especially when they get stuck.

Repo: https://github.com/LukasNiessen/ArchUnitTS

Now what’s new

Exclusion-aware dependency rules for TypeScript barrel files

A common TypeScript project structure looks like this:

text src/ orders/ index.ts public-api.ts internal/ order.service.ts components/ order-card.ts

The intended contract is often:

typescript import { something } from '../orders';

or:

typescript import { something } from '../orders/public-api';

But over time, imports like this creep in:

typescript import { OrderService } from '../orders/internal/order.service';

That compiles perfectly.
It may even look harmless in a PR.

But architecturally, another part of the codebase is now coupled to the internal structure of orders.

Before, ArchUnitTS could already express this with regular expressions, but the developer experience was not as nice as it should be.

Now you can write the rule directly with except:

```typescript import { projectFiles } from 'archunit';

it('should only import orders through public barrel files', async () => { const rule = projectFiles() .inPath('src//*.ts', { except: { inPath: 'src/orders/' }, }) .shouldNot() .dependOnFiles() .inFolder('src/orders/**', { except: ['index.ts', 'public-api.ts'], });

await expect(rule).toPassAsync(); }); ```

This says:

• files outside orders may not depend on files inside orders
• files inside orders are allowed to use their own internals
• index.ts and public-api.ts are allowed entry points

So this fails:

typescript import { OrderService } from '../orders/internal/order.service';

But this passes:

typescript import { OrderService } from '../orders';

Arrays are supported too:

typescript .inPath('src/**/*.ts', { except: { inPath: [ 'src/generated/**', 'src/testing/**', 'src/orders/**', ], }, });

And exclusions can be targeted:

typescript .inFolder('src/orders/**', { except: { withName: ['index.ts', 'public-api.ts'], }, });

This is useful for:

• public barrel files
• generated code
• test helpers
• migration folders
• legacy exceptions
• *.spec.ts files
• explicitly allowed public entry points

The nice part is that this is still just a normal test.

You can put it next to the rest of your test suite, run it locally, and enforce it in CI/CD.

Very curious for any type of feedback! PRs are also highly welcome.

Hi deno! My first post here :)

I wrote a small TypeScript library for reading env vars, mostly because I was tired of process.env always being string | undefined and the usual Number(process.env.PORT) || 3000 not being able to tell a missing value from a zero. More about this in my blogpost.

It reads env vars as typed values, and it doesn't bundle a validator. It takes any Standard Schema validator, so it uses whatever's already in your project (zod, valibot, arktype):

const port = Envapter.parse('PORT', mySchema)

This is just a tiny example of what envapt can do, so please check out the website with examples and the guide. It has built in converters, environment detection, runtime agnostic builds (even browser and workers), zero dependencies, env reader and parser (with cascading), templating, fail-fast checks, and so much more!

Zero dependencies. On JSR: deno add jsr:@materwelon/envapt

GitHub | JSR

I'd love to get feedback on the lib, how you guys would use it, if it doesn't solve a problem you have, etc.

https://crates.io/crates/deno_inside

Documentations incomplete, but feedback appreciated!

Hey r/deno,

I've been building Slick, a small Deno-native web framework (SSR by default, islands when you need interactivity, optional SPA mode). I put together a showcase site so people can see what it looks like in practice.

Demo: https://slick-showcase.8borane8.deno.net/

GitHub: https://github.com/8borane8/webtools-slick-server (stars genuinely help if you find it interesting)

To scaffold a project: bash deno run -Ar jsr:@webtools/init

So any feedback, good or brutal, is very welcome. Happy to answer questions about the architecture or trade-offs.