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.