Andrew has talked about many distant goals in zig’s development after securing 1.0 including making game development libraries, making generalized libraries for all languages which interop with C to use, as well as taking a slice of golang’s pie in the webdev space due to the new (frankly awe inspiring) async zig features.
I have been wondering what a zig based web development stack might look like and what could follow the principle of “not leaving any performance on the table,” as zig strives for. Additionally, a focus on accessibility and being explicit being reflected in the chosen stack would be welcome as well in the zig community.
Backend
What is most obvious as an approach to the backend is projects like tokamak, http.zig, and zap as different flavors of backends which all have little to no allocations and focus on performance.
Frontend
What is more uncertain is the frontend approach, as both WASM and Hypermedia solutions such as htmx, alpine-ajax, or Datastar seem viable for updating the DOM in a server-side oriented way. As has been discussed on this forum before, the overhead of WASM to JS is minimal and will get smaller over time. In the case of HATEOAS, we have many choices, mainly centered on whether to focus on scalability (Datastar) or progressive enhancement (alpine-ajax, htmx, unpoly).
Database
Finally, the database solution for a given server would most likely be a client or wrapper around c bindings for the given database or cache being used. The sqlc zig code generator could be useful as well for productivity.
Conclusion
I am wondering if there is anything I may have missed in this picture or if you think there could be a better solution to each of these aspects of web development being used in conjunction with zig.
I forgot to mention this, but I also wanted to ask what we think should be in the standard library in terms of web development utilities (routers, http specifics) vs what should be reserved to libraries imported, since the size of such features could significantly bloat the std.
I believe the core team has said in the past that as far as HTTP client/server stuff is concerned, std will only provide the bare minimum necessary to serve the needs of the Zig compiler/toolchain itself. std.http.Client is mainly for implementing the package manager and std.http.Server is for testing the client as well as serving docs on localhost. std.http is not and will never be production-grade, and any serious endeavor should use something else.
The same goes for other web-related parts of std as well like std.json and std.wasm, they are mainly motivated by what the compiler needs in order to work with JSON output or Wasm binaries.
I personally don’t think Zig will be a good choice for any serious backend/server project any time soon. But on the web frontend side however it has a chance to really shine, specifically with regards to Wasm. Zig is already by far the easiest and most hassle-free low-level language to compile for freestanding Wasm with.
agree with @castholm
if web server should support remote ui to the device (like browser interface to openwrt based routers) - it’s ok to use zig
But for serious backend/server projects where we are talking about teams of developers , GC based languages
(like go and c#) are more suitable than C style ones
It’s my own experience
I think it’s worth trying to identify the reason for that. Can you describe the reasons why they are more suitable? Are you thinking of lack of statically enforced memory safety in Zig by chance?
Can Zig be written in a style that is well structured and conducive to maintenance by a team? I’m certainly trying to do that with my database, which is intended for backend use. I’m inspired by how Postgres is implemented in very well written C, and maintained by a team that is very happy with their use of C. It has been hardened over time and has a very good track record with regard to bugs and security.
Of course there are many types of “backend” software. Perhaps you’re thinking of web apps (edit: with low/medium performance requirements). I’m thinking of what I’d call “critical, high performance infrastructure”: shared components that must be finely tuned for maximum performance and low resource consumption. These are not thrown together quickly and are very thoroughly tested. Zig or Rust are currently the best choices for such components, not GC-based languages.
Regarding memory safety, I think it is not completely clear yet how much Zig improves, and can improve later, on C. And memory safety is not the only issue – the trade-offs between Zig and Rust are complex. I don’t think it’s possible to say one is better than the other without thoroughly understanding the details of a particular project. I tried Rust at first for my database and eventually realized it was not a good fit. I’m sure Rust is a better fit in other cases.
I come from a background of “boring” enterpise backend web development so my view is obviously a bit clouded. But like @g41797 suggests, the vast majority of web development “hype” is centered around what is useful for business. In this context, people mainly care about three things:
Is the server/backend layer secure and does it perform/scale well enough for our business?
Can we move fast in our code base and develop new features quickly?
Can we quickly onboard new (junior) developers, who are perhaps not as technologically minded and don’t have as much of an intrinsic passion for understanding computers on a low level?
Zig, because it is a low-level language and doesn’t have a mature ecosystem of libraries, is not a good fit when those are your priorities. In the time it would take for an average dev team using Zig to build a solid backend, a JS/Node or C#/ASP.NET shop building an equivalent backend would already have ran laps around them simply because of the ecosystem and language ergonomics.
There are obviously business where high performance and low-level-ness is critical and for those Zig might be a good fit once it matures further. And I would personally love to see Zig having a flourishing web ecosystem! But if you happen to work professionally with something like that, and you’re surrounded by people who like touching computers as much as you do, you’re an outlier and should consider yourself very lucky. Most people who work with web dev don’t want to even think about having to concern themselves with the types of questions Zig is good at solving, they want to type return db.Products.Where(x => x.Category == category).OrderBy(x => x.Price).ToListAsync(ct), trust that everything will just work out and move on with their day.
Thank you, that’s very well stated. I may have overreacted because the term “backend” is so broad, and I probably should have assumed that typical (non-critical, performance wise) web development was implied since this topic is about web dev. But I’m glad you’ve spelled it out.
I have seen cases where a web service has very strict performance requirements, particularly latency, meaning that a GC-based language made this very difficult to achieve. But that was very much the exception.
An idea I’ve been entertaining is that of a client-side database-driven web app. Essentially, a web site consisting of a bunch of static files with SQLite serving at the backend. End users would be able to do search and other operations requiring the sophistication of a SQL database, with everything running on their own computer.
Eliminating the server eliminates a lot of headaches. First of all, your hosting is practically zero (unless you get massive traffic). No worries about scaling. No worries about hackers defacing your site. That in turns completely sidesteps the issue of Zig’s immaturity. When you app is just a bunch of static files sitting at Cloudflare, there can be no vulnerabilities.
And the user experience is going to be fantastic, since data retrieval is near instantaneous.
It’s a promising idea, I think. For now, I only have this little proof-of-concept demo. I plan to expand on it once I finish upgrading my project to 0.15.x.
I agree with most of what has been said in this thread, but I think some of these limitations can be turned to our advantage. Although zig may not be perfect for mainstream web development, it is pretty great if you’re interested in trying new ways of doing web development. The lack of ecosystem means you rely on your own bespoke solutions for most things.
This is particularly refreshing on the frontend now that JS in the browser is so feature rich. With vanilla JS, HTML, and CSS on the frontend (no bundling, no libraries), and zig with sqlite on the backed I’m regaining the joy that web development used to give me in my early days using PHP, MySQL, and JQuery. Instead of linking up a bunch of libraries and frameworks I am actually building things and learning about web fundamentals instead of how to use the latest framework.
The backend is also more interesting since zig is more low level and prioritizes things being explicit. This makes everything very clear and understandable instead of hiding everything behind layers of abstraction deep in various libraries, only exposed to me as a consise one-liner that tells me nothing about how the result was actually accomplished. I can still abstract for readability, but I also own the rest of the code and can dive in and understand it whenever I need.
I am curious as to how much of these questions for the viability of a zig server in enterprise software are design questions for a given backend server library.
The draw of using a language like zig will always be to favor performance over feature implementation speed, but that isn’t to say its impossible to be productive given the right backend framework setup.
For the issue of being non-GC, I think the use of an arena allocator being provided to each endpoint make allocation basically a non-issue (arena.alloc()) since freeing can be handled internally.
Similarly, for security the use of comptime assertions can make server invariants much easier to follow. Not to mention comptime allows a lot of benefits for end users. An interesting use case is jetzig which uses a comptime switch between the implementations of Request and StaticRequest for different build modes like so:
This way, unnecessary building of static artifacts during development is eliminated and requires no code changes to move to release which uses the intended behavior.
Personally, I am most interested in these kinds of design decisions and being able to use something more accessible like comptime in server side code, though I can definitely see how that might not be as much of a concern for enterprise web dev.
I have to say std.http is great in 0.15.2, give it a try.
This comes from someone running pythons standard lib http server in production, just to avoid dependencies. But std.http also supports e.g
websockets. Most things it might be lacking are not that hard to fill in.
If I may add, from experience I’d say 98% of the companies are looking for velocity over resource efficiency, so it is hard to imagine a world in which Zig becomes a mainstream language for backend.
About 1.9% will care about performance and resource efficiency to the extent that perhaps they’d rewrite the solution in a new language, but that’d likely be Go or Java, as many places use PHP, Python, Ruby or JavaScript in the backend, so those would already yield a performance benefit. The reason is very likely because of easier hireability, thinking in long term maintenance of the solution.
However, for the 0.1% of the cases where Zig would be the right choice, then a very lean solution will be key, which very likely means minimizing the dependencies. We can imagine that it could even be something else then restful HTTP entirely, skipping the overhead of HTTP for local network. I’m not saying we should write our own serialization logic and transport protocols when writing Zig, but commercially speaking, unless the company is built with Zig from ground up, there’s a big chance that a Zig solution will be implemented to solve a specific problem and the less maintainability burden it has, the better.
Applying that logic to the original question, I’d say having decent networking primitives in the standard library is strategically more important to Zig that to Java, for example, which only in the recent versions added an HTTP Client (2018), Unix Sockets (2021) and is yet to release a native json implementation.
today I finished coding of something else and started to prepare documentation and template repo
I am talking about async messaging protocol
zig 0.14.1 + std.posix - nothing more
Can’t resist my 2 cents as I’ve been thinking of Web Development with Zig for a while and put some time trying to do so. And I highly think of Zig being an option at least for web development for not many but some important cases.
Backend
The ecosystem for the backend is evolving already, there are many web frameworks out there, and some of them are really fast. And I have a benchmark of those here.
And I feel like in some cases where the requirement is to build very fast, low memory usage, and reliable backend service Zig may make sense.
Frontend
Frontend powered by Web Assembly is something I would highly think of seeing web evolve with applications like Figma coming to mainstream. More people would want to build similar applications in the future seeing the possibility. I even started a project to have JSX/React like way of building frontend using Zig. Currently it has SSR and it’s pretty promising, at least to me haha.
I’ve a prototype of the project above I mentioned here. Original discussion here. And a short video showcasing it here. (Apology for too many links out )
Here is how it looks like, still need more feedback and usage to finalize all the features and syntax but it works as of now for most common things.
While if I think in numbers most people won’t want to build web applications using Zig because most people want faster development speed rather than runtime speed. But in a few cases for mission-critical applications people may want to choose Zig. And it depends on how the Zig community cares about seeing Zig in the web and keeps pushing out production-grade lib/frameworks for the web.
Actually I think zig has a future in all parts of the eco system.
When making a website why would I choose an inferior language for my backend? One of C# greatest strengths is that you can use it for your entire tech stack. You want 3D? Unity. You want backend? ASP.Net. The benefits of not only having matching contracts/transfer models but actually using the exact same code file and serializer library just removes so much uncertainty.
I would expect we’re still many years from companies without zig in their tech stack to use zig for backend. But anyone making a distributed system and already using zig, should give a zig backend serious consideration. Having a zig server that can do both web signup and rest api for your zig program helps remove the barrier between backend and the rest of the dev team.
Interesting comparison you got there. I’d honestly say httpz is the true winner (checks on all aspects and has almost the same performance behavior as zap).
Also, I agree with your thinking for backend, I think it coincides with my view though I might’ve put it in a more pessimistic way. The problem is that many companies are usually averse to change so unless the zig community grows, it might be difficult to justify. But it is an optimistic prospect nonetheless.
)