I don't want to be overly critical of a very well-intentioned and worthy effort, but it is looking less and less to me like Ryan and the rest of the Deno team understand what problems node.js developers care about. Specifically:
1. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don't recall hearing about a lot of security issues that could have been prevented by this. I mean, I suppose this won't hurt anyone, but it's certainly never something that I've wanted. I expect most people will simply white-list most access by default in all new projects.
2. deno bundle: Initially, when I heard about this, I was excited. The need to bundle code via webpack and similar systems is one of the worst things about front end browser development. It introduces tons of complexity and makes debugging much harder. So I thought, wow, maybe deno is going to just give us a first-class solution to this problem that will just work. Nope. They are only concerned with bundling code such that it can be run elsewhere by deno. A friend put it thus: "we don't want bundlers anymore, so we're making deno bundle, the one true bundler!" "does it do any of the stuff that webpack does?" "mostly no, because it's not meant for that" Read the comments on https://github.com/denoland/deno/issues/2475 to get a sense of what I'm complaining about.
3. URL Imports. Packages in node.js are stupendously easy to use. Making me import from a URL instead of typing `yarn add foo` and `import * as foo from 'foo'` does not make my life any easier. It certainly makes the implementation easier, and I'm glad to see the last of node_modules and path-climbing module resolution. But the URL-based system offers no equivalent that I can see to lock files and automatic upgrades (e.g. `yarn upgrade`), which are two crucial features. This is something that node developers need and want, and if Deno doesn't provide it, 3rd parties will. My worry is that we'll end up with competing third-party solutions and a fractured ecosystem, due to Deno's failure of leadership here.
4. Stack traces: The single worst thing about using node is the frequency with which you get utterly useless stack traces that tell you nothing about the true source of the error. It was easier to debug C++ programs 20 years ago that it is to debug node.js apps today. But as far as I can tell, deno isn't making any efforts to improve this. That's ok, they don't have to fix every problem. But it does make me worry that they don't know what node.js developers actually care about, if this wasn't on their "must fix" list.
5. Typescript by default. I really like typescript. I mostly want to use it instead of javascript these days. But tsc is slow. Slooooooow. Really really slow. I am worried that most deno programs are going to be very slow to start up in practice. (Before you say "caching", 99% of the time that you want to start a program, it's because you just changed the source code. caching can only do so much in this case). And I am extremely skeptical of the plan to build a new typescript compiler in rust.
I'll conclude with praising a few things that I am very glad to see: No more node_modules, Web APIs, and a promise-based stdlib.
1. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don't recall hearing about a lot of security issues that could have been prevented by this. I mean, I suppose this won't hurt anyone, but it's certainly never something that I've wanted. I expect most people will simply white-list most access by default in all new projects.
2. deno bundle: Initially, when I heard about this, I was excited. The need to bundle code via webpack and similar systems is one of the worst things about front end browser development. It introduces tons of complexity and makes debugging much harder. So I thought, wow, maybe deno is going to just give us a first-class solution to this problem that will just work. Nope. They are only concerned with bundling code such that it can be run elsewhere by deno. A friend put it thus: "we don't want bundlers anymore, so we're making deno bundle, the one true bundler!" "does it do any of the stuff that webpack does?" "mostly no, because it's not meant for that" Read the comments on https://github.com/denoland/deno/issues/2475 to get a sense of what I'm complaining about.
3. URL Imports. Packages in node.js are stupendously easy to use. Making me import from a URL instead of typing `yarn add foo` and `import * as foo from 'foo'` does not make my life any easier. It certainly makes the implementation easier, and I'm glad to see the last of node_modules and path-climbing module resolution. But the URL-based system offers no equivalent that I can see to lock files and automatic upgrades (e.g. `yarn upgrade`), which are two crucial features. This is something that node developers need and want, and if Deno doesn't provide it, 3rd parties will. My worry is that we'll end up with competing third-party solutions and a fractured ecosystem, due to Deno's failure of leadership here.
4. Stack traces: The single worst thing about using node is the frequency with which you get utterly useless stack traces that tell you nothing about the true source of the error. It was easier to debug C++ programs 20 years ago that it is to debug node.js apps today. But as far as I can tell, deno isn't making any efforts to improve this. That's ok, they don't have to fix every problem. But it does make me worry that they don't know what node.js developers actually care about, if this wasn't on their "must fix" list.
5. Typescript by default. I really like typescript. I mostly want to use it instead of javascript these days. But tsc is slow. Slooooooow. Really really slow. I am worried that most deno programs are going to be very slow to start up in practice. (Before you say "caching", 99% of the time that you want to start a program, it's because you just changed the source code. caching can only do so much in this case). And I am extremely skeptical of the plan to build a new typescript compiler in rust.
I'll conclude with praising a few things that I am very glad to see: No more node_modules, Web APIs, and a promise-based stdlib.