Advice on use case

[axyz]

Sorry for the non descriptive title, I have a very abstract use case in mind and was wondering if in your opinion using rhai could be a good solution.

Please also let me know if this may not makes sense at all and there is an obvious better alternative in your opinion.

What I'm thinking is having a lot of different .rhai files each one "defining" nodes of an arbitrary graph structure. Specifically a very vague idea is to describe different front-end components (but really could be anything), each one having some data fields and a list of other components they may depend on.

e.g.

registerComponent("my-component", #{
  dependsOn: ["other-component"],
  color: "blue",
  description: "it does nothing, but is blue",
  // etc...
})

registerComponent would be a Rust function made available in the engine and when used in those rhai file would add those nodes to a graph that can be used for different types of possibly expensive operations, likely via some topologically sorted visits.

those .rhai files can be easy to edit and hot reload while the application runs. When the change the graph can be updated as required and visits or other operations triggered.

For example the rust process could be used to generate component files in different formats for different frameworks/platforms, an optimized CSS bundle based on some styling properties, documentation, a show-case webpage, whatever...
And when changing a .rhai file, the outputs that needs an update could be automatically regenerated.

Would that be theoretically possible, and would make sense to use a scripting language like rhai for such use cases?

Possible alternatives

use a macro based DSL to define nodes

probably way faster, but requires recompiling on every change, not very distribution friendly as a tool.

Also the performance benefit may not be that important if all the scripting language does is defining a static object?

use some static config files

instead of rhai files, simply use some, TOML, JSON, or even some custom DSL format.

While there are extremely fast parsers for those simple languages, I wonder how that would perform in the "hot reload" scenario. What I am thinking is that using a scripting language would have an edge here, as it would be possible to expose functions to directly operate on the graph, rather than reparsing and rebuilding everything, or even having more fine grained control using exposed rust functions, for example there could be a separate registerDependencies function that could trigger a new topological sort without modifying the existing nodes.

Maybe there may be some solutions here as well, for example scanning all files and associate at run time each file with a node and selectively update the graph on the file watch events?

Another advantage of using a scripting language like rhai, would be the possibility of reducing lot of duplication, by sharing some rhai functions, using loops, conditionals, etc.

Make

This is not a new problem, if is needed to rely on files anyway a carefully crafted Makefile (or similar tools) could handle sorting, parallelism, batching, caching under the hood.

On the other hand there might be many "intermediate steps" to be cached as files and many very specialized programs that would have to generate them and/or assemble them somehow in the various expected outputs.

Different embedded scripting languages

Probably a matter of preference and most consideration made here about rhai would apply for other languages, I personally do not have experience in the field and would be hard to evaluate what more advanced features may be needed in these kind of use cases.
So far rhai, rune, and mun caught my eye, but merely based on reading a bit of their documentation,

Other?

[schungx]

Not 100% sure about what you're describing, but it looks like something similar to a React coded in Rhai...

It certainly is possible (and perhaps even desirable) to do something like this, otherwise React wouldn't have been created.

On the other hand, why not just use React for it? Why go another scripting language? Unless you really need to stay within the Rust ecosystem...

The benefits of using a scripting language to define nodes is the ability to implement logic on generating those nodes. A config file or a template would still need to encode those logic somewhere, which will be much more cumbersome than a simple scripting language.

That's why React can look so clean while Angular templates look cluttered...

[axyz]

yes, many things in terms of front-end components could be solved better with markup languages, including JSX in React.
But I'm thinking of this pattern more in general as it might be common and useful also in other use cases.

I could imagine it as an alternative to XML in configuring a bunch of modules metadatas, or even nodes that represent remote resources. If a server of sort needs to regenerate a bunch of interdependent artifacts when changing those XML, would using an interpreted language avoid the parsing and full graph rebuild on every change?

Another use cases could be "describing" components in a non platform specific syntax, e.g. to generate typescript types for react,android, ios, to be extended on each platform. Or even generate a susbset of needed css in an optimized way.
These use cases might work with a markup as well, but usually require parsing the markup, and do some heuristic on the generated AST, transform to a different data structure and feed the graph; so why not skip some layers with a scripting language?

Another use case could be live reloading of a web server routes handlers that might depend on each other in some ways.

So I'm looking on feedback on the general pattern rather than the specific example of front-end components, even though I have a few ideas where I might consider this over JSX or similar, but probably not for a full blown FE framework.

I see definitely some advantages, but I'm wondering about the negative sides. Is it wise performance wise? Can be done in more ergonomic ways? etc...

[schungx]

Well, performance is unlikely to be a problem unless you're re-rendering the entire network thousands of times per second.

Otherwise, for infrequent changes (e.g. several times a second) the scripting engine's speed is unlikely to be a bottleneck.