11–20 of 116 posts
I prefer CommonJS. It's so simple. You assign the dependency to a variable and that's it. I still need to look up the syntax every time I use ESM.
honestly tough, esm is more complex than it should (especially regarding how live exports happen)
I prefer CommonJS. It's so simple. You assign the dependency to a variable and that's it. I still need to look up the syntax every time I use ESM.
erm, how is that any simpler than `export const/function/class $defintion` ?
I guess if you only touch JS once in a blue moon it's difficult to remember?
Also CommonJS has some acknowledged issues around cyclic dependencies, and being incredibly fudgeable at runtime that makes static analysis and linting a pain.
Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"
the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it
> V8 is a sandboxed language False, V8 is a JS runtime with sandboxing built into its core design. It’s not a language and it doesn’t guarantee sandboxing the JS runtime. > that makes it impossible False, breaking out of the sandbox is trivial in environments which allow native addons.
Also related: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
Most Browser exploits these days use Heap Spraying attacks that try to corrupt the state of the sandbox in between bindings and native libraries (or their data structures that are transferred between contexts). So technically, a JIT VM always leads to possibilities for breakouts when there is a discrepancy between the optimizer and deoptimizer's assumptions (e.g. in regards to callstack, garbage, memory ownership etc).
Also: There's a legacy navigator.plugins C-Bridge based API which hasn't been maintained or redesigned/refactored since the late 90s yet it is still active in most Browsers.
https://github.com/denoland/deno/issues/11964
https://github.com/denoland/deno/issues/9750
API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” makes no sense without checking the integrity of the binary, controlling the environment for LD_PRELOAD-like hacks and evaluating the code of this command for possible escape hatches. If you want to isolate a program, you need to do it on the OS level.
Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.
I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.
This isn't necessarily enforced by Deno itself right? That seems like more of a side-effect from the self-selection of its users. Once the ecosystem grows and the all the "normies" come in, this doesn't seem guaranteed at all.
Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix. https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/9750 API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” m…
Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix. https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/9750 API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” m…
As a non-js dev, is it better than Node?
Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix. https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/9750 API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” m…
Is there an alternative tool you can suggest, to allow us securely run arbitrary JS? I was looking at Apple's JavaScriptCore to run JS and and if it happens that I need any level of access to the system(i.e. files) simply handle that in Swift and pass the file to the JS. Would that be a secure approach?