Deno by Example(examples.deno.land)
examples.deno.land
Deno by Example
https://examples.deno.land/
5 comments
I know what you mean. I feel like the term "execution environment" better describes it, but "runtime" has historical momentum in the JS world (I think), so changing it might cause other confusion. I think (probably) you've been doing your JS/TS in a "runtime" but that was probably either a.) the browser, or b.) Node.js.
In the (pretty weird, IMHO) JS world, this notion of "runtime" amounts largely to what magical global variables are available. And then, what language features are available.
Deno (properly, IMLHO) hides most of its "nonstandard" features behind one magic global variable: Deno. The rest of what it offers is "standard" which Deno (and all sane persons IMNSHO) interprets as "what the browser supports".
Even that's fucked, in JS-world, because there are a bunch of browsers, and each one of them is like "yea woo I love standards, but fuck that standard". But browsers have a standard, more or less, it's just that all browsers implement only a subset of it. Still, to me, that's "the standard".
So Deno implements its own subset of that standard (but they seem to try hard to implement as much as possible), and then it adds its own "Deno" global object for everything else (like local filesystem access, key-value database, etc that browsers don't support).
An execution environment like Node hasn't traditionally prioritized compatibility with "the browser" and so instead it offers a bunch of top-level built-in things like "fs" or whatever, that you "require()" and then you can use them. And standard things that exist in al(most al)l browsers, like TextEncoder or BroadcastChannel or many other things, don't exist in Node. So one nice thing about Deno is that almost all the code you write for Deno will also work in a browser (unless you use "Deno.launchDroneAndFetchCoffee()" or whatever.
In the (pretty weird, IMHO) JS world, this notion of "runtime" amounts largely to what magical global variables are available. And then, what language features are available.
Deno (properly, IMLHO) hides most of its "nonstandard" features behind one magic global variable: Deno. The rest of what it offers is "standard" which Deno (and all sane persons IMNSHO) interprets as "what the browser supports".
Even that's fucked, in JS-world, because there are a bunch of browsers, and each one of them is like "yea woo I love standards, but fuck that standard". But browsers have a standard, more or less, it's just that all browsers implement only a subset of it. Still, to me, that's "the standard".
So Deno implements its own subset of that standard (but they seem to try hard to implement as much as possible), and then it adds its own "Deno" global object for everything else (like local filesystem access, key-value database, etc that browsers don't support).
An execution environment like Node hasn't traditionally prioritized compatibility with "the browser" and so instead it offers a bunch of top-level built-in things like "fs" or whatever, that you "require()" and then you can use them. And standard things that exist in al(most al)l browsers, like TextEncoder or BroadcastChannel or many other things, don't exist in Node. So one nice thing about Deno is that almost all the code you write for Deno will also work in a browser (unless you use "Deno.launchDroneAndFetchCoffee()" or whatever.
V8 is a library that gets embedded in some larger program. It doesn't determine how imports work or any API's, and if you don't have any API's to call, there's not much you can do in JavaScript.
A browser does all that, so that's the runtime. Similarly for Node's import resolution and its API's for doing I/O.
You could think of it as all the code in the 'deno' or 'node' command other than V8 itself.
A browser does all that, so that's the runtime. Similarly for Node's import resolution and its API's for doing I/O.
You could think of it as all the code in the 'deno' or 'node' command other than V8 itself.
Got it. Maybe I always naively assumed there is some shallow FFI layer and all the heavy lifting is done by some set of core standard libraries. Ideally portable to multiple environments.
There’s some of that. I/O in node is done by a C library called libuv [1]. It’s portable and it’s used by other languages too.
Deno doesn’t use it, though. They use Rust ecosystem libraries like tokio. [2]
[1] http://docs.libuv.org/en/v1.x/ [2] https://choubey.gitbook.io/internals-of-deno/architecture/to...
Deno doesn’t use it, though. They use Rust ecosystem libraries like tokio. [2]
[1] http://docs.libuv.org/en/v1.x/ [2] https://choubey.gitbook.io/internals-of-deno/architecture/to...
> I’ve been doing all kinds of JavaScript and TypeScript for a long time now without a runtime (I think) so pretty curious.
Node and browser are both runtimes for your JS code.
Node and browser are both runtimes for your JS code.
The additional thing that node, deno and even a browser supplies (aside from what V8 does) is an API layer and sandboxing features. So perhaps, 'the interaction layer', as you put it?
I'm not familiar with the web space but from my untrained eye these sorts of projects are more like modernized V8 wrappers than runtimes in the traditional sense.
If you were making a scriptable game, V8 would be like Lua. It handles the Lua language and some of the basic functionality of it, but beyond that you’d need to integrate it with ur engine.
Has anyone played with both Deno and Bun? They seem very similar but while Deno uses V8 (like Node), Bun uses Apple's JavaScriptCore.
https://bun.sh/
https://deno.com/
https://bun.sh/
https://deno.com/
I built a CLI tool that needed to be compiled to a standalone executable a couple of months ago and tried out Node, Bun, and Deno for it.
I dismissed Node because it was a super-manual process and experimental.
Bun had some crazy bugs around handling environment variables where they were sort-of baked in at build time instead of evaluated at runtime but only used in some circumstances. I never got to the bottom of it but it was weird enough to put me off Bun because there was clearly something very wrong there and the documentation wasn’t helpful.
Deno worked great. There was one bug I experienced caused by inheriting a node_modules directory that caused it to crash while building, but the fix was released a few days after it was reported.
It’s definitely not as mature as Node, but it’s good enough that I would try it by default for new projects now.
I dismissed Node because it was a super-manual process and experimental.
Bun had some crazy bugs around handling environment variables where they were sort-of baked in at build time instead of evaluated at runtime but only used in some circumstances. I never got to the bottom of it but it was weird enough to put me off Bun because there was clearly something very wrong there and the documentation wasn’t helpful.
Deno worked great. There was one bug I experienced caused by inheriting a node_modules directory that caused it to crash while building, but the fix was released a few days after it was reported.
It’s definitely not as mature as Node, but it’s good enough that I would try it by default for new projects now.
That's what I've found too. Bun has bugs and definitely shouldn't have had a 1.0 release and been called "stable." Bun also has some benchmarks where they weren't exactly correct [0]. Deno on the other hand just works. I wonder if it comes from the respective languages that each use, ie Rust favors correctness while Zig doesn't necessarily.
[0] https://twitter.com/deno_land/status/1562771000802279425
[0] https://twitter.com/deno_land/status/1562771000802279425
> Rust favors correctness while Zig doesn't necessarily
I wouldn't pin this on the language, see TigerBeetle as a counter example.
https://github.com/tigerbeetle
I wouldn't pin this on the language, see TigerBeetle as a counter example.
https://github.com/tigerbeetle
Why not on the language? Rust has a borrow checker explicitly to avoid problems that are present in C, C++, and even Zig, such as using after free. Just because you can write mission critical software in a language doesn't mean that that language favors correctness. The language must be designed to do so.
To be clear, the domain of correctness is broader than memory safety.
For example, TigerBeetle follows NASA's The Power of Ten Rules for Safety-Critical Code. We require that memory allocation failure be explicitly handled in the control flow, and that no dynamic memory allocation be used after initialization, that all resources (including memory) be explicitly limited, with no hidden allocations.
Our language choices then came down to C or Zig. Zig made most sense.
Zig's correctness philosophy (e.g. extremely explicit control flow) may be different to other languages. But Zig resonated with our own philosophy—in addition to the big examples already given above, we also noticed the little things (e.g. checked arithmetic enabled by default in safe builds).
For example, TigerBeetle follows NASA's The Power of Ten Rules for Safety-Critical Code. We require that memory allocation failure be explicitly handled in the control flow, and that no dynamic memory allocation be used after initialization, that all resources (including memory) be explicitly limited, with no hidden allocations.
Our language choices then came down to C or Zig. Zig made most sense.
Zig's correctness philosophy (e.g. extremely explicit control flow) may be different to other languages. But Zig resonated with our own philosophy—in addition to the big examples already given above, we also noticed the little things (e.g. checked arithmetic enabled by default in safe builds).
I've enjoyed trying to use Deno for a small new service at $WORK. Sadly had to give up and retreat back to Node due to missing support for private NPM repositories and lack of Datadog tracing support.
Their compatibility is getting better and better, so I'm confident Deno will eventually be a clear "better Node".
Their compatibility is getting better and better, so I'm confident Deno will eventually be a clear "better Node".
One use case where pure Deno works for me is shell scripts. Writing them in Deno is quite pleasant and they usually don't need many dependencies. Plus you can always host then and just "deno run <url>" from any machine that has it. It used to be a problem that you had to know permissions ahead of time but now they interactively ask you for it which makes the scary "-A" flag much less needed.
You can also compile them to standalone executables easily with `deno compile`.
I wonder how that works, do they ship the entire Deno runtime with the executable à la Electron?
Yes, a `console.log()` compiles to a 78.46MiB .exe
Wow, sounds like I'll stick with Rust.
What was the issue you encountered with private registries on Deno? Based on Deno's docs, it looks like they're supported[0]
[0] https://docs.deno.com/runtime/manual/basics/modules/private
[0] https://docs.deno.com/runtime/manual/basics/modules/private
What I'm looking for is the equivalent of this .npmrc contents to access an NPM module on Github Packages:
//npm.pkg.github.com/:_authToken=${AUTH_TOKEN}
@myEmployer:registry=https://npm.pkg.github.com/
Here is the relevant Github issue with a better explanation:
https://github.com/denoland/deno/issues/16105
https://github.com/denoland/deno/issues/16105
Now that there is also bun, both javascript tooling/runtime ecosystem will improve faster, now there are 3 competing mainstream runtimes (but as now the only one that is production ready imho is node)
Deno is great. I wish the maintainers were open to moving some of the great functionality from the CLI into separate libraries, but I understand how that might not be desirable from business perspective.
if you didn't know already, it's very easy to roll your own JS runtime with whatever bits you need using deno_core crate.
https://deno.com/blog/roll-your-own-javascript-runtime
Tangentially related: what is the benefit of Deno KV over something like S3? I see option for atomic transaction, which is nice, but otherwise fewer features for far higher cost. Is it mostly speed?
Deno KV seems more like a redis alternative and not an S3 alternative. The benefit seems to be that it’s built into the runtime itself
It's half about using Deno Deploy and needing a way to store persistent data across edge servers and half about having a database you can just use in your own runtime.
Of course there's a lot of other databases, but we programmers forget that for beginners it is setting up the DB which is the barrier to entry.
Of course there's a lot of other databases, but we programmers forget that for beginners it is setting up the DB which is the barrier to entry.
I think DynamoDB would be the more apt comparison.
Are there web apps that just use S3 and no database? How does that work?
Still don’t fully understand what ‘runtime’ means in this context. It’s not the parser, interpreter, VM, GC I think, because that is the V8 part. It’s not a runtime compiled into an executable like Haskell or Go.
Is it the term used here for a set of standard libraries? Or maybe in interaction layer with the operating system underneath, or the package/build system? Or an umbrella term for all of this?
I’ve been doing all kinds of JavaScript and TypeScript for a long time now without a runtime (I think) so pretty curious.