Deno 1.35: A fast and convenient way to build web servers | Hacker News Reader

Deno 1.35: A fast and convenient way to build web servers

deno.com

199 pointsmikece119 comments

As part of my first couple of months of work at Deno, I wrote the new Deno.serve implementation that's being stabilized here. It's based on a thread-local slab that is wired into Hyper 1.0 (which is an amazing Rust webserver and nearing release).

This gave us solid support for HTTP/2 in Deno itself -- you can start a full webserver on a TLS socket and start talking fully-compliant HTTP/2 in just a couple of lines.

It's an interesting challenge to get this to cooperate with V8 in a performance way and we're continuing to work on it while keeping the code as maintainable as possible. The implementation will continue to evolve as we design better and faster interfaces between Rust and V8. The cool thing is that this is all going into open-source projects, either in Deno itself, rusty_v8 or V8 itself.

Happy to answer any questions.

So how do I get the SSL certificate in there, does it come with it?

I found this:

https://deno.land/manual@v1.35.0/runtime/http_server_apis#ht...

I would personally use letsencrypt and then pass the cert/key into the Deno.serve call, though I am curious now if there is a more integrated solution and I'm going to dig into it a bit.

Use Caddy.

Yes, I too am too lazy to learn nginx, certbot or whatever those things are as well.

Edit: I really am. Why downvote?

I got you boss. Cheers to laziness

Laziness is the Mother of Invention

Does it have HTTP/3 features like WebTransport?

Not yet, but we are keeping our eyes on HTTP/3. There are a few good options for us to integrate it, but we want to make sure we do it right (and meanwhile figure out the right way to expose HTTP/2 features that aren't available yet).

Sounds like sales speak, nodejs isn’t even there yet.

There are like three different http/3 implementations in Rust, used in real ways. Even if they don't want to write their own, there's a lot of choice out there.

That's awesome, any automatic HTTPS (ideally by default)?

Yep. As long as you give Deno.serve a certificate and private key and you get modern TLS, HTTP1 and HTTP2.

Oh, sorry, to clarify, I meant: HTTPS that works automatically. By starting the server, it's starting HTTPS by default. It gets or generates a certificate for you and renews it, etc.

In this case, not in the built-in Deno.serve case. Certificate management is definitely a challenge, especially for local development.

Does streaming work? Server-sent events?

Everyone's interested in SSE again thanks to serverless and Open AI's API

Open AI's API is using SSE to stream results?

It has a "streaming" mode (non-SSE, traditional long http requests") and many developers are choosing to forward chat data to end users with SSE (maybe to get around browser http request timeouts).

Both of these definitely work. I'm on my phone right now so finding references is a challenge, but you can stream either of these ways (or use WebSockets) using Deno.serve.

I trialed Deno for an HTTP+WS side project [1] and have been loving it. The simplicity of having Typescript built-in, the nice async APIs, and the sandbox permission system all make it a great choice for green field projects. I don't mind the url-based dependency system as much as I thought I would; with the language server DX it's easy enough to maintain.

Deno feels like Node from 10 years ago, in both good and bad ways: every Deno native community library I've pulled in (redis, S3) has had significant bugs. Fixing them has been fun but distracting. Looking under the covers, I've found the code to be really clean as a result of Deno's abstractions. The improving npm support helps to make mature libraries accessible, but the Deno native libs also have a bright future.

[1] https://github.com/chromakode/coalesce/tree/main/project-ser...

I tried deno a while ago (over a year) and could not find a way to get deno and typescript to accept the same files. They disagreed about filename extensions in import statements, and I couldn't find a format that was accepted by both.

Are you trying to use Typescript separately from Deno instead of Deno's builtin support for Typescript? Are you using VSCode without the Deno extension? I think you're overcomplicating something if you're running into this issue.

That would be yes on both points. I was unaware that deno needed a separate vscode extension and did not know that deno ran the typechecking itself.

I may give it a try on some personal projects now that I know this.

The repo I linked to has an example of shared files between Deno and Vite. I'm using import maps to have a consistent `@shared/types` module between both (as well as consistent names for the requisite imports)

The thing I don't quite get yet about Deno (and maybe some other similar things), is that do so much that they need to be perfect to be worth using.

Deno is effectively a language and runtime, webserver, package ecosystem, and arguably infrastructure and database. When choosing the technology to use for something that feels like a lot of eggs to put in one basket. Sure there are benefits to bundling like this, but the downside is that you're more exposed to bits of that bundle being insufficient.

Maybe this criticism doesn't play out in practice, but Deno and some other things trying to re-invent Javascript again, seem to be trying to do too much at once, and are risking ending up too far away from the original ecosystem to be able to return. Now maybe the only way to re-invent JS in a convincing way is to do these wholesale rewrites making big divergences, but then again, perhaps that just indicates that JS is not the foundation that it needs to be for some kinds of development.

Note, I've said JS as a grouping of the JS/TS ecosystem and existing packages. I don't think TS changes things that much as it's still the same ecosystem of tooling for the most part.

The status quo comes from tools that do just one thing or that compose a lot of other tools. And I don’t think too many people are excited about the status quo.

Deno’s pitch to me is to take everything that makes Golang work so well, and apply it to JS/Typescript. I can’t switch yet but I sure would like to!

They are doing too much at once, but I think it's possible, since they are a company, and last year raised $21M.

https://deno.com/blog/series-a

I like Deno for many of the same reasons I like Rust and Go, the tooling comes bundled with the runtime. No fussing about with ESLint/prettier/tsconfig/bundling and all that jazz, Deno includes it all. The dependency story was a little rough for a while but with import maps now it’s really quite nice. With the npm ecosystem integrations it’s starting to be a very nice developer experience.

I guess this is part of my criticism. It's nice to have all that stuff bundled, but it's banking a lot on the decisions being the right ones for your project. When it's just the language, linter, formatter, that might be fine. Adding the package manager is often ok as well, but even Rust/Cargo aren't fully coupled. But then adding a package ecosystem (that isn't fully compatible), a server, infrastructure, database.... it's a lot of decisions that all need to be good enough.

No one's forcing anyone to use those things, though. I think the benefit of having those wrapped into Deno is that they'll presumably be performance optimized, but it's just as easy to use JS instead of TS, use ESLint instead of `deno lint`, Prettier instead of `deno fmt`, or whatever. Those are kind of evergreen toolchain concepts that I think benefit from being standard to Deno, even if their implementations are minimalistic.

I think similarly, note my usual comments about guest languages.

Typescript gets the pass, because it basically a JavaScript linter, with an easier way to get modern JavaScript features, without wrestling with babel and friends.

Projects dictate language toolchains, not the other way around, and so far I haven't seen any project or product SDK placing Deno on the tooling requirements.

Maybe this doesn’t count, but Deno Deploy dictates Deno. I’m finding it pretty nice so far.

It will be more compelling when the FoundationDB-based KV store is finished. At that point there will be enough to write full web apps without any external API’s, so I can use it to build the simple hobby websites that I used to use AppEngine for. (For now I’m trying it out using Neon for Postgres.)

It’s still for developers rather than nontechnical users, but this may be simple enough to deal with that it does some of what Sandstorm promised to do for things like blogging. Or maybe a personal Fediverse server?

It would be nice to have a second source for Deno-based hosting, but in a pinch I could put Deno and my apps in a Docker container and run it anywhere, though probably not for free.

Deno was created by the guy who created NodeJS, so it might be good for JS projects.

> a language and runtime, webserver, package ecosystem, and arguably infrastructure and database

Some gentle pushbacks:

Runtime and webserver yes (though not web framework), language sorta, though Node is already just as much all of these things

Package ecosystem also sorta. Any Deno module that doesn't use the Deno APIs is isomorphically runnable in the browser and most other JS contexts. This is actually more true than with Node, because idiomatic Node code uses CommonJS imports which are incompatible with the browser without transpilation

Infrastructure I don't think is really true; obviously there's Deno Deploy, but I don't use that for any of my Deno projects. If anything, the fact that it's so self-contained makes it more flexible to different kinds of infrastructure. All you need installed is the runtime, and then you run a single command and you're off to the races (with dependencies downloaded automatically as needed)

I think it strikes a great balance between batteries-included and compatibility. It's become my favorite default way to write a CLI or a web server

I had similar hang ups about deno but my experience aligns with what you’re saying. I hit far fewer snags than I thought I would (none I suppose), and the tooling off the shelf was excellent. I was off and running within 30m or so.

I got a little confused about importing packages properly but it might be down to how my IDE handles stuff and not really deno-specific.

I also love it for CLI work. I was using Go pretty much exclusively for years, but I’ve used Deno twice for real work and a bit for experimentation. Go offers some features I prefer, but Deno offers TypeScript which — for better or worse — is where I think best in code. I like to maintain it more, which means a lot for something I have to deal with next year.

Wait, Node or Deno for CLI tools? I was reading this and thinking "Go would make a much better tool for that job", so after seeing that you have actually used it in the past, I cannot but ask about some more info or comments your might have about it.

A language that is designed from the ground up to compile into standalone binaries seems so much more apt for CLI tools... Deno/Node, on the other side of the spectrum, requires a whole environment and runtime, which seems like a hassle. I know of vercel/pkg but that's not a first-class citizen of the ecosystem and has its shortcomings.

You can run `deno compile` to build a standalone binary.

https://deno.land/manual/tools/compiler

Very interesting, I just learned that Deno has direct support for doing this! Very useful, indeed. Thanks for mentioning it.

Have you used it, to know what is the baseline size of the file it generates? e.g. the size of a "hello-world" command, which would be basically 99.9% composed of the runtime and core libraries.

It’ll bundle the entire V8 engine. You can expect probably close to 80mb for a hello world app.

I’m not sure about the size of a Hello World but a very small command-line tool I wrote is about 90MB, where the only substantial dependency is commander.js from NPM. I expect the vast majority of that is a constant size added to all binaries.

The other commenter mentioned `deno compile`, but also, if you're in a situation where you can assume everyone has the deno runtime installed (maybe it's a personal script, or it's org-internal or something) then you don't really even need to do that, because the runtime is the only piece of environment you need. The dependency management is self-contained and the runtime is backwards-compatible; scripts should generally "just work"

I was assuming a more general case where concerns like distribution of the tool are something to think about. Of course if it's just a personal thing, it doesn't matter much, I just wasn't counting on such a small use case.

Or just use Hermit to automatically install deno on first run… https://github.com/cashapp/hermit

(Disclaimer, I work for Square, a sister org within Block of CashApp, where the folks that created Hermit work.)

I've started using Hermit for all my personal projects... one too many times I've cloned one of my own github projects I haven't touched for a couple of years and taken half an hour to remember/decipher how to get everything installed and running. Now I just use Hermit, and possibly a `bootstrap.sh` file that will `pip install -f requirements.txt` or suchlike, and I'm off to the races.

You're not wrong — Go is awesome at this, and on paper it's generally a better tool for the job. I had to write a CLI tool that did a ton of concurrent fetching and processing with interactive retries, pausing, and other nasty UX stuff that would have been misery in TypeScript compared to Go, but I had it working well inside of a week. I don't think the same would be true of something I'd make with Deno, or at least not with the same performance.

Yet I can model solutions better in TypeScript, I work faster most of the time, I find the people I work with tend to understand complex TypeScript projects far more readily than complex Go projects, and some tooling (certainly not all) can be nicer in TypeScript land. There are definitely trade-offs. There are some go-to packages I love to use and fit my habits extremely well in that ecosystem though, so that's a welcome benefit for me personally.

If I had to build something very fast, reliable, more readily portable, and well-suited to Go's strengths, I wouldn't hesitate to use it. For something smaller or far nicer to model with TypeScript's type system, or with a team that isn't up to speed with Go, I'll seriously consider Deno without feeling like it's a major compromise.

Everything you said makes sense. If it's a tool shared and maintained by a team, technology is not the only matter to consider. Familiarity and ease to model the problem is also very important. Thanks for sharing your perspective

You’re welcome!

The more I think about this the more I realize how spoiled we are these days. These are both awesome tools in their own right that didn’t even exist when I got started. It’s a real joy to have such great tools to work with.

Decades of experience has taught us that when you don't integrate the language, runtime, packaging and infrastructure properly you get a total mess, like Python or C++.

Just in case someone at deno is monitoring HN comments there is a typo in the third link resulting in a 404 : https://deno.com/manualruntime/web_platform_apis should probably be https://deno.com/manual/runtime/web_platform_apis

Also there's one feature that deno could make possible given their tight integration:

Allow JSON.parse to use typescript types.

So I can parse JSON with supplied type and engine would validate JSON against that type. Simple as that.

Also might be useful for JSON.serialize to have an output control (because TypeScript could be abused and actual value might differ from its type).

This simple feature would bring tremendous value to application stability IMO.

I have been using zod to create validation functions. The validation functions give the TS compiler hints about the types that are output after validation.

I think you either:

(1) start with the runtime code and derive the types (what TS does by default).

or (2) start with the types and derive the runtime code (like "macros" in some languages).

Does anyone have any suggestions for the best way to do this in a Node runtime?

I use Deno for all my personal projects. It's not perfect, but the fact that it's so much closer to working in a browser environment really helps a lot in terms of mental modeling. Lately, I've had no reason to revert to using Node given the current level of support for NPM packages.

Can someone enlighten me about one thing.

I kind of like deno when it came to its package management. I hate npm and I liked that deno tried to disrupt ecosystem.

Now when deno bent over and accepted npm reality, is it possible that few years later they'll just switch over to it entirely and abandon their old ways of packaging?

I understand that it's easier to sell deno to developers when they can import npm package. And deno wants to make money, so taking a hard stance is a bad financial option in the short term.

Still I'd love to take a bet on deno. But if deno is just another npm... Well, setting up node + typescript + eslint + prettier sucks, but not so much.

With all the hype around server-side webasm I decided recently I'd try to implement a project in this. Cool but just in case anyone else figures the same just keep in mind that webasm is still 32-bit and as such if you need more than 4GB ram in whatever you're doing, well, that's your ceiling for now until they figure that out come next year or so.

The Deno ecosystem itself needs some work for sure. I think alot of other comments already said everything better regarding that but it's still nice to know that we have something to write typescript in that doesn't just target nodejs.

http benchmark are mostly useless. Most of the benchmark re-uses connections. You will get around 14k requests/second if you close the connection for each request.

The axios redis And pupeteer support added is actually really important and only mentioned as a side note really. Super cool work going in.

I'm new to the deno world but will be testing it out this week.

I'm curious though the decision not to have a dedicated package manager on the first place? Maybe someone knows the reasons for this?

What do you need axios for compared to fetch?

Nothing that I can think of but that's not the point, the transition is easier without having to rewrite in deno native as i understand.

I'm not using Deno yet (I'm about as bleeding edge I want to be with my serverless services built on TS) but I love these updates and look forward to the day that I feel like I can start to use it.

I used to think the sandboxing feature was going to be a really big deal but I don't any more. I think WASM is eating their lunch in sandboxing. I'm keeping a close eye on Fermyon and Dapr.

Deno runs WASM code just fine and IMHO will probably be the pre-eminent way to use server side WASM (because you likely also need some JS/TS bootstrapping or glue code too for setting up a basic API or other endpoints): https://deno.land/manual@v1.10.0/getting_started/webassembly

If you're writing your server side code in JavaScript, yeah. I don't think it will be pre-eminent. I think it could be popular but much less popular than Node.

There are server side WASM runtimes for other languages, though. Including ones that let you write endpoints entirely with WASM (and its languages like Rust and Go*), like Fermyon and Dapr.

* https://github.com/appcypher/awesome-wasm-langs

WASM is just application servers being talked by those that didn't lived through Java and .NET application servers.

Now served with tons of YAML configuration files instead of XML, and being told to configure our own Kubernetes infrastructure on top of it.

Deno is great. I put together a website using Lume super quickly and it was a refreshing change from using Node etc.

Some annoyances, mostly around the Deno Deploy side of things, but otherwise I'm a huge fan.

Can I easily integrate Rust crates into my Deno app like a smaller extension for number crunching or at one point even something like Polars?

You could compile them to WASM and call them from Deno

I tried to switch my nodejs project to deno and discovered it “just doesn’t work that way”.

Deno is not a drop in replacement for nodejs, which is a pity.

I don't think so. I don't want another nodejs. If I'm getting the same tradeoffs as nodejs, why not just use that?

I like Deno specifically because of how different it is from node.

Bartek from the Deno team here. Sorry to hear that - we made great progress in making Deno drop-in replacement this year, but we certainly are not yet there 100%.

I'd love to hear what problems did you hit and look into solving them.

I don't recall but it felt like a distant goal at best.

Is there a written guide for how to convert a nodejs project to Deno?

I'd really prefer to be using deno instead of node. If it was a seamless experience I would definitely drop nodejs.

A couple months back we added an ability for Deno to run projects authored for Node.js directly.

Eg. if you have a Vite app (or any other app really) with "package.json" and some "scripts" defined there, just try running "deno task <script_name>". Deno will automatically pick up "package.json" and try its best to run the that script.

It's not fully done, but in our testing we got a lot of non-trivial projects running that way. If something doesn't work in your case, I would greatly appreciate a bug report to help us fix this.

As for the written guide - there's not a single one at the moment - it's something we'll be looking into in the coming months.

I'll wait till there's a written guide then follow it.

I’m wondering how you implement Deno.serve on Deno Deploy?

With CF Workers and Lambda you have to export a function

The same code works in both places - the deploy architecture seamlessly integrates Deno.serve with the deploy architecture that lives in front so it "just works".

Anyone knows if something similar to `deno compile` is planned for node in the future?

Nodejs support for "single executable applications" is getting there - this issue below is preventing wider adoption at the moment:

"The single executable application feature currently only supports running a single embedded script using the CommonJS module system."

https://nodejs.org/api/single-executable-applications.html

Should be an awesome game changer for node.js when the feature gets rounded out.

Also check out vercel's `pkg`: https://github.com/vercel/pkg/issues/1291

Like over a year ago Deno raised $21M in investments and this is the current state...

A general hypothesis I have is that the Deno team is just taking on too much to make the investment work in terms of, well everything really: version compatibility to reduce breaking 3rd party libs, one-by-one certification of npm module compatibility, deno core module re-writes, a hosting company, maintaining developer tooling/ecosystem - to name a few.

I am not sure if either fast or convenient applies here. Maybe I have different definitions.

I think they mention fast because the built-in Deno webserver is now faster than node:http. I've been following Deno for a while, and even deployed a service with it, and it's awesome that it has finally surpassed node performance.

I think if you've used Deno before convenient definitely fits, you can build quite a bit without needing external libraries, typescript by default, you kinda just start working on your problem - just a much cleaner version of what node could have been in my experience.

Just use uWebSockets.js[1] in node, and you'll leave Deno in the dust again. (uws is also what's under the hood in bun)

https://github.com/uNetworking/uWebSockets.js

The fastwebsockets library one of our team developed gives uWebSockets a run for its money under a lot of circumstances (though we trade performance improvements and the top spot back and forth).

We're constantly working on improving the performance of Deno from top to bottom and it's a marathon.

We don't want to be fastest at the expense of security or maintainability and the results from the last couple of months have been pretty awesome.

I can't necessarily speak for priorities at any point in time, but I can say that performance is very important and literally what I'm working on most of the time.

good thing I am not in position of power to choose the stack in my company. if I were, I don't think I'd pick deno over plain old docker container somewhere in someone else's computer. on docker, at the very least I know how to move my project somewhere else in case the data center is on fire.

Why wouldn't that be the case with deno too? Just move the deno executable, that's all you need to run it (and your code obviously) You can even just build and use a deno-based docker image like node or any other language image.

Deno and Docker are orthogonal

It's referring to the permissions system which sort of resembles container isolation. Only a bit, though. Something that resembles it a lot more is WebAssembly. There's a plugin system that has been shared by its creators around here a couple times: https://github.com/extism/extism

Can Deno output WebAssembly?

JIT is not possible in WASM. So, the answer is no

Reply on news.ycombinator.com