Deno 1.0: What you need to know | Hacker News Reader

Deno 1.0: What you need to know

blog.logrocket.com

60 pointsjeremiahlee11 comments

I thought the point of TypeScript was to transcend certain limitations of the JavaScript language, while still being able to write for browsers.

It’s a bit awkward, you have a transpile the script, and generate source maps to debug it, but hey, that’s life in a browser.

So if you’re not stuck in a browser, and can run any language you want, why in the world would you do all that?

This is not about TypeScript per se but about providing a more standards-based alternative for the Node.js JavaScript eco-system for non-browser environments.

I am beginning to think the JavaScript ecosystem for non-browser environments is a deepening spiral.

Learning another language does require effort, but the increasingly circuitous machinations being invented to continue using browser scripting technologies outside the browser are starting to seem like even more effort.

Plus, those efforts yield skills that only apply within the contrivance. A second language would apply more broadly, and probably be more edifying.

Makes sense. But on the other hand JavaScript is currently more important than just another script-language for browsers. Browser has become the universal GUI platform. You want your application be usable over the web. So there's a lot momentum behind JavaScript, and also lot of effort to make it better.

Presumably, for the same reason it would be convenient for me to write in a non-javascript language for the browser: I've already invested in X lang, it would be nice not to have to keep current in two languages if someone is trying to port my vm to another platform [0]. <Edit to add> On the other hand, I'm chastened by the lifecycle of projects like Jython, that can only survive with maintainers who are well versed in two runtimes, which is apt to be a small intersection.

[0] https://blog.codinghorror.com/the-principle-of-least-power/

tl;dr A creator of node.js and others have made a new runtime and ecosystem [1] (via rust) for EcmaScript that also bundles a Typescript transpiler. Rather than utilize npm, deno dependency files call out specific uris, rather than an abstract package and assuming it is on a central server. In service of letting a user choose the sandbox boundary, the interpreter requires disabling security features (ex file IO) via the run args or a config file.

[1] https://github.com/denoland

This looks absolutely fantastic!!

For some reason I assumed Deno was an "experimental" project, didn't realise it would be released so soon.

* Use TypeScript without transpilation

* Need explicit permissions for filesystem, network etc

* Extends JS standard library with useful modules like fetch, logging etc

* Builtin tooling like test runner, formatter etc

or can be both. node got pretty stable in so far as the very core pretty quick.

If I'm not mistaken, it still transpiles TypeScript to Javascript. It just has the TypeScript compiler built into deno itself, but the transpilation step is still happening (just kind of invisibly to the user).

Isn't that the best part?

No more tsconfig files and all that nonsense.

Typescript is a great language and it has a direct target for development now.

For now the combo of a Rust backend with native TypeScript support means that type safety can be expected (but not enforced) and disabling access to net and system by default does improve on Node's behaviour and reduces the risk of importing a module that takes over the host system.

This is tempting... but now my question is: what will Deno do or have that will make those who've invested years in Node consider switching?

Wish it had a better name to gain more attention.

Reply on news.ycombinator.com