4 ms·

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 ch

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.
brundolf 6y ago
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.
- tolmasky 6y ago
  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.

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.

brundolf 6y ago

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.

tolmasky 6y ago
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.