
A browser extension that replaces occurrences of 'serverless' with 'CGI-bin' - ghuntley
https://github.com/ghuntley/serverless-to-cgi-bin
======
viraptor
I appreciate the meme and get it as a response to everything being
"serverless" recently. But I noticed some people started repeating it
unironically, like cgi-bin was actually equivalent. I wish this project at
least acknowledged it's a meme reaction. Maybe people these days don't
remember anymore what cgi-bin really worked like? (or never worked with it?)

~~~
tannhaeuser
I'd rather say it's worrying how millenials+ raised in post-standard cloud
times are in denial of just how much they dropped the ball and are being
brainwashed to believe the cloud progress narrative where there is only
centralization and monopolization. Self-delusion to stay relevant in the job
market.

~~~
dvfjsdhgfv
I don't think you're fair here. There definitely are some that blindly believe
the hype, but I met many who clearly see through the bullshit. Mostly, it
boils down to the crucial distinction: are you building the project for
someone else or for yourself? If for someone else, of course you want to
maximize your revenue, and here the complexity of AWS &co. is an advantage.
However, if you're building something for yourself, unless you're stupid
you'll calculate well and choose the option that makes most business sense. In
many case this means renting a server or a couple of servers for a flat rate.

The sad piece of truth in your comment is that there are actually people who
seem to know only AWS (etc.) and use it for everything, whether it makes sense
or not. Well, that's their choice.

~~~
tannhaeuser
That's a great point - that there are of course those who ride the cloud wave
to milk their customers.

To get a sense of how much we're putting the cart before the horse, I
recommend taking an occasional look at a subreddit frequented by webdev
bootcampers (eg. [1] where they're hellbent to justify using React for static
sites, because that's all they really know, and even accuse dissenters of
being hiveminded).

[1]:
[https://www.reddit.com/r/webdev/comments/cxfvcw/is_react_sti...](https://www.reddit.com/r/webdev/comments/cxfvcw/is_react_still_worth_it_for_nondynamic_webpages/)

~~~
viraptor
I feel you're misrepresenting that discussion. Most people say they shouldn't
use react, some propose react to generate static content before deployment,
few raise good points for why you may want to use react even if the page is
static right now. There's always going to be an extremist opinion somewhere,
but it's really not common in the discussion you linked.

~~~
tannhaeuser
Maybe I'm biased because I've been downvoted. IMO /u/webdev has become a React
echo chamber if there ever was one; it's actually encouraging to hear that
you've got a different impression.

------
carlsborg
Ok I’ll bite. The argument here is that serverless is similar to cgi (common
gateway interface, the original way a web server handed requests to an
executable) in that they both spawn a process for each ‘dynamic’ backend
request (static files are served from a cdn in serverless model).

This is of course a false and misleading analogy - the reason spawning a new
process for each request is bad is that it doesn’t scale on a single server,
but in the serverless model the infrastructure serving this is scaled up
exactly so you don’t have to worry about this aspect.

Response times are measurably very good for go python and js, in our
experience, and aws serverless will try to reuse you running process for
subsequent requests (warm start).

And most importantly — there are no servers to manage.

~~~
deaddodo
> Response times are measurably very good for go python and js, in our
> experience, and aws serverless will try to reuse you running process for
> subsequent requests (warm start).

This is because most modern serverless implementations are closer to FastCGI
(which had similar benefits over classic CGI). But the concepts are the same.

------
InvaderFizz
Funny, reminds me of the whole cloud-to-butt thing.

On a different note, the whole serverless thing seemed weird to me until I
looked into it an realized that it kind of is cgi-bin all over again.

I love it, someone else can manage and patch the server and worry about
scaling. I just deploy my workload as a self-contained app or set of apps.
Scale is only limited by the bank account.

~~~
jasonjei
It’s a really apt comparison. Before PHP and embedded scripting with HTML, and
entire contained applications with MVC frameworks, we had our static HTML and
our CGI.

Now we have serverless and HTML that talks to our cgi-bin using JavaScript.
Life is full circle. Client/server back to the cloud, which reminds me of the
dumb-terminal/mainframe days.

~~~
quickthrower2
But the key difference is in the "why". Serving that HTML from a nearby web
server is a lot faster, and it's easier to distribute static content to a
bunch of servers around the world that are near the people requesting them.

~~~
sodabrew
Fixing this for you -> "serving a multi-megabyte bundle of Javascript that
renders the entire page through DOM manipulation" from a nearby web server is
a lot faster, "in some cases almost being as fast as fetching a single HTML
file from across the world."

------
matchagaucho
Well, maybe I'm just missing something in this meme, but...

Back in the day, deploying code to cgi-bin first required _buying_ and
_hosting_ your own server; which I have neither the time or patience to do
today.

~~~
tannhaeuser
No, it requires _renting_ a server, just like "serverless". Bringing your own
hardware was called colo(cating).

~~~
matchagaucho
Scaling still required _renting_ another server, which then went unutilized
until peak load was needed.

~~~
tannhaeuser
Or ordinary shared hosting on an Apache cluster (that isn't overcommitted)

------
eddieh
Would this be funnier if it replaced ‘container’ with ‘chroot’ too?

Maybe ‘Electron’ can be replaced by ‘JVM’?

------
jamestomasino
CGI-bin vs my butt... hmmm

