Jetzig reads funny in german something like "now-ish"
Jetzt = now [1]
German adjective suffix: -ig [2]
The German suffix -ig attaches to nouns, verbs and even adverbs. Given this flexibility, it ranks among the most common adjective endings in German. You can use -ig words to express that something is a certain way or happens a certain way.
traurig: sad, sadly
wässrig: watery
knackig: crunchy, crispy
abhängig: dependent, addicted
geizig: stingy
This site makes a big point of using the term "RESTful" repeatedly, but it seems to be JSON-based by default?
I don't know why modern web frameworks insist on continuing to misuse or misapply the term despite a fairly large amount of messaging recently about how exactly this term is misapplied, and the resurgence of frameworks and tools that do correctly apply it, e.g. HTMX, Datastar, Alpine AJAX.
Otherwise, this looks cool. I'd encourage you to un-roll-your-own docs and use something like Starlight or Docusaurus so you can have usable search and versioned docs.
That's a fight we lost two decades ago now unfortunately. Nearly any modern-ish API is a JSON-based RPC. There's nothing wrong with that, JSON RPC is a plenty fine solution for many common use cases, it just isn't REST.
>An application that adheres to the REST architectural constraints may be informally described as RESTful, although this term is more commonly associated with the design of HTTP-based APIs and what are widely considered best practices regarding the "verbs" (HTTP methods) a resource responds to, while having little to do with REST as originally formulated—and is often even at odds with the concept.
Nice, looks like a decent framework. I used to do a lot of python for backend web apps, but recently jumped on the hypetrain and used go for developing a web app (devops) tool. Single binary, easy deployment etc etc.
From that experience, I think this competes with go based web apps mostly. And if so, it makes a good chance at becomming succesful. Zig seams to have a better type system. Additionally the quality of documentation for this project is pretty good. That is something the go ecosystem seems to be lacking in general. The rest of the go perks are there as well. Single binary etc.
As much as I like Zig, I can't imagine working on something as string/list-heavy as web without a garbage collector. Not to mention having a web server without coroutines. Web services these days are just glue code between various pieces of infrastructure, you are constantly waiting on something, it just doesn't make sense to run these in full blown threads.
Jetzig reads funny in german something like "now-ish"
Jetzt = now [1]
German adjective suffix: -ig [2] The German suffix -ig attaches to nouns, verbs and even adverbs. Given this flexibility, it ranks among the most common adjective endings in German. You can use -ig words to express that something is a certain way or happens a certain way. traurig: sad, sadly wässrig: watery knackig: crunchy, crispy abhängig: dependent, addicted geizig: stingy
[1] https://de.pons.com/übersetzung-2/deutsch-englisch/jetzt [2] https://www.lingoda.com/blog/en/german-adjective-suffixes/
The "-ig" suffix corresponds roughly to English's "-ish", I would say. As a native speaker of neither German nor English, though.
It doesn't merely sound like it, it is a German word, translating to current/present.
https://www.dwds.de/wb/jetzig
https://de.wiktionary.org/wiki/jetzig
https://www.duden.de/rechtschreibung/jetzig
It's a perfectly fine name. There's a billion dollar web framework company named Zeit which famously built https://now.sh
They rebranded to Vercel, most likely because Zeit turned out to not be a perfectly fine name.
I'd propose Zig have a specific version for Germany and call it Z-Germans.
Do you mean because of the newspaper called _Die Zeit_?
This site makes a big point of using the term "RESTful" repeatedly, but it seems to be JSON-based by default?
I don't know why modern web frameworks insist on continuing to misuse or misapply the term despite a fairly large amount of messaging recently about how exactly this term is misapplied, and the resurgence of frameworks and tools that do correctly apply it, e.g. HTMX, Datastar, Alpine AJAX.
Otherwise, this looks cool. I'd encourage you to un-roll-your-own docs and use something like Starlight or Docusaurus so you can have usable search and versioned docs.
That's a fight we lost two decades ago now unfortunately. Nearly any modern-ish API is a JSON-based RPC. There's nothing wrong with that, JSON RPC is a plenty fine solution for many common use cases, it just isn't REST.
Note that there is also a standard for JSON-based RPC systems, called JSON-RPC [0]. Not every JSON-based self-titled "RESTful" API uses JSON-RPC.
[0]: https://www.jsonrpc.org/
Being RESTful and the data encoding used are largely orthogonal aspects of an API.
Wikipedia RESTful article says:
> The formal REST constraints are as follows:[10]
> Client/Server – Clients are separated from servers by a well-defined interface
> Stateless – A specific client does not consume server storage when the client is "at rest"
> Cache – Responses indicate their own cacheability
> Uniform interface
> Layered system – A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way
The key line is actually this:
>An application that adheres to the REST architectural constraints may be informally described as RESTful, although this term is more commonly associated with the design of HTTP-based APIs and what are widely considered best practices regarding the "verbs" (HTTP methods) a resource responds to, while having little to do with REST as originally formulated—and is often even at odds with the concept.
Taking that to mean you disagree. However using HTTP verbs has nothing to do with using JSON or not. Notice it says "HTTP" not "HTML" APIs.
What do you think of HTMX vs Datastar for a new production app? Any key reasons to use one over the other?
Ha I came here to complain about the same thing.
Kinda makes me disappointed in the authors especially when they link to the REST wikipedia page as if they know what it means.
Nice, looks like a decent framework. I used to do a lot of python for backend web apps, but recently jumped on the hypetrain and used go for developing a web app (devops) tool. Single binary, easy deployment etc etc.
From that experience, I think this competes with go based web apps mostly. And if so, it makes a good chance at becomming succesful. Zig seams to have a better type system. Additionally the quality of documentation for this project is pretty good. That is something the go ecosystem seems to be lacking in general. The rest of the go perks are there as well. Single binary etc.
Now the ecosystem needs to catch up. Nice!
Here's a video introduction to Jetzig by one of the contributors:
Screencast #1 - Introduction https://www.youtube.com/watch?v=qeaO_MwfUII
I really like Jetzig. It just seems to make every framework decision that I think feels right. Major props to the team
Sad to see that cookie banner. One would not expect opensource project to be associated with spyware.
As much as I like Zig, I can't imagine working on something as string/list-heavy as web without a garbage collector. Not to mention having a web server without coroutines. Web services these days are just glue code between various pieces of infrastructure, you are constantly waiting on something, it just doesn't make sense to run these in full blown threads.
I don't know zig - is this query type safe in that if I change a member name in the struct it'll fail to compile? https://github.com/jetzig-framework/jetquery
usually I do this with codegen, pretty cool if zig's type system is this powerful
Also holy crap: for (cat.homes
This is like django!
Yes, all reflection in Zig is static reflection, so that should generate a compile error (although how obvious it will be is a different question).
it’s using http.zig, so only http1.1?