▲ 73 points
back
27 comments
Can Deno be embedded in a larger Rust application? I know I can embed v8 directly https://github.com/denoland/rusty_v8 but I wish I could use other parts of Deno.
In particular, I wish I could write a Tokio async program in Rust, and load plugins using deno, and have this work seamlessly
edit: actually, https://deno.land/manual@v1.25.0/embedding_deno https://crates.io/crates/deno_core https://docs.rs/deno_core/latest/deno_core/
It doesn't expose tokio so I suppose that it manages its own runtime separate from the executor of the application using it (edit 2: it doesn't, it lets the user bring their own executor. cool!)
Yes, easily. We do this for the JS runtime at litprotocol.com
Cool! Can you link to it on Github or something? (is it oss?)
> New experimental HTTP server API
> Our benchmarks show a 4x improvement in hello-world request per second performance compared to Node.js and a 3x improvement compared to our existing web server.
What the heck was wrong with the previous implementation? :P
https://github.com/denoland/deno/pull/15405
I think this is the PR for it though.
Unless the performance benefits are from something else in https://github.com/denoland/deno/releases/tag/v1.25.0
Npm support is really big addition. I thought of exploring deno for big project, but was worried if I can't find deno package for specific feature.
With bun claiming to be fastest I want to see how deno compares to bun.
Looks like bun gave a good boost for deno
Feel like Node should've ripped the band-aid off and just said 'fuck it, ESM only in the next LTS' instead of this .mjs business. If you need CJS, use the previous LTS which we'll exceptionally support a bit longer. Would've gave them space to make other fundamental changes as well. Yes, you get a bit of a Python2/Python3 split in the community but to me it'd have been worth it and the JS community is less risk adverse anyway.
ES modules were not only issue with node. There are bunch like no Promises in std library(they are adding that though) standard library is very minimal, so not easy to make a web app without a npm package.
It has always been extremely easy.
Ryan Dale famously demoed his 10 line webserver for Node
Seems like some competition is a good thing!
Love to see the experimental npm support.
deno init is a bit silly imo.
A tiny command like this seems trivial, but it actually plays an important role.
It makes trying Deno for the first time frictionless, while placing learning pathways for both module layout and testing. It’s a small accelerant to learning – but one that probably reduces early churn on the learning pathway due to an unnecessary decision.
This command also means that the next 100 tutorials written about Deno will skip a step with `mkdir` and `touch` while standardizing the naming convention of _test.ts files clearly.
A little pebble can change the flow of a large river if it’s placed while the river is still a stream.
What's wrong with `deno init`? `npm init` has been a thing for years.
From the sound of things, deno init basically just downloads a sample project- it's not creating actual boilerplate that you're going to keep using as you implement your real app
Yeah but that's what users want. `<project manager> init` is a de facto standard way to say "Ok, new tool that I don't understand, make me a blank project."
Just because Deno's blank project is literally just `/* main.ts */ console.log("hello world!");` doesn't mean that the `init` command is useless.
It's not useful if you are already aware how Deno works. The point of adding it is to help people who don't know. It's about discoverability.
Yeah but Deno doesn’t require package.json or anything like that. Seems sort of redundant.
It's also missing git and gitignore.
Really happy to see. I have been using Deno for a project and I have really enjoyed it. It solves all of the annoyances of Node for me.
annoyances?
could you mention some
See:
"10 Things I Regret About Node.js - Ryan Dahl - JSConf EU" https://m.youtube.com/watch?v=M3BM9TB-8yA
The main thing I want from Deno is per dependency sandboxing. They let you enable file system or internet access for the whole project, but that's basically useless in most of my usecases. If I could whitelist the couple of dependencies that might need http access or whatever, that'd be great.
While there's no realistic way to provide a security boundary between JavaScript modules, Workers are a possibility [1].
The code with the more restricted set of permissions must run in the Worker. That code then communicates with the rest of your app through postMessage / SharedArrayBuffer, perhaps using ComLink [2].
[1] https://deno.land/manual@v1.25.0/runtime/workers#specifying-...
I think realms are the future in this direction. https://github.com/denoland/deno/issues/13239
> When doing this, no npm install is necessary and no node_modules folder is created.
Where do they go for say... Docker container purposes?
Probably into the same cache that Deno uses for other module URIs: $DENO_DIR or system default cache location. https://deno.land/manual@v1.25.0/linking_to_external_code
My node.js needs is related to electron.js, wish deno becomes one of Electron.js backend someday.
You may also find astrodon [1] interesting
Look into Tauri, it uses the web view of the host OS rather than Electron