Scuffed Web Development With The Mellifera WebAssembly Build And JavaScript FFI API

What should the behavior be here? Should Mellifera treat all getters as properties when converting? That seems like it could easily lead to a data redundancy error. Should Mellifera ignore getters entirely? Well then cases like our Pixel class here would fail to properly convert into a meaningfully useful value, which could be especially surprising to a user if converted as a sub-object within a larger data structure.

All of these problems also exist in the reverse case when trying to convert from Mellifera to JavaScript with js::from_mellifera(). How do we represent Mellifera functions, in JavaScript? I mean heck how do we even really represent Mellifera map values in JavaScript? Maps in Mellifera can have have arbitrary values as keys: strings, numbers, and even other maps, just to name a few. Do we try to represent Mellifera maps as a JavaScript Map instead? I don't have good solutions to these problems right now, and I have not had enough experience with Mellifera in the browser to feel confident with any decision I could make.

So to go back to your question about why Mellifera can't just use interpreter magic to convert between Mellifera and JavaScript automatically: it turns out that the differences between the languages make a generalized conversion strategy real tricky, and would necessarily require the Mellifera language to take an opinionated stance on how such conversion should take place. Instead of attempting to tackle that mess of a problem, the js FFI API chooses to explicitly acknowledge the differences between JavaScript and Mellifera, and purposefully forces the programmer to think about those differences when interacting across the FFI barrier.

Ashley

Wow I guess I did not really realize how complicated JavaScript is. *sigh* Why is it that my head starts to hurt every time I learn more about web development.

It seems like there isn't really a whole lot you can do with this API given all of these incompatibilities. Is this thing even really usable?

Despite these incompatibilities, there is actually a surprising amount that one can do in pure Mellifera now. You just need to be careful with the conversions back and forth, and be mindful of when you are working with external JavaScript values and when you are working with native Mellifera values.

Let's take a look at the "hello world" of interactive web development: building a to-do list application. For this exercise, we want to have some list of tasks that can be added and removed interactively. In pure HTML/JavaScript a simple version of this to-do list would look something like the following:

<div style="margin: 1rem auto; padding: 1rem; border: solid 2px var(--color-orange);">
    <h2>To-Do List (JavaScript)</h2>
    <input type="text" id="todo-js-input" placeholder="Add a task...">
    <button onclick="todoAddTask()">Add</button>
    <ul id="todo-js-list"></ul>
</div>
<script>
function todoAddTask() {
    let input = document.getElementById("todo-js-input").value.trim();
    if (input === "") {
        return; // ignore empty tasks
    }

    let ul = document.getElementById("todo-js-list");
    let li = document.createElement("li");
    li.innerHTML = `${input} <button onclick="this.parentElement.remove()">Remove</button>`;
    ul.appendChild(li);
    document.getElementById("todo-js-input").value = "";
}
</script>

This HTML/Javascript snippet appears on this page as the following:

We can write this same basic to-do app with Mellifera, translating the JavaScript code into Mellifera line-by-line, which would look something like the following:

<div style="margin: 1rem auto; padding: 1rem; border: solid 2px var(--color-orange);">
    <h2>To-Do List (Mellifera)</h2>
    <input type="text" id="todo-mf-input" placeholder="Add a task...">
    <button onclick='mellifera.evalById("todo-mf-source", {});'>Add</button>
    <ul id="todo-mf-list"></ul>
</div>
<textarea hidden readonly id="todo-mf-source">
let input = js::into_mellifera(js::global().get("document").call("getElementById", [js::from_mellifera("todo-mf-input")]).get("value")).trim();
if input == "" {
    return; # ignore empty tasks
}

let ul = js::global().get("document").call("getElementById", [js::from_mellifera("todo-mf-list")]);
let li = js::global().get("document").call("createElement", [js::from_mellifera("li")]);
li.set("innerHTML", js::from_mellifera($`{input} <button onclick="this.parentElement.remove()">Remove</button>`));
ul.call("appendChild", [li]);
js::global().get("document").call("getElementById", [js::from_mellifera("todo-mf-input")]).set("value", js::from_mellifera(""));
</textarea>

This HTML/Mellifera (with a little bit of JavaScript) snippet appears on this page as the following:

Ashley

Of all the to-do applications, that is... certainly one of them.

Yea, look I know this Mellifera code isn't the most pleasant thing to look at. There is a reason I am calling this scuffed web development. There is pretty much no reason anyone would want to use Mellifera as their primary web-dev language. But there is a kind of cursed beauty that comes from being able interact with the browser from a completely separate scripting language in a somewhat impractical way.

More importantly though, this FFI API makes it possible to add more interactive elements to Mellifera programs in the browser. It may not be pretty, and it may not be ergonomic, but giving Mellifera programs a means to interact with the web page they are hosted in opens up new doors for creative and educational content on this blog, which I am still excited for.

Footnotes