> This month we made a hard decision to convert our internal runtime code from TypeScript to JavaScript. There were several factors that led us to this decision: Complicated and slow build process on each build of the Deno internal runtime code was typechecked and bundled before being snapshotted.

Woah

There was a design doc[1] that described the problem and some subsequent discussion that goes beyond the GitHub PR history, and a HN thread[2] 6 months ago.

[1] https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...

[2] https://news.ycombinator.com/item?id=23592483

Nice now they replaced slow build times with nightmare maintenance/refactoring capabilities.

Have you read their docs on the decision? Typescript was actively hurting their development

I want to give the deno folks a shoutout

I've been learning ES5 for work, and I wanted to get better at more modern JS while I was at it. I decided to write JS solutions for Advent of Code and had to choose between deno and node.

My preferred way of running an advent of code challenge is to pipe in the problem input. I ended up using deno cause it was a lot faster for me to figure out how to make that happen (as somebody who's only used browser-side JS)

> This change had a significant impact on the module ecosystem, making some popular modules unusable until maintainers adjusted the code to work with isolatedModules.

Does this mean Deno introduced a breaking change in a minor version (1.5.0)?

Looking at the linked blog post, it seems to be behind the --unstable flag, so it’s opt in currently. I guess it’ll be the default in 2.0?

So far very impressed with Deno. Oak is cool too.

No Intl support and no http2 have been a drain this year but those seem to be coming soon as they are on the Q1 2021 roadmap.

The import/module system is great. Can all tooling convening on including extensions in imports (looking at you TypeScript)

It's not clear to me if this is now a Rust wrapper around a C++ implementation, or if it's completely Rust.

V8 is still in C++, but the wrapper, in my understanding, is all Rust now.

Still no Node or npm compatibility? Not even on their roadmap? Still think Deno is DOA, then.

TypeScript is great, sure. I love TypeScript. But I wouldn't touch Deno for just about any serious development if I couldn't be certain that I could search npm for a library and use it without a potential hassle.

It's like wanting to convert a Tesla into a hybrid. Replacing npm with url imports was one of the main motivations to create deno. I don't miss npm at all. I am happy that I don't have to deal with it anymore. But if you want npm you can just continue using node.

What issues were npm giving you?

Most of the issues are just stemming from its centralized nature. Typo squatting for example and other security issues. Beyond that the whole ecosystem around npm is just so bloated. The amount of data you have to pull for any tiny project is ridiculous.

Granted some of those issues is just down to growth of the ecosystem, so it could happen to deno as well. But my hope is that deno community will not repeat most of past mistakes. And it's decentralized nature will help with that.

Npm is great, but it's not ideal to structurally depend on a centralized service for normal functioning.

So it's doa because it shedded some fairly major legacy tech debt in npm and the commonJS format?

While I have concerns about the dependency management style of deno being looser than node's package.json, I do think it is a net positive with realigning to "web standard library" over reinventing interfaces for everything.

This is the greatest reason to switch to Deno. NPM is, in most cases, a dumpster fire. If you need 1000+ dependencies to write a couple lines of code you have failed and I want nothing to do with you, your team, or any of your code.

If Deno succeeds it will be no different.

Not so sure of that - if only because it aims to have a pretty reasonable stdlib built-in.

There is a compatibility library https://deno.land/std@0.83.0/node. But they're at about 10 out of 35 for the Node Standard Lib. And There is no way to handle Node libs that use node-gyp - although I don't think that's _most_ modules.

If they finish the compatibility layer, I think that's enough for most scenarios.

> Still think Deno is DOA, then

Never has there been a community as obsessed with the new hotness as the JS one. People will use it just so they can say they do

That can’t keep a project alive.

Next year something else is the new hotness and the people who like that move on.

What do you need npm for when you can just import modules from skypack or some other cdn?

Even if you don’t use the npm CLI per se, the npm ecosystem is huge. Losing access to that is a really big deal.

Most of it isn’t Typescript though.

And even what's typescript is only usable as javascript+.d.ts. Each package has it's own tsconfig.

How does skypack work? Does it have automatically what npm has?

No NPM support is by far the best thing about Deno for me.

You can use all of npm in deno if you link to them via www.skypack.dev

Deno is beginning to look like an interesting alternative to Nodejs, now that their api is stabilizing. Trying it out is on the roadmap for this year.

There was a post on HN yesterday about Rust not having a strong web ecosystem yet, especially for writing web API libraries and working directly with microservices.

I wonder if and how Deno solve that?