[smt88]

> 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?

[fndex]

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.

[estebank]

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.

[charlieflowers]

I wonder about Helix plugins.

[gabereiser]

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.

[vanjajaja1]

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

[nerdix]

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.

[pkulak]

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.

[izietto]

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

[smt88]

Why not transpile Rust to WebAssembly directly?

[chrisco255]

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.

[smt88]

> 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

[izietto]

> 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