Hacker News Reader

> 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'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.

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"

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.

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.

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!

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.

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++.

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

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

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.