I don't quiet like the defaults of how the zig builder arranges zig-out. I guess just because of my background in C#, I'm used to different build targets and modes being placed in different sub-folders in the build-out directory, but I kind of miss it.

When zig builds my project, I want it to place it in the ./zig-out/<build_mode>/<target> directory.

It's magic, and it's the weirdest thing I've seen all day.

You know what? I'll admit it: TLS scares me.

e.g. /path/to/resource/5.

Minimum Required: allow for u64 identifiers at the end of the path.

Nice to have: allow it to be anywhere in the path.
Nice to have: support UUIDs.

Right now, on template render, I have to match the runtime-found identifier name in the template to the compile-known field name using a bunch of inline for's.

We theoretically could do this only once on template compile by using a single inline for to find the field index, then we can store the field name index in the Template or DeconstructedHtml and use it to look up the compile-time field name for accessing the field of the given struct. Right?

We have some choices, from least annoying to most annoying.

1. Just use SQLite
2. SQLite is for babies; write your own file-based, binary, ACID-compliant, persistent storage solution.

I have a wide rage of intellectually diverse ideas, as you can tell.

To at least disable the automatically-enabled html encoding. Sometimes I want to inject raw html, what can I say?

Also to help specify formatting for floats, because f floats.

Currently, they are stored in their respective struct as a nullable template until the first render call is made. At that time, the template is inited and treated as global (it is never deinited for the life of the program).

This isn't a particularly huge issue, I just kinda don't like the var? vs a const template instance. That, and I don't like never deiniting allocated memory. I guess for all practical purposes, it is just going to live for the life of the application, anyway.

Each template should associate static, comptime RenderOptions with a particular field of its T struct instead of passing in a RenderOptions parameter to the render function at runtime, which affects all fields equally.

Modify the templates-from-runtime-file to watch their source file for updates and re-init the template instance when the template is changed.

The most naive implementation I can think of is just to check the file stats every time the get request is made and remember the date we last reloaded the template. If the file has been modified since we created the template, deinit the old template and reinit a new one. We will want to disable this for release builds, probably, because that is time a production application would not need to spend time doing. Right? I feel like hot-reloading is an unnecessary expense in a lot of cases... but what do I know?

Whenever I feel like actually doing web-dev.

Following work on #6, the Template is in a decent spot to evolve into using comptime. I have some investigation I need to do in order to see if this will work, however.

The Template.init() requires an allocator. There are a few reasons for this.

• First is that .{field_markers} could use Zig's string iteral field, such as @"this". All's well that ends well, but it can contain escape characters, which modify the true presentation of the field name, thus I need an allocator to allow for the extracting of the true field name.
• I also need space to cut out the .{field_markers} from the original template text into the new text.
• I also need space to allocate the FieldMarkers.

One possible solution is to use a std.heap.FixedBufferAllocator. Comptime restricts the existence of syscalls during comptime, but the fixed buffer allocator may be able to just use stack space available during comptime. I am not, however, sure of comptime's restrictions that may inhibit the total possible size of templates using this strategy. I am also not certain whether I can arrange two arrays of disparate types in such a way that comptime will accept.

Alternatively, I could compromise on the valid template syntax to not allow escape characters, thus reducing my need for the allocator. This does make the set of possible identifiers in the template language a subset of Zig's possible identifiers, but who really needs freaky field names, anyway?

Might end up scrapping this one. Not sure how much of a problem it will actually be.