121–130 of 151 posts
I am the author of Pogo, a web server framework for Deno that has friendly APIs and is secure by default. It supports React out of the box and has the best documentation of all the frameworks. GitHub: https://github.com/sholladay/pogo Video tutorial: https://www.youtube.com/watch?v=Fe4XdAiqaxI
Extraordinary claims require extraordinary evidence.
Some random comments: - good to see native TS support - Would be nice to see a builtin maven/gradle-like standard build system, which IMHO not having it in node.js was a major let down for me. Sure, you have gulp/grunt, but having to write repetitive code (which can be buggy!) for running a compiler/test/packager? With another set of plugins? just give me some standard tool and let me call the equivalent of "mvn pack…
Earlier quoted context omitted.
Does package-lock.json not fill this void? It's been a thing for a few years IIRC.
Partially, like the yarn.lock it only filled half the problem. The other half is being able to have multiple versions installed at the same time and freely, confidently referencing the version I want. node_modules can only have one version and it's not hard to have version drift even while having a lock. The standard answer is to do the `rm -rf node_modules` & install. Often that fixes whatever problem creeped in. Bl…
It's not well-known, but it is possible:
"dependencies": {
"sodium-native-2": "npm:sodium-native@2",
"sodium-native-3": "npm:sodium-native@3"
}
Don't get me wrong, npm is haunted, but I use it daily can't remember having experienced "version drift". The only reason I have to `rm -rf node_modules && npm install` is that `npm update` (even with --depth) doesn't do its job, so if you want to update all deep dependencies then you have to blow up your lockfile.
(Btw, if you are experiencing some "version drift" problem, I'd recommend `npm ci` as an alternative to `rm -rf node_modules && npm install`.)
Deno is on my list of tools to play with. It's sandboxing capabilities are the main selling point for me because it will allow executing semi-trusted/un-trusted code on private data sets. If I know that the code can't access the network or do anything fancy with the file system then I can treat the untrusted code as a pure function and know that the output will only depend on the input. This is a very desirable prope…
Sandboxing has been possible for many years before Deno. Running untrusted code is not popular for good reasons.
Earlier quoted context omitted.
You could implement this by fine grained imports and subprocess execution. Node.js actually has a very nice sub-process communication API: https://nodejs.org/api/child_process.html#child_process_subp... . At some point I remember writing some gpg wrappers with Node.js and I remember the subprocess API being one of the more pleasant ones to work with. In the case of more stringent Deno process sandboxing, the parent p…
Deno uses the web standard Worker API to implement sub processes. They are also working on fine-grained permissions for these workers [1]. [1] https://github.com/denoland/deno/issues/4867
Earlier quoted context omitted.
I think he means Ryan Dahl Anecdotally, there are several languages (French, "Argentinian" Spanish to name a couple) where it's common to re arrange the syllables of the words backward-ish (More often than not for slang - argot for France, lunfardo in Argentina - uses).
What do you mean by your last sentence? The sentence makes complete sense and is not backwards translated to spanish
The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, w…
The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, w…
I'm not too sure, but in Java, you depend on specific versions and the packages are signed. And most company have an internal repo they work off on, in case the public repo is having downtime or the package gets removed from it. Also deployments don't make use of dependencies, a single uberjar bundles it all up. Was this all true of NPM as well?
That's not actually completely right... there are problems with deploying a single jar. With Java 9 modules, you're actually throwing away module encapsulation if you deploy a uberjar. The current state-of-the-art is to deploy the whole app + the JVM in a jlink image, which requires no uber jar.
The example on permission isn't great. It said the library you used cannot access your database password from env and send it over the internet unless you allow so. When you're putting database password in the env, most likely you need to permit env var and network access for your database client library. Then at the same time, the library in example can do that malicious thing. The problem here is, deno request the…
> Javascript is great. But... in saying that it has a few quirks and can work in some unexpected ways. Typescript has just as many[1] (in fact more, as it's a superset) quirks than Javascript. I like using it (and it makes JS type-safe-ish), but it's not really some kind of paradigm shift. Not sure how I feel about import maps. They are quite literally the same thing as package.json. In fact, converting between the t…
Frankly I find TypeScript with strict mode turned on to be a safer and saner than C# and Java because of explicitly nullable types alone. I _never_ get null pointer exceptions in my own TypeScript code. Combined with fairly strict ESLint you get something that catches a lot of problems at compile time. Of course it's still far cry from being as safe as for example Rust. And yeah the inconsistency of JavaScript/TypeSc…
I agree. I think this probably looks a lot like a Rust-lite (GC instead of lifetimes for memory management) or a Go with generics or a mature ReasonML?