I'm not convinced you actually watched that video. He describes his passing comment as "this is mostly a thought experiment" and only remarks that there was no attempt at compatibility with existing systems, which is clearly disproved by this discussion.
I feel you're just trying to be contrarian and a poorly sourced zealot.
That first half is essential for understanding the second half. It sounds like a passing comment if you didn't watch both segments because he's assuming you already have the context for why he's ditching node.
Since you're assuming bad faith I won't be monitoring this thread any more. If you'd like to have longer, substantive discussions on HN, I'd suggest knocking off the name calling.
> > [In] Deno I want to simplify the module system, so screw all this stuff about how Node modules work... it can't be compatible with Node, otherwise you end up building Node, so there's no attempt at compatibility with existing software.
I think that Deno's module system is still incompatible with Node's: supplying a node_modules directory of files in your project root, at run time or at build time, still won't work. Deno is now just doing the work to ingest npm packages and process them into Deno modules at build time, if you want to use them. That doesn't seem out of line with Dahl's vision to me.
> Linking to a package requires a lot of components, a lot of systems. The problem that I have with [package.json] is that it gives rise to this concept of a module as this directory of files, where that wasn't really a concept before, where we just had JavaScript files. ... It's not a strictly necessary abstraction. And package.json has all this unnecessary noise in it.
> ...
> [In] Deno I want to simplify the module system, so screw all this stuff about how Node modules work... it can't be compatible with Node, otherwise you end up building Node, so there's no attempt at compatibility with existing software.
[0] https://youtu.be/M3BM9TB-8yA?t=1256