Hacker News Reader

Comment by GenerocUsername | Hacker News Reader

I 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?

View on HN

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.

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.

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 :)

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.

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!

Maybe because there are way more JS frameworks than runtimes. It feels like dozens of frameworks pop up every day.

Yes but my point is that this doesn't address the OP's frustration: learning new APIs without a clear sense of what one is getting out of it. Many of Deno's fundamental features are basically framework features. Learning the Deno for-await API for answering HTTP requests is an identical experience to learning a framework that offers that API. "But Deno has fundamental performance improvements" -- Frameworks can also offer fundamental performance improvements. In fact, I can write a Rust-backed binary package for node.js and now we're really in a grey area.

The point is that "its a runtime not a framework" is not an answer as to why he should learn it or not. At least, not without attaching to it a meaningful explanation as to the benefits he'll get from it because its a runtime, but at that point, we're back where we started: just pitch him on what he'll get out of it, don't correct him on technical terminology.

Frameworks tend to dictate a certain way of doing things and introduce a pile of their own concepts and abstractions. Runtimes tend to be unopinionated. There's very little learning-fatigue around Deno, and there's almost no choice-fatigue since it's only the second mainstream (non-browser) JS runtime.

Perhaps in the general case, but Deno is probably as opinionated or more so than your average JS framework choice on node.js. And certainly more opinionated than a more "neutral" runtime change like when Microsoft made the Chakra-backed node.js. For example, choosing to go with Deno cuts you out of much of the npm ecosystem (either due to the specific module model, or simply because the fundamental APIs are different, which is why express won't run "out of the box" on Deno -- there had to be ports of express and koa, etc.), which certainly is a bigger side-effect than switching from React to Vue. It also, to its credit, bets big on Typescript, a very opinionated decision (and I'd argue a good one too!). It bets big on async/await (which is still somewhat contentious in the node.js community, but luckily fading). In other words, there's not a lot of information conveyed from "it's a runtime not a framework," at least not in this case, aside from technical aspects. And again, I think it is precisely worth pitching it on its opinions, like the browser-compatible APIs, etc.

Well, Deno's not really a framework, it's a runtime (like node.js). If you're writing Typescript, it makes that way easier. If you're doing lots of IO, it makes that easier (promises). If you want sandboxing, it has that (though if it's for server software, you should use firejail or Docker or something around it anyway).

does it interop with libs made for node.js and are on npm? e.g. using the official the AWS node.js library

It doesn't load libs from NPM directly, it has its own package management system based around URLs. Most JavaScript/TypeScript logic should port to it trivially, unless they use system APIs, in which case those will have to be converted to Deno's system APIs. But mostly that just comes down to "swap out function X for Y and rearrange the parameters a bit".

So in practice: it's super easy to port something, but most of the time you do actually have to port it, unfortunately.

The canonical answer is _maybe_. If your Node lib relies on Node built-ins, you won't be able to import it directly from GitHub for example. However, CDNs like Skypack and esm.sh do polyfill some of those to Deno. Your mileage may vary depending on the lib you're trying to import. Some will work better on one CDN, some on another -- you really just have to try it for yourself. A surprising amount of libs work without issues.

The AWS sdk v3 works really well from Skypack, check out our docs for our Deploy platform, it has an example with DynamoDB https://deno.com/deploy/docs/tutorial-dynamodb#write-the-app...

Can't comment on sibling, but https://www.skypack.dev/ lets you import many npm packages; I haven't tried the AWS library, though.

That looks pretty cool; it's unsurprising that there's an automated solution since the differences are so small and predictable

Edit: Does this do automated conversion? I can't actually tell

Yes, it's automated.

Deno isn't a framework, it's a node.js alternative. The best pitch I've heard is that it's written by the same guy who did node.js, with the intent to fix everything he thought he got wrong with node.js.

Good news.

Deno tries to be as close to the browser API as possible. So it's easier to learn than Node.js if you come from frontend development.

You're getting a lot of responses. I just want to say that I empathize with you.

I'm not at that point in my life where new technologies don't excite me. I'm still happy to learn new things. But I fully expect I'm going to get tired of the next wiz bang language, the next gee wow framework, the next hot stuff server. I get it.

There's still value in knowing what you know. I wish people didn't think so much otherwise.

It's not a framework, it's a JS runtime on top of v8 (like node).

short_anecdote: don't switch, it's not for you!

Is it technically a framework? I thought it was an entire alternative runtime to NodeJS.

Deno has first-class support for TypeScript. Refactoring code without types is not a pleasant experience.

Deno isn't a JS framework?

You mean it's a runtime, like Node.js? /s

I guess roughly a billion people were just as triggered as I was and now there are all these redundant "actshually" comments :D

That's a rather ignorant thing to say.

You are basically saying "I feel like I have hit a point in my life where I don't want to learn."

It doesn't matter if it's a framework, language, protocol, specification, book, way of coding, or anything else. Learning is how you gain knowledge and stopping ones desire to gain knowledge is never a "point in ones life". It's just being lazy.

Then why are you on here blathering about someone being ignorant when you are being "just as lazy" and not spending this time learning new$x.js instead of arguing on the internet?

Have some compassion/empathy for those of us that don't have the luxury to be able to constantly keep up with what gets churned out every day.

Who said anything about compassion/empathy?

There is a difference between saying I won't try and convivence me otherwise. Versus saying I can't I don't have the time.

OP is very clearly saying I won't, they have given no indication as to the fact they don't have time to learn.

Kind of a leap to go from not wanting to learn the JavaScript techology du jour to not wanting to learn anything.

Reply on news.ycombinator.com