Deno 1.35 stabilizes a request-handler HTTP server

An HTTP handler usually wants a request and a way to return a response. Requiring it to manage accepted connections and HTTP-event iteration adds transport work before application behavior begins. Deno 1.35 stabilizes Deno.serve, putting that connection machinery behind a handler API built around web-standard objects.

The July 5 announcement says the API no longer requires the unstable flag. Its 1.35.0 release notes record the stabilization, with the tag dated July 4. This post follows the announcement date because that account explains the intended server interface and compatibility work.

I value TypeScript mainly through the ecosystem that supports web applications. A server interface using the same Request and Response concepts as other web APIs reduces the number of conventions application code must translate. That is useful even without choosing a full framework.

Connection management moves behind the handler

The earlier Deno.serveHttp arrangement required accepting connections and iterating HTTP events. A program handled each request event by supplying a response. The new API accepts a handler directly, and the runtime manages the connection-level work needed to invoke it.

The stable entry point can be demonstrated without a separate package import.

Deno.serve((_request) => new Response("hello world"));

The small example matters because it shows the boundary of application responsibility. The handler receives a Request and produces a Response. It does not mean that application routing, authorization or response content cease to need an implementation. Those concerns can now be expressed above the transport interface.

Using standard objects also makes other web facilities relevant. Response bodies and streams belong to the same family of APIs used by fetch. A library expecting those objects can interact with a handler without first converting a runtime-specific request representation into its own shape.

This does not make a server interchangeable with a browser. Listening for incoming traffic is a host facility, while Request and Response describe messages. Sharing their representation reduces adaptation work without erasing differences in permissions and execution environment.

Existing Node HTTP users share runtime work

The announcement says npm packages using node:http use the new server API underneath. That connects the new implementation to existing application interfaces. A project can exercise the runtime HTTP implementation through compatibility code without rewriting every handler to call Deno.serve directly.

This is a useful form of compatibility because it avoids maintaining wholly separate server implementations for the two programming interfaces. It also makes correctness in the adapter important. A Node-facing API has its own expectations for events and object behavior even when the underlying transport is shared.

The release notes include a keep-alive method addition to the compatibility socket. That level of detail illustrates why a simple hello-world example does not establish complete compatibility with every middleware package. An application may depend on a less visible method invoked only in connection management.

Deno's announcement includes performance comparisons with Node for simple servers. Those results belong to the described workloads and test environment. The architectural point is that both native handlers and compatible Node HTTP packages can use the runtime implementation, so improvements there can reach more than one application style.

Compatibility grows through specific missing operations

The release describes additions and fixes in HTTP, HTTPS and compression facilities. Brotli compression and decompression APIs are among the named changes. An npm package can require one such operation even when most of its JavaScript already runs correctly.

The announcement names packages including axios and node-fetch as newly working examples after these compatibility improvements. This gives the change a practical interpretation without establishing that every use of each package has identical behavior across runtimes. The relevant claim is that implementing missing host APIs makes more existing packages usable.

The release notes also repair Node-API behavior for properties with getters and setters. Native interfaces and JavaScript property semantics meet at that boundary. A runtime can expose an API name while still rejecting a descriptor shape that an extension depends on.

I find these individual compatibility repairs more informative than a broad assertion that an ecosystem is supported. They identify the operations whose absence stopped real combinations of code from working. A runtime migration depends on that concrete dependency set.

Editor imports need to match runtime resolution

Deno 1.35 improves auto-imports for npm specifiers and import maps. The language server can propose the names and paths the project actually uses. This addresses a different part of compatibility from executing a module after its import is already correct.

A developer often encounters a dependency first through completion or a quick fix. If the editor inserts an inappropriate path, the runtime may resolve imports correctly while the ordinary editing workflow remains awkward. Integrating import maps into those actions makes the configured mapping useful during source construction as well as execution.

This also helps preserve a project convention across files. Import-map aliases can remain recognizable in newly written code instead of being replaced by whichever underlying path the editor happened to find.

The release ships TypeScript 5.1.6. That compiler version supports the new JSX element-tag declaration mechanism, while Deno's own language-server work connects imports to its project model. Compiler capability and runtime-specific editor integration contribute different parts of the development experience.

Standard-library changes expose representation choices

The associated standard-library semver rewrite replaces the stateful class representation with immutable plain objects and narrows overloaded API inputs. The announcement demonstrates parsing version strings before passing them to comparison functions. Older forms remain marked deprecated at this point.

That makes parsing a visible operation. A comparison receives a version representation, while converting text into that representation happens separately. The transition differs from stabilizing the HTTP entry point, but it follows the same concern with assigning each operation a clear responsibility.

The release also adds Headers.getSetCookie and value-aware URLSearchParams operations. Those changes fill specific gaps in the standard web interfaces available to handlers. Together with the stable server entry point, they let more request and response work use the runtime's web objects directly, reducing the need for application-specific substitutes around missing operations.