11 ms·

Better IDE support is huge. I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up,

by d4mi3n 4y ago

Better IDE support is huge. I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up, so this effectively removes a big barrier to adoption for a lot of folks. Excited to see how well Deno's security features pan out under broader, real-world usage.

MuffinFlavored 4y ago
> I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up if VS Code already supports TypeScript, what is missing?
- d4mi3n 4y ago
  The ability to infer types from NPM packages. If you have existing codebases with non-trivial apps, reworking all your dependencies makes the prospect of picking up Deno a non-starter. My understanding is prior to this release the Deno LSP didn’t have visibility into types from packages originating from NPM. Compatibility issues likely still exist, but I suspect the scope of work for an MVP substitution of Node for Deno is in the realm of possibility now when it wasn’t before.
- brundolf 4y ago
  Deno has its own language server, unfortunately. This is necessary because of a few key aspects of Deno code that are incompatible with the regular TypeScript support, and it means Deno's editor integration is often a step behind mainline TypeScript
- justinmchase 4y ago
  It did still partially work but there was some friction with resolving types from ESM modules. For example in typescript+node if you're importing another module with esm you'd still have to import javascript like so: ``` import { Example } from "./example.js" // the actual file is example.ts ``` While in Deno you actually import the typescript file ``` import { Example } from "./example.ts" ``` That difference alone was enough to trip up the built-in typescript language tool and add friction. Another thing is that Deno has a built in formatter / linter, you don't use a 3rd party tool like eslint, so having the ide just know how to do the linting and formatting is nice, the default typescript language plugin can't do that. Also, Deno formats other file types including json, yaml and markdown.
dopeboy 4y ago
As a side note, this comment in itself is interesting. We are seeing tighter integration between frameworks and IDEs, almost a reversion back to early visual studio days. Will be interesting to see how each nudge the other.
- tomtheelder 4y ago
  The coupling here is actually extremely loose. It's based around implementing an LSP server, which is editor/IDE agnostic. It trades depth of integration for breadth of support. I think it's the total opposite of the old days!

by d4mi3n 4y ago

MuffinFlavored 4y ago

> I know a lot of devs who liked the idea of Deno but weren't in a position to dump a lot of their development tooling to pick it up if VS Code already supports TypeScript, what is missing?

d4mi3n 4y ago
The ability to infer types from NPM packages. If you have existing codebases with non-trivial apps, reworking all your dependencies makes the prospect of picking up Deno a non-starter. My understanding is prior to this release the Deno LSP didn’t have visibility into types from packages originating from NPM. Compatibility issues likely still exist, but I suspect the scope of work for an MVP substitution of Node for Deno is in the realm of possibility now when it wasn’t before.
brundolf 4y ago
Deno has its own language server, unfortunately. This is necessary because of a few key aspects of Deno code that are incompatible with the regular TypeScript support, and it means Deno's editor integration is often a step behind mainline TypeScript
justinmchase 4y ago
It did still partially work but there was some friction with resolving types from ESM modules. For example in typescript+node if you're importing another module with esm you'd still have to import javascript like so: ``` import { Example } from "./example.js" // the actual file is example.ts ``` While in Deno you actually import the typescript file ``` import { Example } from "./example.ts" ``` That difference alone was enough to trip up the built-in typescript language tool and add friction. Another thing is that Deno has a built in formatter / linter, you don't use a 3rd party tool like eslint, so having the ide just know how to do the linting and formatting is nice, the default typescript language plugin can't do that. Also, Deno formats other file types including json, yaml and markdown.

dopeboy 4y ago

As a side note, this comment in itself is interesting. We are seeing tighter integration between frameworks and IDEs, almost a reversion back to early visual studio days. Will be interesting to see how each nudge the other.

tomtheelder 4y ago
The coupling here is actually extremely loose. It's based around implementing an LSP server, which is editor/IDE agnostic. It trades depth of integration for breadth of support. I think it's the total opposite of the old days!