41–50 of 89 posts
CGI really is a beautiful abstraction. The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware. I wonder how true that is today, given that our machines have vastly more RAM and CPU? If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.
I love the simplicity of CGI, it was ~2002 when I read about it in a book on Linux and had my first server-side generated HTML output a couple of minutes later. But: It has no place in todays world except of educational use. Especially the fact, that every HTTP request would spawn a full new process makes it unfeasible for any serious webapp.
Even for a web-facing tool, as long as it doesn't receive more than a couple requests per second CGI is good enough, and that probably represents most web apps in existence. YAGNI principle applies, too. Most people don't work at Google of Facebook or hyper-scaling startups. A fantastic number of real-world development consists in building boring web front-ends for in-house use of random companies; and 99% of accounting forms or support tickets won't require huge performance, even running with CGI.
CGI really is a beautiful abstraction. The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware. I wonder how true that is today, given that our machines have vastly more RAM and CPU? If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.
It's unusable today, more so than it was a decade ago: - modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fine to run a perl script with no dependencies. - it prevents any form of caching. caching is very important for many use cases. - it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis…
> it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis for caching).
nutcracker, twemproxy?
CGI really is a beautiful abstraction. The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware. I wonder how true that is today, given that our machines have vastly more RAM and CPU? If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.
Fastcgi maybe? It's a little more complex but doesn't spawn process like cgi
Web frameworks are libraries/helpers on the application side to help with business logic for serving requests.
You can use CGI with web frameworks (look at the ton of useful PHP/Perl/Ruby frameworks out there).
You can also build a fully competent website without CGI OR web frameworks. Modern languages now all have built-in web servers which perform a lot better so Apache/nginx etc. need to function at most as reverse proxies.
In fact even if teaching is the goal I'd argue that Apache/CGI introduce more opaque abstractions, not less. You can create a web server and request loop in any language of choice in like 10 lines and take it from there.
There's an important point I haven't seen discussed yet: I don't believe it's possible to write secure web apps without a templating engine with safe-by-default XSS handling (i.e. interpolated text is sanitized, unless explicitly marked as trusted HTML somehow), which implies some amount of a web framework or at least a web-specific library.
I love the simplicity of CGI, it was ~2002 when I read about it in a book on Linux and had my first server-side generated HTML output a couple of minutes later. But: It has no place in todays world except of educational use. Especially the fact, that every HTTP request would spawn a full new process makes it unfeasible for any serious webapp.
> It has no place in todays world except of educational use. That's overly strong. I will create a CGI app every now and then. I can use basically any language I want. Not a lot of thought has to go into it. As the article says, it's a simple approach that makes sense for those of us that aren't so familiar with web development (we're usually making those apps for ourselves). In particular, the "you can never have to…
Like writing C in a simple console-based editor and compiling it with cc on the command line, writing raw CGI scripts like this is a great way to start and learn underlying principles. You can build some simple, even useful things and understand every bit of what is happening. It doesn't scale to what we do on the web today, of course. It's a good place to start. Not a good place to stay.
CGI really is a beautiful abstraction. The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware. I wonder how true that is today, given that our machines have vastly more RAM and CPU? If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.
There's an important point I haven't seen discussed yet: I don't believe it's possible to write secure web apps without a templating engine with safe-by-default XSS handling (i.e. interpolated text is sanitized, unless explicitly marked as trusted HTML somehow), which implies some amount of a web framework or at least a web-specific library.