101–110 of 116 posts
Earlier quoted context omitted.
My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;) Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.
> quality backend modules and shitty 100-dependencies web modules As someone who works in both stacks, I have seen incredibly shitty backend modules that dump 400mb of node_module deps. I'd even argue node ecosystem is at fault because frontend adopted their package manager and "best practices". So off of your high horse. And Deno's goal of web compatible is in using web APIs where applicable instead of special snowf…
- I think the permission thing is bullshit (and probably a reason enough not to take deno seriously). I'd be interested to be proved wrong (I work on backend security so this is sincere), but it feels like traditional server side isolation mechanims (cgroup, namespace, outgoing http proxy, ...) are well known, work well, seem safer and more flexible and are not nodejs specific, so are better in any system that are not running JS only backend (probably any reasonably large system)
- nodejs now supports the webcrypto API - experimentally (and for what it's worth, I liked the nodejs one better ^^)
Wanted to install deno via cargo. It failed due to having low amount of memory while building V8.
How much memory do you have? It should use a prebuilt version of V8 by default to speed up the build process.
I'd like to use some modern common ground for js/ts development, but the entire toolchain is not ready for this, somehow turning it into chicken/egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to "type":"module" in package.json, which makes webpack.server.config…
I don't even remember the details, but I remember it all feeling very rickety. I'd never push anything that fragile into production, it didn't even survive 25 days of doing small puzzles without constant nursing
Earlier quoted context omitted.
In Deno's case, there are two things: Deno API, which comes bundled with Deno and is present globally, always, without importing: https://doc.deno.land/deno/stable . Includes basic stuff like stdin, stdout, stderr, file management... etc and standard Web APIs like Fetch API, web assembly interoperability, localStorage, FormData, TextEncoder/TextDecoder, etc. Deno std lib, an official library that presents what you co…
So what's Deno's stdlib principle: 1. you got pretty much 80% of what you will need from the std libraries for a mid-size 'normal' application(similar to glibc, libstdcpp, go stdlib, python's stdlib) 2. you got a small stdlib than usual(rust's stdlib), the rest you use cargo and good luck with that 3. you grab whatever you need(node.js, you have no idea about the 500 modules npm just installed) I prefer No.1 here.
Earlier quoted context omitted.
Hence why developers always recommend to use immutable sources when importing modules
The web isn't immutable.
If you wanna take it a step further, you can always opt in to that lock file with various degrees of strictness as you yourself mentioned
Earlier quoted context omitted.
This is inaccurate, or at least misleading. Your code doesn’t begin executing until all of the modules are loaded so it doesn’t “make the call stack async” just because of the import system. Module loading that’s async from the point of view of user code is also supported, but it’s use is rare.
> This is inaccurate, or at least misleading. No it’s not. > Your code doesn’t begin executing until all of the modules are loaded. This is inaccurate, or at least misleading. This, or some aspect of it, is both possible and relatively common: import foo from 'foo'; await foo.bar(); await Promise.all([ import('other'), import('stuff'), ]); // Admittedly this is less common but also valid! import yet from 'more-stuff'…
> import foo from 'foo';
> await foo.bar();
import baz from 'baz';
baz.foo();
> await Promise.all([
> import('other'),
> import('stuff'),
> ]);
> import yet from 'more-stuff';
// main.js
console.log('a')
await new Promise(res => setTimeout(res, 1000))
console.log('b')
import { foo } from "./foo.js";
// foo.js
export function foo() {
}
console.log('c')
c
a
[one second pause]
b
No, it really isn't. From the POV of the application code it's irrelevant. This is trivially proven by the existence of module bundlers which convert non-dynamic `import` statements into one big file that doesn't do anything asynchronous to initialize.
(edit: fighting with formatting)
Earlier quoted context omitted.
Why doesn't nodejs just make modules async? // main.js const fs = require("fs") const foo = await require_async("foo") await foo.sleep(1000) // other.js require("./main.js") // RequireError: main.js returned an unsettled promise, use require_async() Wouldn't that be better of both worlds?
Node did make modules async (just ESM modules). They can’t/won’t make CJS async because their synchronous semantics are a guarantee they determined not to break well before ESM. If you want async modules, ESM is the solution for that.
I'd like to use some modern common ground for js/ts development, but the entire toolchain is not ready for this, somehow turning it into chicken/egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to "type":"module" in package.json, which makes webpack.server.config…
I tried doing Advent of Code in Typescript, and spent entirely too many hours googling circular problems like "I can't use type:module because then ts-node can't load .ts files anymore, but if I don't use it, then require-statements are broken, but ...." I don't even remember the details, but I remember it all feeling very rickety. I'd never push anything that fragile into production, it didn't even survive 25 days o…
Meanwhile guys like node-fetch and chalk ask us why don't we just adopt ESM.
Earlier quoted context omitted.
> This is inaccurate, or at least misleading. No it’s not. > Your code doesn’t begin executing until all of the modules are loaded. This is inaccurate, or at least misleading. This, or some aspect of it, is both possible and relatively common: import foo from 'foo'; await foo.bar(); await Promise.all([ import('other'), import('stuff'), ]); // Admittedly this is less common but also valid! import yet from 'more-stuff'…
> import foo from 'foo'; > await foo.bar(); You only have to `await foo.bar()` if foo.bar was an async function already, the module system is irrelevant. You would still need to await it even if it was `require()`'d in. import baz from 'baz'; baz.foo(); Works just fine, no `await` necessary. > await Promise.all([ > import('other'), > import('stuff'), > ]); Of course these have to be awaited, at this point you're expl…
You cannot do that. Top-level await is forbidden because CJS require is explicitly synchronous.
> Works just fine, no `await` necessary.
I typed all of that on a phone so I erred on the side of brevity, but suppose either the Promise.all or the awaited imports depended on some result from importing foo.
> I assume this is included to imply that loading `yet` is blocked by the `await Promise.all` above it to show that import statements can run after module resolution. If this was your intent you are mistaken, that import statement is still resolved before execution begins.
I was trying to show that import statements are blocked by prior awaits. I’m not sure what you’re trying to show, but you’d need to log output after the import from foo.js to see how the asynchrony works for that import.
> No, it really isn't. From the POV of the application code it's irrelevant. This is trivially proven by the existence of module bundlers which convert non-dynamic `import` statements into one big file that doesn't do anything asynchronous to initialize.
Compare that to a non-bundled but otherwise similarly optimized app and look at the waterfall.