Hacker News new | past | comments | ask | show | jobs | submit login
Running JavaScript in Rust with Deno: Experimenting with Deno's Rust Crates (austinpoor.com)
136 points by a-poor on May 4, 2023 | hide | past | favorite | 19 comments



Being able to allow custom behaviour via JS/TS in Rust is definitely something that I wanted to explore too. If you haven’t already you should check out these two articles from the Deno blog website which go a bit further:

https://deno.com/blog/roll-your-own-javascript-runtime

https://deno.com/blog/roll-your-own-javascript-runtime-pt2


Part 3 of the series was published just an hour ago:

https://deno.com/blog/roll-your-own-javascript-runtime-pt3


> Being able to allow custom behaviour via JS/TS in Rust

I understanding wanting to call out to Rust from JS/TS, but I don't think I understand wanting the reverse. Isn't a major goal of Rust not to have "custom behavior" that is invisible to the compiler?


Imagine you are building a game in Rust where players can write mods. Those mods could be written in JS/TS while the game is written in Rust.


It of course doesn't need to be a game. VBA macros in Office and AutoLISP in AutoCAD are two examples of scripting environments on large compiled applications that allows users to customize and automate behavior, outside of gaming. Hell, you can point at Emacs and vim as examples too.


I wonder about Helix plugins.


Building a data ingestion pipeline that scales horizontally but leaves the ingestion rules up to your customer in the form of a ts module that implements an interface? There’s plenty of opportunities to allow your runtime to be controlled via scripting.

Or a function host that executes jobs at scale? You only need to program the security, sandboxing, scheduling, and distribution of functions that can be invoked.


Presumably Deno is a use case where you would want to write rust that hosts js/ts safely


Some applications use Lua for configuration: neovim, conky, awesome, etc.

I haven't looked into the details of this so I'm not sure if its a suitable replacement for embedding lua (binary size would be my first concern..does this embed v8?) But I would much prefer TypeScript as a configuration language than Lua.


Business apps can sometimes be so complicated that the decision is between having a giant settings page, where you try to anticipate everything users will want to do, or you let them write little snippets of code that you interpret on the fly. I like the latter approach a lot, because even if I have to help write the snippets, it’s easier than shoving special-case code into the project, yet again, and deploying.


I'm trying to build a view rendering engine / perform SSR straight on Rust with that


Why not transpile Rust to WebAssembly directly?


SSR is the process of generating the HTML and CSS necessary to render a web page on the server side before it's sent down the wire. You can't just pipe wasm to the client to get the same effect. Besides being less efficient than JS at manipulating the DOM, the idea is that everything is already available and streamed to the client for optimal render speed.


> You can't just pipe wasm to the client to get the same effect.

I know what SSR is and you can do it[1] in Rust, where you write type-safe, compiled Rust code and send HTML/CSS/WASM to the browser. SSR was originally developed in things like Perl and PHP -- there's nothing language-specific about it.

> Besides being less efficient than JS at manipulating the DOM

Some applications manipulate DOM a lot (and WASM isn't slow enough for a well-written app to be noticeably slower to a user) and some applications do a lot of processing before changing the client. WASM will be dramatically faster at the latter.

1. https://wasmedge.org/book/en/write_wasm/rust/ssr.html


> I know what SSR is and you can do it[1] in Rust, where you write type-safe, compiled Rust code and send HTML/CSS/WASM to the browser.

Yeah, but that way your frontend team is forced to develop in Rust, instead of develop in JS/TS. What I want to do is enable FE devs/team to do their job (writing JS/JSX) happily ignoring the server, and at the same time do SSR on the server happily ignoring how FE devs/team implemented the view.

You might notice, "ok but they need a contract to know which is the data shape that the server is going to provide to the JS/TS render() call"; yep, that's one of the challenges of what I'm trying to do :D


I wasn't aware of a pt2, thanks for the link.


> Data pipelines (eg Apache Airflow) where the orchestration is handled by Rust but the high-level business logic is defined using JavaScript

That is ... exactly what windmill is https://github.com/windmill-labs/windmill

The orchestrator is built from scratch in rust using postgresql to store the state. The steps when in typescript are run in deno: https://github.com/windmill-labs/windmill/blob/main/backend/... and the transforms between the steps (piping outputs of any node to the input of any node) are actually javascript expressions run by deno JsRuntimes: https://github.com/windmill-labs/windmill/blob/f3ec9ca09dc37...


Maybe a naive question but why using Deno instead of v8 directly for javascript interpreter/compiler/runtime, it can also be called from rust.


> the release build of js-in-rs is 54 MB, grep is 179 KB, and a basic hello world JS application compiled using Deno is 103 MB.

OMG. That's ridiculous.

Write the code in C or Zig, and use Lua for scripting, and you're down to under 1MB for the final binary.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: