4 ms·

Having a feature is not the same thing as having API compatibility with Node's implementation of the feature. I think people are worried that an exciting projec

by dkarl 3y ago

Having a feature is not the same thing as having API compatibility with Node's implementation of the feature. I think people are worried that an exciting project that aimed to have a different approach and a different set of trade-offs from Node will end up having to support everything that Node does, possibly inheriting its trade-offs and losing the freedom to innovate that they started with. Even if there's no technical trade-off, it does seem that most of their engineering efforts will be focused on backwards compatibility with Node, instead of the new vision that they were promising.

bredren 3y ago
I’ve seen this type of thing in vanilla js vs react projects. Where there was a fine vanilla js implementation, but it was abandoned by maintainers to do a react version. Or a new frontend package is built for react by default rather than vanilla js, (or a very light set of js dependencies) even if it easily could have been. And my experience is that react has been corruptive to the vanilla js ecosystem as a result. It’s a bit of a reverse from node->deno but I could easily see how deno would be stunted or affected in an unknown but possibly not great way by this. All that said, Deno has had to pivot because node seems to have gotten its act together to some extent. At least compared to when Deno set out. So as a practical user acquisition need, not want but need, Deno had no choice but to do this. And the decision to go down this path was made quite a while back, iirc. I remain hopeful for Deno and the team behind it. Frontend tech is very competitive. The thrashing across the frontend stack that backend folks recoil from has made things stronger and there’s a lot of talent at work.
tracker1 3y ago
I think that most wanting to use Deno are wanting to write an application in a more Deno friendly way. Linting, formating, and typescript in the box. But pragmatically also needing or desiring to be able to utilize existing NPM modules. Those NPM modules more often than not needing node compatibility. It doesn't mean the application at its core will be more node based so much as wanting to be able to use a given NPM module.

by dkarl 3y ago

bredren 3y ago

I’ve seen this type of thing in vanilla js vs react projects. Where there was a fine vanilla js implementation, but it was abandoned by maintainers to do a react version. Or a new frontend package is built for react by default rather than vanilla js, (or a very light set of js dependencies) even if it easily could have been. And my experience is that react has been corruptive to the vanilla js ecosystem as a result. It’s a bit of a reverse from node->deno but I could easily see how deno would be stunted or affected in an unknown but possibly not great way by this. All that said, Deno has had to pivot because node seems to have gotten its act together to some extent. At least compared to when Deno set out. So as a practical user acquisition need, not want but need, Deno had no choice but to do this. And the decision to go down this path was made quite a while back, iirc. I remain hopeful for Deno and the team behind it. Frontend tech is very competitive. The thrashing across the frontend stack that backend folks recoil from has made things stronger and there’s a lot of talent at work.

tracker1 3y ago

I think that most wanting to use Deno are wanting to write an application in a more Deno friendly way. Linting, formating, and typescript in the box. But pragmatically also needing or desiring to be able to utilize existing NPM modules. Those NPM modules more often than not needing node compatibility. It doesn't mean the application at its core will be more node based so much as wanting to be able to use a given NPM module.