That's it, I'm sold. I'm building my startup around CGI scripts! /s
Myths About CGI Scalability
11–20 of 57 posts
Re: Myths About CGI Scalability
#12It doesn't always lead anywhere, but it can be useful to revisit old patterns because sometimes there have been enough advances in either speed or logistics to make them relevant again. Reinvigorated echoes of old ideas spring up all the time and it's fun to see (I'm currently a huge fan of the new SQLite scene and also new uses being found for VMs thanks to Firecracker).
Starting up a process is now so trivial, efficient and fast that there are certainly places where a CGI-like approach could scale a long way! Quite a bit of what's been going on in the "serverless" space has parallels, including some of the optimizations made to scale it up.
Re: Myths About CGI Scalability
#13There's no publication date and archive.org's earliest snapshot is 2007. For which decade is this advice relevant?
The article is an explanation (defense?) of the author's library Powtils[0], which was created in February 2004[1]. Even in 2004 I think it would have been extremely unusual to write web applications in Pascal and serve them via CGI. The first edition of Lazarus was released in 2001, and the name gives a hint about Pascal's popularity at the time. From what I remember of that era, PHP was dominant and FastCGI was a p…
Code was last modified two years ago: https://github.com/z505/powtils
Re: Myths About CGI Scalability
#14I really like the PHP approach of "one url, one file" by letting Apache handle the routing. I love to build a whole application by just putting a bunch of php files into a directory. And I hate that in a typical Python+Django application, I have to restart the application to see changes I make. But apart from that, Python is the nicer language. So I would like to do more web dev in Python. Most Python devs get red fa…
I'm only beginning to get into Python, but maybe the solution to the "red faces" reaction is for someone to build something like what you've described and package and present it as a fantastic new way to go.
Remix (https://remix.run/) is doing something like that in the JavaScript space - some of its core ideas could make a 2014 JavaScript developer bristle, but it's a great approach now and developers are loving it.
Re: Myths About CGI Scalability
#15That's it, I'm sold. I'm building my startup around CGI scripts! /s
It wasn't a typical use case, but my current business leant on a CGI script for a few years at the start. I needed to let users sign up for an email list and rather than spin up an entire app for that, I wrote a Ruby script and ran it CGI-style on httpd because the rest of the site was all static HTML files anyway. Would a dev team have ever taken such an approach? No. But when you're a solo founder, it's a privilege to use as little as is necessary.
Re: Myths About CGI Scalability
#16There's no publication date and archive.org's earliest snapshot is 2007. For which decade is this advice relevant?
Since it's talking about Perl CGI websites, the decade for which it's relevant was the 1990s. Phil Greenspun's book Database Backed Websites was published in 1997, and its coverage of CGI already started seeming rather quaint over the next few years as better approaches took over.
Perl was widely used for websites through at least 2005, mod_perl being the dominant expression of it.
Re: Myths About CGI Scalability
#17I really like the PHP approach of "one url, one file" by letting Apache handle the routing. I love to build a whole application by just putting a bunch of php files into a directory. And I hate that in a typical Python+Django application, I have to restart the application to see changes I make. But apart from that, Python is the nicer language. So I would like to do more web dev in Python. Most Python devs get red fa…
Indeed, but: - when declaring routing in code, it's harder to shoot yourself in the foot. So many php sites expose what they should not, and .httaccess is rarely crafted correctly - renaming files don't change your website - coding locally doesn't require apache if your tooling don't need it for routing. No need for stuff like EasyPhp - python dev servers automatically reload for you on changes anyway - declaring rou…
None of the points you mention are an argument against CGI for me. But it is mostly a matter of taste.
There is one point I would like to address though:
"python is slow to start"
Python is slow. Dead slow. But not to start:
echo 'print(1)' > test.py; time for i in {1..100}; do python3 test.py > /dev/null; done
echo ' test.php; time for i in {1..100}; do php test.php > /dev/null; done
Re: Myths About CGI Scalability
#18> The only way of optimizing Ruby is not to use Ruby
lol
Re: Myths About CGI Scalability
#19There's no publication date and archive.org's earliest snapshot is 2007. For which decade is this advice relevant?
The site's favicon has: Last-Modified: Sun, 04 May 2008 00:32:10 GMT Which means very little, they may have added it long after this page was written. As this page is rendered with CGI, we don't get a Last-Modified for it. That's a CGI disadvantage :p EDIT: Oh, http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=PasWiki%20Direct... says "Info on this site dates back to 2004 and may be outdated."! 2004 or earlier then.
It is also unlikely to be running on Windows, as Server 2003 (or perhaps 2008) would not last long connected to the internet.
Windows is also around 100x slower in in forking new processes, so CGI that requires this would not do well.
Re: Myths About CGI Scalability
#20I really like the PHP approach of "one url, one file" by letting Apache handle the routing. I love to build a whole application by just putting a bunch of php files into a directory. And I hate that in a typical Python+Django application, I have to restart the application to see changes I make. But apart from that, Python is the nicer language. So I would like to do more web dev in Python. Most Python devs get red fa…
PHP is now a days ran as fcgi, just like how Python, Ruby or Go runs. The Apache mod days have been left in the past.
That you can't render a python script.py like php's script.php more likely has to do with language construction difference between the two.