With HTTP 2 implemented in this version, gRPC might be possible in a near future.
Deno 1.9
111–120 of 245 posts
Re: Deno 1.9
#112Having read multiple comments Deno looks to me like somethung I want to get into.
Is there somewhere a getting started with Deno guide, tackling setup of a d velopment environment and some typical use cases as examples?
How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?
Re: Deno 1.9
#113I can't see what Deno even is. Clicking the "deno" name at the top of the linked page takes me to another page that says just "cli" and "deploy". Great! Clicking CLI (why?) reveals it is a Javascript runtime in Rust. OK, what does one do with that? We know Javascript runtimes come built into browsers. What would I do with one on its own? Anywhere I could run it, I could run code that actually does something, instead.…
> I can't see what Deno even is.
These are just release notes, for developers who already know what it is and want to see what's new.
Literally the top result on Google for "Deno":
Re: Deno 1.9
#114As a primarily C++ dev who's been using nodejs on the side for about a couple years now - so forgive me if this is naive - but am I wrong in seeing Deno as a potential Electron replacement with standalone binary builds + webview?
If so, the introduction of interactive permission prompts is pretty cool.
I see a few comments from more experienced web developers that are quite negative about Deno that seem to generally be centred around the fact it offers very little compared to nodejs, and isn't worth the effort to learn.
Does it have potential as a safer, lightweight Electron alternative? Or are there better options than Deno in that regard?
Re: Deno 1.9
#115Having read multiple comments Deno looks to me like somethung I want to get into. Is there somewhere a getting started with Deno guide, tackling setup of a d velopment environment and some typical use cases as examples? How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?
> How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?
Raptor is an example project which does that: https://github.com/littledivy/raptor
deno_runtime crate provides high level abstractions which you can use to execute code for deno. It is used in the cli. You would still need to bring in your own transpiling layer for typescript support.
As for getting started, you can go through the manual: https://deno.land/manual
Re: Deno 1.9
#116As a primarily C++ dev who's been using nodejs on the side for about a couple years now - so forgive me if this is naive - but am I wrong in seeing Deno as a potential Electron replacement with standalone binary builds + webview? If so, the introduction of interactive permission prompts is pretty cool. I see a few comments from more experienced web developers that are quite negative about Deno that seem to generally…
I think it's not its main goal right now, but it could be and would be really interesting if it happened.
Re: Deno 1.9
#117I 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?
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.
Kind of a leap to go from not wanting to learn the JavaScript techology du jour to not wanting to learn anything.
Re: Deno 1.9
#118As a primarily C++ dev who's been using nodejs on the side for about a couple years now - so forgive me if this is naive - but am I wrong in seeing Deno as a potential Electron replacement with standalone binary builds + webview? If so, the introduction of interactive permission prompts is pretty cool. I see a few comments from more experienced web developers that are quite negative about Deno that seem to generally…
there's webgl, webgpu, and dom, but it's a headless dom (jsdom) not a webview.
I wouldn't be surprised to see packages developed for a webview but atm demo seems to target server side web platform compatibility... except rendering html!
I wouldn't be surprised to see some packages try to fill the gap, & deno has a much stronger basis for implementation than node (a rpc layer between rust & v8 defines the core character of the project, and an native addon that adds webview methods to the rpc would be natural in Deno, vs a hack in electron).
Re: Deno 1.9
#119Earlier quoted context omitted.
Defaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.
I can't think of a single case of Node reinventing the wheel with their APIs. Like you said, they were all created to fill gaps in browser JS implementations. It's obviously going to be hard to reconcile the two as browsers themselves increase their API surface, but then Deno is going to run into the same problem eventually.
node actually invented a lot of wheels. node was first with promises (a couple major iterations!), streams, uhh I dunno what else. file access (we're just getting that now in the browser after some old ill supported early attempts). modules.
the web reinvented many of these wheels.
Re: Deno 1.9
#120I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…
You do something like this export * as Oak from "https://deno.land/x/oak/mod.ts"; export * as Postgres from "https://deno.land/x/postgres/mod.ts"; Then you do this: import { Oak, Postgres } from "./deps.ts";
> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?)
I know you can do this, but then you can't do
import { Function1, Function2 } from "oak";
import { Oak } from "./deps.ts";
const { Function1, Function2 } = Oak;