5 ms·

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

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?

hayd 6y ago
It's not a framework, it's a JS runtime on top of v8 (like node).
johnfn 6y ago
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.
FractalHQ 6y ago
Is it technically a framework? I thought it was an entire alternative runtime to NodeJS.
remexre 6y ago
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).
- devmunchies 6y ago
  does it interop with libs made for node.js and are on npm? e.g. using the official the AWS node.js library
  - brundolf 6y ago
    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.
  - remexre 6y ago
    Can't comment on sibling, but https://www.skypack.dev/ https://www.skypack.dev/ lets you import many npm packages; I haven't tried the AWS library, though.
    - brundolf 6y ago
      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
      - remexre 6y ago
        Yes, it's automated.
  - wperron 6y ago
    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-application https://deno.com/deploy/docs/tutorial-dynamodb#write-the-app...
turbinerneiter 6y ago
Deno isn't a JS framework?
- tannhaeuser 6y ago
  You mean it's a runtime, like Node.js? /s
  - turbinerneiter 6y ago
    I guess roughly a billion people were just as triggered as I was and now there are all these redundant "actshually" comments :D
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
k__ 6y ago
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.
brundolf 6y ago
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.
- wperron 6y ago
  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
  - brundolf 6y ago
    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?
    - lucacasonato 6y ago
      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.
konart 6y ago
Should we tell him that this is not a framework? Anyone?
- croes 6y ago
  No.
  - asidiali 6y ago
    ...de alternative!
dubcanada 6y ago
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.
- tehbeard 6y ago
  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.
  - dubcanada 6y ago
    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.
- greenshackle2 6y ago
  Kind of a leap to go from not wanting to learn the JavaScript techology du jour to not wanting to learn anything.
pupdogg 6y ago
short_anecdote: don't switch, it's not for you!
programmarchy 6y ago
Deno has first-class support for TypeScript. Refactoring code without types is not a pleasant experience.
tolmasky 6y ago
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!
- croes 6y ago
  Maybe because there are way more JS frameworks than runtimes. It feels like dozens of frameworks pop up every day.
  - tolmasky 6y ago
    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.
oehpr 6y ago
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.

hayd 6y ago

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

johnfn 6y ago

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.

FractalHQ 6y ago

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

remexre 6y ago

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

devmunchies 6y ago
does it interop with libs made for node.js and are on npm? e.g. using the official the AWS node.js library
- brundolf 6y ago
  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.
- remexre 6y ago
  Can't comment on sibling, but https://www.skypack.dev/ https://www.skypack.dev/ lets you import many npm packages; I haven't tried the AWS library, though.
  - brundolf 6y ago
    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
    - remexre 6y ago
      Yes, it's automated.
- wperron 6y ago
  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-application https://deno.com/deploy/docs/tutorial-dynamodb#write-the-app...

turbinerneiter 6y ago

Deno isn't a JS framework?

tannhaeuser 6y ago
You mean it's a runtime, like Node.js? /s
- turbinerneiter 6y ago
  I guess roughly a billion people were just as triggered as I was and now there are all these redundant "actshually" comments :D

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

k__ 6y ago

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.

brundolf 6y ago

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.

wperron 6y ago
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
- brundolf 6y ago
  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?
  - lucacasonato 6y ago
    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.

konart 6y ago

Should we tell him that this is not a framework? Anyone?

croes 6y ago
No.
- asidiali 6y ago
  ...de alternative!

dubcanada 6y ago

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.

tehbeard 6y ago
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.
- dubcanada 6y ago
  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.
greenshackle2 6y ago
Kind of a leap to go from not wanting to learn the JavaScript techology du jour to not wanting to learn anything.

pupdogg 6y ago

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

programmarchy 6y ago

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

tolmasky 6y ago

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!

croes 6y ago
Maybe because there are way more JS frameworks than runtimes. It feels like dozens of frameworks pop up every day.
- tolmasky 6y ago
  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.

oehpr 6y ago

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.