What are the conditions for people feel the urge to migrate over to deno?
Currently, I don't see enough reasons to switch to deno for primary projects.
Deno 1.9
131–140 of 245 posts
Re: Deno 1.9
#132Earlier quoted context omitted.
When Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention). Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold fo…
Indeed. I remember that, I have been using node since the very early days, and switched to it for precisely that reason--that I could use the same language through my web application. Nevertheless, when we did get those modern web API, Node was slow to change or adapt them, although, it's doing its best now. In case of Deno, I hope they just stick to following the standards and changing with them. They might not, I c…
Overall this is true. And beyond that the TypeScript team is heavily involved in TC39, and quite a lot of TC39 proposals are specifically designed to be enhanced by TS. That said...
There are a few longstanding incompatibilities/footguns. And they’re likely to remain due to widespread use, even though most are controversial. Off the top of my head:
- access control annotations (`private` which is compile time only vs `#`). I’m on the fence on this one. I prefer the TS syntax, but obviously not the behavior.
- Enums. Everyone but me hates them. I use them extensively for personal/internal use but try not to force them on others.
- Decorators. This is the big bad ticking time bomb. Last I checked the TC39 proposal has diverged significantly from the TS implementation. And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain.
Re: Deno 1.9
#133Earlier quoted context omitted.
How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?
Maybe there's a bundler/webpack plugin that supports deno's import system, so it just fetches whatever http urls/analyzes the import maps and turns it into a normal web bundle.
Yes there are plugins for this in pretty much every build tool and for Node. But they all have a bunch of caveats and mutual discrepancies.
Re: Deno 1.9
#134I wonder what the general performance difference difference there is between the new Rust-based server and Express?
Re: Deno 1.9
#135Earlier quoted context omitted.
How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?
Snowpack might be an option
Their companion CDN (and namesake umbrella parent company) is also a first class part of Snowpack.
However using CDNs in the browser has some big trade offs. Besides obvious concerns sending any data to consolidated third parties, it’s actually a performance detriment now that browsers are caching per origin.
Used to be, using a CDN got you more likely cache hits and better perf on N+1 requests. Now you definitely don’t get that plus you get the extra DNS lookup and whatever performance characteristics of that CDN.
Re: Deno 1.9
#136Earlier quoted context omitted.
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.
Node didn’t introduce the Promise API. Although it definitely instigated it. Node, with its async IO model, was just littered with callbacks. There were a zillion different approaches to async APIs that could ease that. Promises were, well, the most promising. But years of iteration and competing standards came and went before Node adopted them as the preferred API. And they did so right along with browser vendors and web standardization bodies.
Re: Deno 1.9
#137Earlier quoted context omitted.
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 introduced the "global" object instead of using the existing "window" object the pre-existed in all browsers.
At least whe have "globalThis" now.
Re: Deno 1.9
#138I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.
It's a Node.js alternative. Deno glue code around V8 is written in Rust. It tries to be as close to the browser API as possible, using ES-Modules instead of CommonJS and doesn't require a package manager. Also, it compiles TypeScript automatically.
> Deno glue code around V8 is written in Rust.
The C++ V8 api is very reasonable to be used in a safe way. So i dont see this as a good point unless of course for people that wan to write some parts that need to be optimized in Rust.
Don't deal with NodeJs that much, but is a lot of node functionality in C++ modules? and if so they are presenting a lot of security bugs in a way that Rust might see appealing?
Because by not having direct access to the V8 api in its native language might limit you, the "glue coder", in the things you really can do.
Re: Deno 1.9
#139Earlier quoted context omitted.
Not sure I’d use the local deps file. I really like just the import {..} from “ https://xn--ivg . The version, everything, is up front and explicit.
The problem the deps.ts pattern solves is that your project has several dozen modules that all import a particular version of a dependency, and now you need to update them all to a new version of that dependency. (If your project only has one module, then you don’t have this problem and don’t need this solution.)
Why not just use sed?
Re: Deno 1.9
#140As 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…
> Does it have potential as a safer, lightweight Electron alternative? Or are there better options than Deno in that regard?
If they target this, the big chunk of code will still be the same ones on Electron, so i don't think it would get to be safer or lightweight as compared to Electron.