Deno 1.27
deno.com
Deno 1.27
1–10 of 71 posts
Re: Deno 1.27
#2Better 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.
Re: Deno 1.27
#3It seems to be down for me and for some reason the domain is not indexed by the web archive.
Re: Deno 1.27
#4Better 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.
> 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?
Re: Deno 1.27
#5Better 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.
> 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?
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.
Re: Deno 1.27
#6As a Jetbrains user, somewhat annoying to see everything in VS Code.
Re: Deno 1.27
#7I'm an eager and early adopter of Deno. I however look forward to ecosystem improvements, and the interop with npm is helpful. I was working on a side project recently that was a simple CRUD app and I just ended up going with Express on Node after fighting with Oak on Deno for a few days. It was still in the way enough to slow down the rapid fire development process that happens when you're still figuring out an idea.
Re: Deno 1.27
#8As a Jetbrains user, somewhat annoying to see everything in VS Code.
Our editor integration is completely editor agnostic. Deno implements the Language Server Protocol [1], which essentially all editors support. Because of this the new inlay hints feature, is supported on all editors that support inlay hints and use our LSP integration. The Jetbrains integration for Deno uses our LSP, but I don't know if they support inlay hints yet.
You can find docs on using Deno LSP with other editors here: https://deno.land/manual/getting_started/setup_your_environm...
Re: Deno 1.27
#9Better 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.
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.
Re: Deno 1.27
#10Excited for the improvements, some big wins there!
But surprised to see so many removals in the Changes section to what seems to be a minor version of a 1.x release. Nothing that hurts me personally, altho not Semantic Versioning and cautions shaky ground to build on?