1. The legacy language baggage of different syntaxes, bad Node APIs, non-standard import styles, etc
2. The existing ecosystem of actual packages and their capabilities
It's a good thing that Deno isn't a reboot of #2. Despite the recurring narrative on HN, the scale of the NPM ecosystem is a good thing. It's one of JavaScript's greatest strengths. I don't understand all the people complaining that they're given too many powerful and free packages to choose from. Whenever I've brought Deno up to people at work or otherwise, their major source of hesitancy for using it on real projects is (rightly) that it's lacking Node's vibrant package ecosystem: "Does it have a mature auth library? What about an AWS SDK? GraphQL server? Client? Redis library? What if we need something later that we don't know we need yet?"
As for #1- Deno is still a reboot, just a softer one. It still gives people lots of reasons to write new packages in the well-formed, web-standard-based way that Deno directly supports. NPM compatibility is a bridge to get us there gradually (because that ecosystem is so valuable, and can't be rebuilt overnight).
It was always a bold move to try and go scorched-earth, and especially with the new pressures from Bun, I think it was the right call to make this exact level of compromise.
1. The legacy language baggage of different syntaxes, bad Node APIs, non-standard import styles, etc
2. The existing ecosystem of actual packages and their capabilities
It's a good thing that Deno isn't a reboot of #2. Despite the recurring narrative on HN, the scale of the NPM ecosystem is a good thing. It's one of JavaScript's greatest strengths. I don't understand all the people complaining that they're given too many powerful and free packages to choose from. Whenever I've brought Deno up to people at work or otherwise, their major source of hesitancy for using it on real projects is (rightly) that it's lacking Node's vibrant package ecosystem: "Does it have a mature auth library? What about an AWS SDK? GraphQL server? Client? Redis library? What if we need something later that we don't know we need yet?"
As for #1- Deno is still a reboot, just a softer one. It still gives people lots of reasons to write new packages in the well-formed, web-standard-based way that Deno directly supports. NPM compatibility is a bridge to get us there gradually (because that ecosystem is so valuable, and can't be rebuilt overnight).
It was always a bold move to try and go scorched-earth, and especially with the new pressures from Bun, I think it was the right call to make this exact level of compromise.