vemahk / zig-http-test Goto Github PK
View Code? Open in Web Editor NEWA toy webserver, built with Zig, Zap, HTMX, and TailwindCSS
License: MIT License
A toy webserver, built with Zig, Zap, HTMX, and TailwindCSS
License: MIT License
Whenever I feel like actually doing web-dev.
It's magic, and it's the weirdest thing I've seen all day.
You know what? I'll admit it: TLS scares me.
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.
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?
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.
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.
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?
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.
We have some choices, from least annoying to most annoying.
I have a wide rage of intellectually diverse ideas, as you can tell.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.