My favorite trivia is that busybox has built-in cgi-bin support (and `rclone serve webdav` seems remiss to not mention as well). `https://elixir.bootlin.com/busybox/1.37.0/source/networking/...`

Everything the post mentions is 100% true and well-reasoned, especially with the inclusion of pledge/chroot/etc. for dropping privileges.

There's two diametrically opposed deployment mechanisms:

1) stack towers of glop on top of each other until you're running a simple `echo "hello world"` on top of a docker container inside a vm in a proxmox server as part of a k8s cluster under a hypervisor running on remote compute...

2) just run `bash -c 'echo "hello world"'` and front it with CGI (stateless, single binary, yada yada yada...)

Take a peek at https://github.com/Domain/bash.cgi ... not that i'm suggesting that 'bash over busybox using cgi-bin' is the "proper architecture", it's more trying to illustrate that the amount of code that holds you back from being nearly truly "frameworkless" is tiny and easy to reason about.

For some of the internal tooling I'm doing for work, I've been tending towards:

    some-cmd [--json|--markdown] ...yet-more-args...

For people who find interest in weird web applications, I have been working on a game project, in C++, where the client is compiled to WebAssembly with Emscripten, and the application server is also implemented in C++ (behind nginx).

This is from pre-AI era also. The game is Civ-like. Custom engine from scratch (including both the 3D stuff, and all the web handling also).

Take a look: https://statebuilder.com/

I started a web dev company 22 years ago after developing an online menu ordering system for a restaurant I owned. I, then we, did pretty much the same thing as talked about in the posting but we used fastcgi. I started with C because I knew C. That was my real job. It ran so well, the franchise bought the software from me--and then devolved it to all the Microsoft stuff and had issues upon issues from then on out. That's another story.

I continued to make sites for other venues that needed online ordering; such as theatre companies and restaurants. All in C, fastcgi, FreeBSD, postgresql and h2o-server cause it always did what we wanted without bending to someone else's rules. It was fast and easy to make changes while changes weren't made for us or without our consent. We did very well for ourselves.

I wrote "CGI Programming Unleashed" when I was 16, a scant 31 years ago (it was published in 1996, but not written in 1996). So this sort of brings me back. Almost as much as watching people review the book 20 years later and be like "it seems dated".

I think the conclusion that CGI made sense to die then but not now is probably correct, but for a different reason.

The main reason CGI died in large part is because it wasn't fast enough. Not the only reason for sure, but this is the general consensus. Spawning cgi children was slow, etc. Solutions were built to do in-process CGI, or separate CGI daemons. This even happened per-language with in-process CGI support for Perl, etc.

In the end, as people wanted more speed, they moved away from CGI to various other ways of doing things (client side, etc).

This aspect probably no longer makes sense - i'd be shocked if you couldn't make CGI "fast enough" these days without anywhere near as many hoops. To the degree hoops are necessary, they are probably saner to implement.

That doesn't mean folks should move back to CGI of course - but as i said, it is probably accurate that the main reason it died probably does not hold up anymore.

Golang also makes it possible to serve a web site or service from a single binary. You can even avoid linking libc if you stick to core Go (CGO_ENABLED=0), and it comes with all the http and tls libraries you need to replace the traditional web server (nginx, apache, httpd) as well.

I love C and wrote some CGIs in C in the past but I don't love concurrent programming in C. While forking and execing can use shared read-only mmap on .text segments, the .bss and .data will need initialization and copying; there's unavoidable startup overhead that a threaded process avoids, and raw pthreads is kind of painful. If all you need to do is serve a low traffic site, CGI is fine.

My biggest worry would be how often the SQLite DB gets backed up because there's no way a C web server will be free of RCEs in today's world.

I disagree with the first sentence. In 199x the first people I knew making web pages dropped perl scripts, not C programs, into cgi-bin.

CGI is great. Sadly nginx doesn't support it natively as opposed to lighttpd.

I like this project for adding CGI to nginx: https://github.com/pjincz/nginx-cgi

There's also methods of starting Rack applications directly form nginx via passenger[1]. Rack is the CGI like interface for ruby webapps: https://github.com/rack/rack It easily allows for writing applications and middleware with a few lines of ruby.

[1]: https://www.phusionpassenger.com/documentation/Users%20guide...

The deeper you go into complex web technologies & frameworks, the more obvious it becomes that simplicity wins.

I remember CGI days and I have written tiny web "features" with Perl and C many years ago. All my product backends are now in Rust and SQLite but I use frameworks and libraries. Like Tokio, Auxum/Actix Web, Diesel.

I am not sure I like the idea that the binary will be called by nginx on each request. I prefer the backend binary to have state. A 256 MiB virtual instance is enough for any software shared between friends, family or even a small community.

SQLite backups are easy. I really like how I am building web apps these days. Been with PHP for 7 years and then Python for 10+ years. Single binaries are awesome. I am looking at multi-server backends as well, still 256 - 512 MiB per instance but with a shared Redis. Still with SQLite. Should easy enable medium sized business software.

A Go binary with CGO=0 and all templates/documents embedded gives you a better overall tooling and deployment experience. Put it in a scratch container for complete isolation.

> That always felt a bit strange to me: you essentially have two web servers, and one of them is also responsible for your business logic. ... CGI gives you a single web server that calls your business logic directly. It's clear who does what.

Some of that is protecting your app by using pre-existing components that nothing to do with your app or business: Load balancing, DDOS protection, ect, ect. There's no need to write this kind of stuff from scratch unless you're in some kind of performance-sensitive niche or otherwise are large enough to justify getting into these weeds.

I am very surprised at the lack of pushback. Seems like most is just glazing the simplicity of C.

I know very little of web technology, just a faint memory from when I took Odin Project years ago.But surely there are hackers out there that can give us good justification why we currently need such a long list of stack?

Why do people use : TypeScript + React + Next.js + Tailwind CSS + shadcn/ui + PostgreSQL

I honestly dont know.

Are these still needed in 2026

Maybe in just some use cases such as high interactivity + needing to scale ?

> There's no separate database server. You open the database file through SQLite's C API.

> Every request spawns a fresh process.

How does it work when multiple concurrent requests are possible? Does SQLite allow simultaneous write access from multiple processes?

Author described good ole PHP 3.

Early PHP (3 and 4) were the thin layer over the C libraries and were pretty fast and easy. it came about right when CGI was deprecated and it solved CGI's problems

came back to C/C++ for same reasons, no supply chain trouble, fits in my head, runs forever, ... here a playground for win32, using partially webview2, all batteries included, openai client , tts, stt, vpl, images, audio, video, ... comes with webview2 apps, settings (and encryption), config, rest server, ipc, testing, CLI11, postgres, installer, doc gen, modbus, OpenCV, daemon, computer use, agent memory, image tools, mcp server/client, experimental flow editor - what a fun and exciting times :) https://github.com/polymech-info/win32-boilerplate

I just really wish it had some examples of code in there to get a better idea of what is really going on. It sounds interesting.

> Process forking isn't nearly as expensive as it was; modern kernels optimize it heavily.

When I start to dig into how complex async is to debug I'm really starting to come back around to regular forking.

I wonder if it would be more efficient to skip httpd and implement the HTTP server directly in the app. It would be consistent with the idea of using C with very few dependencies, give a lot of flexibility, and avoid the overhead of CGI.

Implementing an HTTP server from scratch in C is quite simple, clients are harder though, so I would keep using libcurl.

HTTPS can be tricky though, so you probably want to delegate this part to a reverse proxy.

The time is right for AI to generate a basic C web framework just like Node Express with request, response, template, cookies, auth, db, websockets and some other libs

It would be blazing fast, for use by AI itself

Just for fun

I still like writing web applications in PHP for many of the same reasons listed here - modern PHP anyways.

I shy away from frameworks unless I am building something that I expect a large team to work on, or I specifically need multiple complex features that don't make sense to maintain.

I've written a few applications for my own personal use or targeted at friends/family recently that have no third party dependencies other than Bootstrap, which I still like more than tailwind for anything that doesn't need to look like a marketing page.

It's not very clear to me why the author has chosen C in the first place. I appreciate the effort of sharing the experience with us, anyway.

  > You need to write your own utilities to handle things like:
  > 
  >   Cookie parsing and creation.
  >   Query parameter parsing and validation.
  >   Form data parsing and validation.
  >   Escaping input for display.

Otherwise, the general idea is appealing. I always liked writing in plain C, and I felt I understood what was going on. In modern web frameworks so much of it feels magic. Just learn the incantations and cast the right spells.

> I was hesitant to write the entire frontend in C, but it wasn't nearly as painful as I imagined.

> All too many times have I:

> * Fought vim to highlight Go's html/template syntax.

> * Fought helix to detect Go templates without breaking html detection.

> * Fought rustrover to recognize jinja templates for a project using askama.

> Using C means there's no second language for your editor to half-detect, no mixed-syntax where highlighting falls apart, no plugin dance to get the two languages to cooperate.

None of that has to do with C. You can apply the exact same approach in Go, or in any other language for that matter.

Is the CGI process opening up the SQLite database for every request...? That would have the most insane contention ever.

I like everything about it EXCEPT the Apache HTTP Server (if I understood the article correctly). It should be discouraged nowadays. Its lack of progress, lack of features, poor performance and lack of security makes me never consider it again.

To give you more context. I recently closed a security gap in a customer's web server that most likely resulted in a data leak. That web server stored (of course) database backups and other personal data. The directory listing was visible and accessible from the open internet, because - note that - the .htaccess file where the access was disabled had INVALID END OF LINE CHARACTERS according to Apache (and it wasn't me who prepared it in the first place). Therefore - note - the server IGNORED that file and its default setting was OPEN ACCESS and enabled directory index. It's wrong on so many fronts. The Apache's philosophy is not "I cannot parse the config file, therefore I disable access to the directory tree until administrator notices and fixes it". It was not logged in the server logs as "invalid EOL detected". Apache after over 30 years of development cannot parse all 3 end of line sequences - the process which is TRIVIAL to the point of being ridiculous. Deciding not to include CRLF or bare CR is not about performance. It's just the decision of its makers, there's no justification these days. It violates "be liberal in what you accept and conservative in what you send". In 2026, when the cybercriminals are everywhere, just waiting for the data, scraping it all over, the server's default should be "close everything until it's explicitly open" and "if the config is broken, disable access and/or fail".

"A modern web application typically puts a web server like nginx in front and reverse-proxies to an application server written in another language like Ruby, Python, Go, or Rust. That always felt a bit strange to me: you essentially have two web servers, and one of them is also responsible for your business logic." -- Is the fundamental difference here that the business-logic binary is not always running but gets spun out with each request? This looks like a relatively minor thing, to be honest.

I was not thinking about vanilla C and CGI but I wrote my own modern web api server app in C++ (std+boost only) and I found it extremely pleasant experience. very reliable and little supply chain/dependency hell problematic too.

It’s for intranet business app so although it’s not yet production ready yet, definitively winning against many other modern approaches in web development in my consideration, and quite refreshing POC project.

I reallllly appreciated the coder's explanation of the C executable.

But the website itself is awful. I mean, it's impossible on desktop or mobile to tell what buttons are active or disabled. There is basically no UI at all to tell you what you're dealing with or what you get if you unlock it by signing up.

And I'd say I appreciate the raw simplicity of the dark mode interface, except it also looks like it's LLM-generated, even if it's not.

So, I'm not sure what the gains were here, really. I like the hand-written approach, but wish it had some sort of personality. And not to be a debbie downer, but the purpose of this site is also to entice some long tail of small game developers to pay to feature their games with influencers on youtube, twitch, etc. which, as a business model, fine, parasitic but fine, but maybe the most depressing thing I've seen all year even in the middle of the death of most of the industry. On top of that, you're making people pay to sell dead games to dead-eyed streamers on a site that looks like a fucking mortuary. At a glance, there are even more influencers dying to get paid on this site than there are shitty AI slop games going out now; and I don't even know who's playing them; so zayt gezunt to everyone involved.

The best thing about this is that it was written in C, without AI. Ostensibly. Everything else about it makes me want to shoot myself.

My art director critique: make some fucking bright pink rollovers on the buttons or something. At least. Add a stupid pink polar bear as a mascot. Don't make me feel like I'm selling my soul to satan by signing up for it.

edit I'm still confused by which assets were compiled into the C .exe. Are there assets?

Wouldn't it be even more ideal to have the webserver and app be one and the same binary, all bells and whistles included? No need for CGI at all. Just one static binary, no extra disk I/O needed to load resources (all compiled in statically). Basically you can make the OS deny this app any additional disk access for additional hardiness.

I never thought it would come full circle, but here we are. I've helped develop and huge UI application in C/C++ using basically zero frameworks (Used ImGui) and is being used productively by many people and is stable. It runs on Mac, Windows, and Linux. But have also got it fully working on Wasm64. Anything less than WASM and it would have buckled under the load. It's beautiful on Web.

A few years ago one would have thought that it would not be worth the pain to develop it in C, now with AI that is no longer a concern as well, and we're so glad we did not compromise.

It hasn't been touched in a long time, maybe that's because it's "complete", but here's a quick CGI library:

https://github.com/codazoda/cgi-lib

CGI is fine for most small businesses and individuals (blogs) but for larger SMEs and corporations you need FastCGI. CGI is just too damn slow.

I can also recommend VBMCgi as a useful library for doing CGI. Its concepts are very much underrated and underused in web development.

P.S.: its successor (VBlib) is an .exe download which I'm loath to install.

Hmm, ok for minimalism, but C is not going to minimize the pain and risk of ugly standard library and manual memory management for something that is not relevant to optimize at this level.

I'm still in the middle of reading but I wanted to comment first that I had a pleasantly surprising experience a few years ago with CGI. I hadn't thought about CGI since I was a kid and I was tasked with adding a simple dynamic page to a server that had nothing running yet except apache. For whatever reason I though to try out CGI because of how simple the page was going to be, and yeah. Would recommend

I just got C FFI working in my LLVM based language last night so I'll need to take a look at playing around with BCHS :)

From the article, "WRITING HTML AND CSS IN C ISN'T TOO BAD".

Um, any and all string handling in C is pretty miserable.

This could be a defensible choice, reasonable even, if you use Fil-C to guarantee memory safety. Otherwise, I would call it irresponsible.

i also do that way, but i also have written my own webserver so i have no cgi interface. it serves files and provides "special" sites for the application written in. I use html and css as a frontend. nealy no js code in the html. Things i hate: - applicatin status handling - mixing html, css, js and c in one file - having no web "widgets" - having to make them by myself

https://news.ycombinator.com/item?id=26271117

There is Boost in C++. It is very mature and honestly modern C++ has a lot of extremely powerful stdlib functionality and classes that will still be orders of magnitude more performant that the vast majority of the web app languages we use today. See https://www.boost.org/

Why Apache in front? I wrote my own single page C++ multi-threaded http server for our embedded needs, accepting only a single route. Nothing simplier than that. Now I also know if a client is connected or not, how many, and process the backend task accordingly. Like streaming from a camera or not.

I worked on a FORTRAN 77 CGI application in the early 00s. I think the host was Apache httpd, on some old HPUX version.

I have used ccgi.c when I needed access to system calls and PHP was too much of an attack surface.

https://github.com/moths/libccgi/blob/master/ccgi.c

Connecting any C code to the internet is a terrible idea as we have learned over and over again.

Instantly reminded me of this: source code of the first big Portuguese www portal and search engine: https://github.com/celso/sapo

I don't think "computers are faster now" (and the unspoken "LLMs write my code for me now") is a great reason to be using an inefficient design.

I never understood why we abandoned cgi apps rather than fixing them.

Not sure why but it probably had something to do with Microsoft and the browser wars.

Is it time to fix web development?

Sadly it doesn’t look like the server is source-avalaible, so we could count the number of security issues included. There is a reason why C is not used for web servers today.

How about modern web apps in shell scripts only:

https://dhuan.github.io/mock/latest/examples.html

Is BCHS still maintained?

The last update seems > 5 years ago.

https://github.com/kristapsdz/bchs

> CGI gives you a single web server that calls your business logic directly. It's clear who does what.

One could simply put a Node.js server directly on the line. And then it is crystal clear who calls the business logic. I mean, there are reasons why we use Nginx in front of it. Distribution, filtering, rate limiting, etc..

BTW, the cgi-bin competitor back in the days was JavaScript too with the Netscape Communication/Enterprise Server that supported server-side dynamic JavaScript in 1997! Funny enough. :-)

I don't understand how are they writting html in C. Is it like they are doing puts("<html>");?

My first web app in 1995 was also built like this!

Except I had no idea malloc existed and the whole thing was static arrays...

Does anyone know if Hacker News uses CGI as well? I know there's some JavaScript and AJAX magic for the interactive elements on the frontend.

Fun fact, you don't need busybox or an httpd, just open a socket on port 80. You can use openssl for port 443 or use stunnel

fcgi tends to be overlooked

Ok but what about basic features like metrics/observability, logging/alerting?

Maybe not all projects benefit from the full package but some things are now so commoditized that you should have them everywhere (and for heavier project add readiness/liveness probes, configuration management, live documentation, connection pooling, background task scheduling, dev tools like profiling and tracing)

impressive!

which also makes me wonder if it wouldn't have been more programmer-friendlier had it been written in Perl?

I am confused. Is this project open source? If yes, I could not find a link to the source code. Can someone help me?

reminds me of the deprecated C web framework https://github.com/DanielWaterworth/raphters

It is so fresh look at the old! I learnt a lot reading this article. Thank you!

I remember the days of wrangling cgi-bin on Linux hosts! Not a common paradigm these days..

I love this kind of simplicity. It's unexpectedly satisfying.

Best I can do is use a framework built on top of a framework.

Reminds me of the Vibe.d web framework for D lang. Good memories.

cgi app is basically the same idea as a Lambda. Stateless app, that can be run virtually anywhere

Not open source, apparently. Am I missing something?

Wow, you are a role model for me

And the cycle is born again. Seeing the cost of a rust conversion today, there is an argument...

"Every request spawns a fresh process" <- this is when I stopped reading to save some time for the latest news in AI. Apologies for an abrupt interrupt.

why not dietlibc/gatling/append-only-DBs?

> It was refreshing to just write C. It isn't pretty, but neither is Tailwind.

LMAO, I'm sold.

Uhm, important questions:

1: How is the database backed up? Some kind of cron job to an external server? Stored on some kind of network drive with automatic versioned recovery?

2: How will scaling be handled?

3: How is disaster recovery handled?

> One binary, a SQLite file, three dependencies and the entire thing fits in your head.

clearly AI slop

> marketyour.games

Visited this website out of curiosity, and... Please do not use Courier New as a monospace font, not even as part of a fallback. Its stem width for body text is often less than a pixel, which looks awful.

> Everything about marketyour.games is modern

I can't read any of the text on that page other than the headings. Is that what makes it modern? I assume the stack mentioned in the blog post is vibe-slop as well.

Web apps work on input text and generate text, and C is not the most text-friendly language there is. There is a reason why early CGI-BINs were usually written in Perl.

(I won't even get started on the issues of creating new software in a language that is unsafe by design, and where any performance advantage will be dwarfed by the cost of forking. Whatever floats your boat, dude.)

Yes, but why? Why really? Are you Valgrinding the s*t out of the code? What about memory leaks? No template language? Did you use an A.I. Agent? I mean, the code is probably porn for GTK/glib coders, unless it's a horror movie instead. I'm really confused on the motivation there.

"Every request spawns a fresh process. Deploying a new version is replacing one file. That means no server restart and no downtime. New requests simply pick up the new binary."

I think that's why FastCGI exists. It is the equivalent of PHP's "Swoole" or "FrankenPHP" or "amphp" or Laravel's "octane", etc. Each process is long-lived and tries to clean up its state as much as possible between requests. Forking a new process can take around 8ms (https://news.ycombinator.com/item?id=19005586)

When I was building https://github.com/Qbix/webserver in PHP, I was faced with forking a new process per request. I implemented fork-per-request at first, similar to PHP-FPM and then implemented the "FastCGI" approach of long-lived processes that clean up after each request. (Modern PHP has introspection so the engine can know what to clean up, before calling the php files to handle things.) However, some things are not really possible to completely reset in PHP, and you have to be careful with database connection pools, etc. Typically those are left open even by preforking processes like php-fpm.

Anyway, I ended up flipping it: use the "FastCGI" approach as a default, and if the original PHP code doesn't work (rare), then for that app, you can choose the regular CGI approach of forking a process per request. That way you get maximum speed by default, and manually opt into safety (this is an exception to my usual priorities).

PHP is actually quite fast. But I was also interested in transpiling it to C. So I built the transpiler at: https://ulanguage.org/playground ... used Claude to transform about 1000 PHP functions to their native equivalents, but if you use any of the others, it would hook into the Zend runtime and link with it. (There are some nuances with zvals and objects, and resources in previous PHP versions, but I managed to overcome them.) By the way, it also works with Node and Python FFI the same way.

You can basically now take PHP, Python or Javascript/Typescript code, and speed up the CPU-bound parts about 10-50x. A lot of that is because of string and JSON handling. Many web apps use strings and JSON a lot. So underneath, I had the compiler use "ropes" for the strings, and avoid concatenation. It also parallelizes the JSON encode and decode into code that can run on multiple cores at once, i.e. large JSON payloads are encoded and decoded in parallel. Those are just huge speedups.

Anyway... all of this is mostly focused on speed optimization, so you can solve the literally C100K problem (forget C10K) today, on a regular box. If you don't need speed or FastCGI, your approach is fast enough for the vast majority of applications.

PS: By the way, if you fork after your program already loaded the framework and initialized the configuration, then you can run a lot more workers, literally 10x-100x more of them, because Linux and Mac will share all the loaded memory between processes, and do Copy-On-Write only on dirty pages. And when your request is done, and the process exits, that custom memory is efficiently cleaned up by the OS. It is this feature that allowed me to finally get the best of both worlds... run all existing PHP code, that makes blocking I/O requests all over the place to the database, filesystem, network etc. while at the same time being able to handle 100,000 requests in flight at the same time! Swoole and FrankenPHP can't do that.

Who needs rust or javascript anymore when we can write all our code in C again and put an agentic zero-day hunter in the toolchain?

"Make no mistakes."

Or a comfy scripting language with a great FFI as X intended.

Bro invented php

Another interesting looking blog post that I can't bear to read without my eyes bleeding :(

[flagged]

[flagged]

This reads like slop

Many tools can achieve the same thing. I can write a note in pencil, pen, crayon etc. I will tell you a secret, but don't tell anyone: you can write it in assembly also.

Neat, though:

> I'm a minimalist at heart. I use classic Vim with zero plugins. That means no LSP, no autocomplete, no code formatters, and no AI.

yet the author gives us an AI-written blog post :p

A shame to hand code a project in C and then use AI to write a blog post.

It’s a cool project to test yourself but most of the benefits outlined would also apply to Go, Rust, etc, and then you also get memory safety thrown into the mix as well.

Decent, but a half measure. Meaning you still depend on a separate web server (httpd in this case) to actually push your sites over the wire. This limits you in terms of how expressive your web application can be (ie you cannot arbitrarily write HTTP headers or choose how to serve your clients), and in terms of performance.

A far better (and harder approach) is to actually write the whole stack yourself. Meaning the actual web application and web server are packaged from a single binary. You of course have a myriad options in how to actually implement this (the server loop can run as a separate coroutine/thread/process/etc), but overall the performance and expressiveness flexibility is limitless. On top of that you can actually get blazing fast performance compared to classical approaches.

I'd also advise everyone to avoid CGI at all costs. It's overhead is massive (new process every time, more or less) and _itself_ is a half measure since implementing a proper code hot loading/module system for servers is too much of a hassle (and standardizing it is hard). Nowadays you want to inline your server and then handle HTTP generation separately (however you'd like).