Planning a web framework (website redesign part1)

I recently decided I want to try and split the code of my website into content and framework. There are a few reasons but the biggest is I want to remake the repo completely in zig. I thought it may be fun to document this process from start to finish.

...Bruh, I cant even put games in my site. Also, why not? Huh zig isnt meant for webdev. Yeah I didnt think you had a good reason.

Firstoff, currently my website uses a random dom parsing library I found on github to store html. I am going to scrap this completely, first off I dont parse any html, but more importantly dont even use this library like at all, not even for emission. This also brings up that ugly markup language I use. I want to keep the custom format, but ill have to redesign it a little more formally.

Alright, maybe this is actually doable. Another thing I need to worry about, is how am I going to insert wasm into my new generated html through zig. My plan for that is to make the framework build a builder executable, this executable will have flags that can print dependencies. I can then use zigs build system over that to build/emit those wasm files. This will allow all the code to be in one place. I could even have a build target for these executables that emits wasm code instead of a main function. Maybe even packing all the wasm from my entire site into one binary. And keep my wasm inline with the html, pretty nice sounding.

Ok thats cool, but now I need to decide how I will extend this later on, because ya know javascript is always getting new "good" features. I think if I just have a decent protocol for calling js inside my wasm I should be fine. This will also allow me to make things like style sheets in zig, and then have my wasm engine apply it.

Well honestly its not bad at all, just a basic graph. A few things I personally want is optional pretty emission, arbitrary tags through an enum([]const u8), and some form of linking between pages. I also wanna try and use arenas for this because it seems like a fun chance to try the pattern. I dont think thats too bad, maybe something like this:

const DomElement = union(Kind) {
    const Kind = enum { tag, metadata, text, code };

    tag: struct {
        kind: []const u8,

        child_allocator: std.mem.Allocator,
        children: std.ArrayList(DomElement),
    },
    metadata: struct {
        key: []const u8,
        value: []const u8,
    },
    text: []const u8,
    code: DomCode,
};

I already partially discussed it, but the plan for wasm is to embed it inside the zig dom. I think if I have a wrapper for structs Itll endup pretty nice, maybe something like:

const DomCode = struct {
    pub fn init(comptime Base: type) DomCode {
        switch (DomMode) {
            .html => {
                // dont emit any code
            },
            .emit => {
                // export functions
            }
        }
    }
};

Ill have to figure out how to force a function to export, but other than that it should be straight forward.

Anyways thats all the rough planning out of the way (for now), I guess just stick here til I spec out the actual functions in part 2.