Ami
Ami•8mo ago

Updated examples for "Roll your own JavaScript runtime" blog posts?

Hi all. I'd like to embed Deno in a project and I discovered the excellent series of "Roll your own JavaScript" posts on the Deno blog. Unfortunately, the examples don't work with current Deno because "op" has been replaced by "op2". I know updating the blogs is likely to take a while, but is it possible for somebody to post updated example code, or point to some example code using op2 that does something similar to what's the blog posts? I've tried to find examples in various places, including in the Deno code itself, but I really need a complete but simple example in order to understand what's going on.
6 Replies
Deno AI Helper
Deno AI Helper•8mo ago
Hello! I understand you're looking for updated examples that align with the changes in Deno's runtime, specifically regarding the transition from op to op2. While the blog posts provide a great starting point, they might not always reflect the most recent changes in the Deno codebase. The documentation does mention a series of blog posts about creating your own JavaScript runtime, including a part 3 that discusses optimizing startup time by creating and loading a snapshot of a custom JavaScript runtime. However, it doesn't provide specific code examples for op2. For a complete and simple example using op2, I would recommend looking at the more recent examples in the Deno codebase, as you've mentioned. The Deno runtime is actively developed, and the source code is often the most up-to-date resource for understanding how to use new features. If you're looking for a specific example and can't find one in the Deno codebase, you might want to check out the Deno examples repository or the manual for guidance on the new APIs. The Deno community is also a great resource, and you can often find help and examples by reaching out on platforms like the Deno Discord channel, forums, or GitHub discussions. Remember that while the blog posts are informative, they might not be updated as frequently as the actual codebase, so the Deno repository and official examples are your best bet for the latest patterns and practices. 🦕
gio
gio•8mo ago
Hi! I'm in the same boat as you but I'm on part 3 trying to figure out snapshotting. I was able to finish part 1 by looking at example ops over at https://docs.rs/crate/deno_url/latest/source/lib.rs
#[op2(async)]
#[string]
pub async fn op_read_file(#[string] path: String) -> Result<String, Error> {
let contents = tokio::fs::read_to_string(path).await?;
Ok(contents)
}

#[op2(async)]
pub async fn op_write_file(
#[string] path: String,
#[string] contents: String,
) -> Result<(), Error> {
tokio::fs::write(path, contents).await?;
Ok(())
}

#[op2(fast)]
pub fn op_remove_file(#[string] path: String) -> Result<(), Error> {
std::fs::remove_file(path)?;
Ok(())
}
#[op2(async)]
#[string]
pub async fn op_read_file(#[string] path: String) -> Result<String, Error> {
let contents = tokio::fs::read_to_string(path).await?;
Ok(contents)
}

#[op2(async)]
pub async fn op_write_file(
#[string] path: String,
#[string] contents: String,
) -> Result<(), Error> {
tokio::fs::write(path, contents).await?;
Ok(())
}

#[op2(fast)]
pub fn op_remove_file(#[string] path: String) -> Result<(), Error> {
std::fs::remove_file(path)?;
Ok(())
}
and
let runjs_extension = Extension {
ops: vec![
op_read_file::DECL,
op_write_file::DECL,
op_remove_file::DECL,
op_fetch::DECL,
]
.into(),
..Default::default()
};
let runjs_extension = Extension {
ops: vec![
op_read_file::DECL,
op_write_file::DECL,
op_remove_file::DECL,
op_fetch::DECL,
]
.into(),
..Default::default()
};
Ami
Ami•8mo ago
Cool. In fact, after writing this question, I eventually stumbled upon the github repo with updated code from the blog. You can find it here: https://github.com/denoland/roll-your-own-javascript-runtime/tree/main
GitHub
GitHub - denoland/roll-your-own-javascript-runtime
Contribute to denoland/roll-your-own-javascript-runtime development by creating an account on GitHub.
Ami
Ami•8mo ago
There are still some deprecated functions in that code, but it builds and appears to work. Now I'm trying to figure out how to pass Javascript Objects back and forth. @Deno AI Helper Do you know how to pass Javascript Objects (v8::Object) between Rust and Javascript?
Deno AI Helper
Deno AI Helper•8mo ago
Passing JavaScript objects between Rust and JavaScript in a Deno plugin involves serializing and deserializing the objects. When you're working with the V8 engine (which Deno uses internally), you typically deal with v8::Local<v8::Value> for JavaScript values. In the context of Deno's FFI (Foreign Function Interface), you would use the serde_v8 crate to serialize and deserialize values between Rust and JavaScript. This crate allows you to convert between V8 objects and Rust structs or enums that implement the serde::Serialize and serde::Deserialize traits. Here's a high-level overview of how you might pass objects between Rust and JavaScript: 1. From JavaScript to Rust: - JavaScript objects are serialized into a format that Rust can understand (typically using JSON). - The serialized object is passed to Rust through an FFI boundary. - Rust deserializes the object into a Rust struct or enum using serde_v8. 2. From Rust to JavaScript: - Rust structs or enums are serialized into a format that V8 can understand. - The serialized data is passed back to JavaScript through the FFI boundary. - JavaScript deserializes the data back into a JavaScript object. Please note that the advice provided here is not based on the Deno documentation, and you should double-check the accuracy of this advice. The Deno documentation and examples would be the best source of truth for the most current and idiomatic ways to pass objects between Rust and JavaScript in Deno. If you're looking for more detailed guidance or examples, I would recommend exploring the Deno manual, the serde_v8 crate documentation, or reaching out to the Deno community for more specific use cases.
Ami
Ami•8mo ago
Hmm. Serializing to/from JSON seems like a terrible way to do it. Probably good enough for my application, but surely there must be a better way.