That new bench reporter is really something to look at
Tracking where open resources like timers were invoked is something that is quite literally a game changer People sleep on how good the Deno test runner is, but I can't for the life of me stress enough how many times…
"Immutable" in the sense that packages can't be taken down or modified by authors If you wanna take it a step further, you can always opt in to that lock file with various degrees of strictness as you yourself mentioned
Hence why developers always recommend to use immutable sources when importing modules
They don't though. They transpile it behind the scenes
They are different, currently no Deno registries have dynamic version resolution (no greater than operator). Once you have locked in on a version you are in it for good unless you change it manually However if the…
Reimplement in the way that they change certain rules to accommodate a more "modern JS" feel And they absolutely use TS for the std library, just not in the runtime itself
You don't need to test a feature that they don't have
Wrong, 1.0 released exactly one year ago, before there was mostly destabilization of the runtime and not really development features
We may have WebGPU powered desktop applications in the near future though. Let's see how things play out, as you daid
There have been multiple test runners built on top of Deno's vanilla testing (through the JSON output feature), those may fit your use case better The current multi threaded and module isolated model however I think…
IMO this is a terrible idea. If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long…
Only if you update dependencies, a fresh install would not have such integrity checks, so it's just as vulnerable as Deno hosts to such attacks
No they can't, Deno is JavaScript compliant
For frontend TypeScript I assume you mean TypeScript that doesn't use JS modules but extensionless modules, the TypeScript folks sadly have decided to not bring compatibility here ATM.
You do something like this export * as Oak from "https://deno.land/x/oak/mod.ts"; export * as Postgres from "https://deno.land/x/postgres/mod.ts"; Then you do this: import { Oak, Postgres } from "./deps.ts";
Yeah, libraries can't use import maps because import maps are not extensible
You don't ever lose productivity or knowledge on a tool when a new one comes out though. A new thing that people like becomes popular and people start using it, old one becomes less used but it doesn't dissapear. You…
They had to remove it from the Deno build process so Deno internals didn't need a compiler. However TypeScript support remains untouched and receives constant updates
This. I cannot stress how important is this for modern app development. Just like Deno doesn't trust any script that is passed to it, no user should trust an app just cause it's installed directly in the system (and I…
The thing is that without read/write or net permissions, a malitious script that turns your computer into a mining rig will throw because it can't connect to any server or use your filesystem. We already expose CPU to…
No matter if you are interested in Deno or not, seeing this amount of features in a year alone gives you an idea of what's to come for Deno in the future
The catch is that it works in a case by case basis. The most used libraries are there and work wonders, but things like the Vue compiler won't work with NPM transformations and are better off with a native port, like VNO
Actually that is being worked on (std/node is a shim for Node libraries that aims to make Node ecosystem 100% usable from Deno) but the idea is to build software with Deno's mindset and features on top of it. Just look…
Fundamentally, Deno works way more like the language JavaScript is meant to be according to the vision of the ECMA committee (the ones who add features to the language). Problem is that a lot of software was built upon…
That new bench reporter is really something to look at
Tracking where open resources like timers were invoked is something that is quite literally a game changer People sleep on how good the Deno test runner is, but I can't for the life of me stress enough how many times…
"Immutable" in the sense that packages can't be taken down or modified by authors If you wanna take it a step further, you can always opt in to that lock file with various degrees of strictness as you yourself mentioned
Hence why developers always recommend to use immutable sources when importing modules
They don't though. They transpile it behind the scenes
They are different, currently no Deno registries have dynamic version resolution (no greater than operator). Once you have locked in on a version you are in it for good unless you change it manually However if the…
Reimplement in the way that they change certain rules to accommodate a more "modern JS" feel And they absolutely use TS for the std library, just not in the runtime itself
You don't need to test a feature that they don't have
Wrong, 1.0 released exactly one year ago, before there was mostly destabilization of the runtime and not really development features
We may have WebGPU powered desktop applications in the near future though. Let's see how things play out, as you daid
There have been multiple test runners built on top of Deno's vanilla testing (through the JSON output feature), those may fit your use case better The current multi threaded and module isolated model however I think…
IMO this is a terrible idea. If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long…
Only if you update dependencies, a fresh install would not have such integrity checks, so it's just as vulnerable as Deno hosts to such attacks
No they can't, Deno is JavaScript compliant
For frontend TypeScript I assume you mean TypeScript that doesn't use JS modules but extensionless modules, the TypeScript folks sadly have decided to not bring compatibility here ATM.
You do something like this export * as Oak from "https://deno.land/x/oak/mod.ts"; export * as Postgres from "https://deno.land/x/postgres/mod.ts"; Then you do this: import { Oak, Postgres } from "./deps.ts";
Yeah, libraries can't use import maps because import maps are not extensible
You don't ever lose productivity or knowledge on a tool when a new one comes out though. A new thing that people like becomes popular and people start using it, old one becomes less used but it doesn't dissapear. You…
They had to remove it from the Deno build process so Deno internals didn't need a compiler. However TypeScript support remains untouched and receives constant updates
This. I cannot stress how important is this for modern app development. Just like Deno doesn't trust any script that is passed to it, no user should trust an app just cause it's installed directly in the system (and I…
The thing is that without read/write or net permissions, a malitious script that turns your computer into a mining rig will throw because it can't connect to any server or use your filesystem. We already expose CPU to…
No matter if you are interested in Deno or not, seeing this amount of features in a year alone gives you an idea of what's to come for Deno in the future
The catch is that it works in a case by case basis. The most used libraries are there and work wonders, but things like the Vue compiler won't work with NPM transformations and are better off with a native port, like VNO
Actually that is being worked on (std/node is a shim for Node libraries that aims to make Node ecosystem 100% usable from Deno) but the idea is to build software with Deno's mindset and features on top of it. Just look…
Fundamentally, Deno works way more like the language JavaScript is meant to be according to the vision of the ECMA committee (the ones who add features to the language). Problem is that a lot of software was built upon…