Comment by brundolf | Hacker News Reader

Comment by brundolf | Hacker News Reader

Parent Full thread

It isn't a framework, it's a runtime. You use it instead of Node, and the headlining feature is you can run TypeScript without a separate build step. The system APIs are different than Node's but those are analogous/easy to learn, and the language itself is still just JavaScript/TypeScript, so there isn't really much to learn.

With that said: I've used it for a couple projects because I'm really interested in its value-proposition, but so far I'm not impressed with the dev experience when it comes to editor integration. It brings its own language server because it has a few tiny caveats, and the language server doesn't work nearly as well as the official TypeScript one. Type changes sometimes don't propagate across files, auto-imports are lacking the file extension (which Deno requires, so you have to go and manually edit them all), etc. Given that frictionless TypeScript support is the major draw, this is a pretty serious issue for me.

I hope it gets there some day, but for me it isn't there yet.

Sorry you've had this experience -- the LSP is improving a lot with every release, this one included, try it out and let us know what you think. We really appreciate issues for the LSP on GH

Thanks- I should probably actually file bug reports :)

I am curious though: why roll your own? It seems like the only real differences are a) URLs/file extensions in the module names, and b) some type declarations for the system APIs (which I'd think just come down to some .d.ts files, not custom LSP logic). Microsoft's TypeScript language server is a wonder of engineering, and I doubt any small independent team would ever be able to go toe-to-toe with it. Seems like a waste to forego that if there's any possibility of utilizing it. A minimal fork maybe, if nothing else?

TypeScript does not actually have a native language server. TSC is just directly shoehorned into VS Code. It is very difficult to extend (we tried with the 1.x and 2.x branch of our extension). We needed to do a lot of trickery to get TSC to do what we want, and even then it would not always work. That solution also only worked on VS Code. Our new LSP works on all editors with LSP support. We are hoping that in the coming few weeks / months the Deno LSP will be just as featureful as TSC + Node in VS Code, and way more performant. We still have some ways to go, but we are slowly getting there.

Ah gotcha, that's unfortunate that they integrated it directly, though it explains a lot.

Well I'm glad to hear it's a priority. Best of luck, and I'll try to check in periodically and see how things are coming along! I would very much like to see this project succeed :)

This is only partially true. TypeScript does have tsserver built in, which is where the language server design originated from (just with a slightly different API). The VS Code TypeScript integration is a layer around that, not a custom implementation. There are also a couple other TypeScript language servers out there (which again simply wrap tsserver and translate the APIs) which work great.

There's a couple of reasons. Internally, there's quite a few things that we do in Rust that aren't actually taken care of by TypeScript -- Having our own LSP allows us to connect those bits (like the module graph resolver for example) directly to the internals of Deno, in-sync with the Deno version you have installed.

Deno also does more stuff than just providing Type definitions, embedding TypeScript and doing module resolution; it's a complete toolset -- there's things that we can cover having our own LSP that the TypeScript LSP can't. Linting, formatting, testing etc.

Reply on news.ycombinator.com