Have they resolved issues where many third party packages are not available for Deno? Like i don't see things such as MikroORM/Pino/Firebase-Admin on deno.land, and even things like AWS-SDK are out of date.
Deno 1.9
21–30 of 245 posts
Re: Deno 1.9
#22Earlier quoted context omitted.
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 val…
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?
Re: Deno 1.9
#23I feel like I have hit a point in my life where I don't want another framework to learn, and due to this I am not giving Deno a fair shake... Does anyone have a short anecdote why I might bother to invest in yet another JS framework?
short_anecdote: don't switch, it's not for you!
Re: Deno 1.9
#24I feel like I have hit a point in my life where I don't want another framework to learn, and due to this I am not giving Deno a fair shake... Does anyone have a short anecdote why I might bother to invest in yet another JS framework?
Deno has first-class support for TypeScript. Refactoring code without types is not a pleasant experience.
Re: Deno 1.9
#25Have they resolved issues where many third party packages are not available for Deno? Like i don't see things such as MikroORM/Pino/Firebase-Admin on deno.land, and even things like AWS-SDK are out of date.
Pro tip: don't import those libs from deno.land/x. The runtime is agnostic to where you're pulling libs from, and that's by design. The AWS SDK v3 for example works great through the Skypack CDN, and you're pulling the canonical one, not simply a port maintained by a third party.
Re: Deno 1.9
#26I feel like I have hit a point in my life where I don't want another framework to learn, and due to this I am not giving Deno a fair shake... Does anyone have a short anecdote why I might bother to invest in yet another JS framework?
Deno isn't a JS framework?
You mean it's a runtime, like Node.js? /s
Re: Deno 1.9
#27I feel like I have hit a point in my life where I don't want another framework to learn, and due to this I am not giving Deno a fair shake... Does anyone have a short anecdote why I might bother to invest in yet another JS framework?
It's really weird that most responses to you are that Deno isn't a framework, as if changing the category the thing is in would somehow magically remove your choice fatigue, especially considering that the most likely interpretation of your fatigue would make the distinction between runtime and framework fairly meaningless in this case: they are both for practical purposes a set of APIs you must learn on top of an existing language you probably already know. Whether under the hood they are implemented as Rust bindings that require you to run your app in a specific binary, vs. being written in JS, probably doesn't matter, and if anything would make the endeavor more complicated and raise the bar necessary to convince you to learn it even more.
Either way, barring your work forcing you to learn something, or you running into a specific problem that requires you to learn something new, you should really treat frameworks/runtimes/languages/etc. the same as TV shows or comics, and I mean this in a very positive way. If you enjoy it and have the bandwidth for it, then of course pick up a new show or comic and invest some time into it! Especially if a trusted friend recommends it to you. It might introduce you to new ideas or give you a different perspective. And most importantly, you probably won't get as much as you would out of it if it doesn't seem exciting. You won't miss out on it if you decide to punt it until later, I promise you. This isn't some Thanksgiving Day sale, if in a year it's more popular than it is today, there'll only be better articles and tutorials that have been written, more bugs having been fixed, and more libraries already existing for it than today. And if it ended up not being that great, you probably won't hear about it in a year anymore, and you will have spent your time on a thing you do enjoy. So don't force it, if it seems cool to you or resonates with you for any reason, try it, otherwise, no big deal!
Re: Deno 1.9
#28Earlier quoted context omitted.
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 woul…
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.
Re: Deno 1.9
#29Earlier quoted context omitted.
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 woul…
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 c…
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 :)
Re: Deno 1.9
#30Earlier quoted context omitted.
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 woul…
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.