> 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.<p>Woah
I want to give the deno folks a shoutout<p>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.<p>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.<p>Does this mean Deno introduced a breaking change in a minor version (1.5.0)?
So far very impressed with Deno. Oak is cool too.<p>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.<p>The import/module system is great. Can all tooling convening on including extensions in imports (looking at you TypeScript)
Still no Node or npm compatibility? Not even on their roadmap? Still think Deno is DOA, then.<p>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.
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.<p>I wonder if and how Deno solve that?