4 ms·

> 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

> 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 too many dependencies" philosophy of modern web developers is strange to me.

iratewizard 5y ago
Definitely overly strong. I don't personally use CGI because I've got a whole toolbox of pre-built starters that can scale if needed. Still, I've worked many projects that needed a simple, infrequently used microservice to do something that couldn't be done inside of an enterprise management system (read SAP, CRM, Salesforce). CGI would be an easy to maintain and perfectly acceptable solution.
bawolff 5y ago
I think its just that everyone on hacker news likes to pretend they have to scale to the size of google even though most people aren't even in the same ballpark.
- midasuni 5y ago
  Currently trying to order room service in a hotel from xxxxx.menu.org.Uk It isn’t loading, just sits there spinning. Pile of shit. I wish they’d chosen to write the service as a reliable cgi rather than some web framework where errors are eaten and hidden in Ajax calls. Uber eats let’s me place the order then vanishes when it comes to paying. Nandos yesterday told me error UK03 when I tried ordering in the restaurant, slightly better, but perhaps those more concerned with scaling to a million concurrent users could deal with 1000 reliably first.
  - whelming_wave 5y ago
    I mean, on the other hand you could be dealing with an unreliable CGI-served page where errors are eaten and hidden in ajax calls, wishing they’d used a reliable javascript framework[1] instead. [1]: an oxymoron, I know
    - midasuni 5y ago
      The point is that people spend far too much effort worrying about the ten millionth user rather than concentrating on making a reliable product for the hundred or two they have. “Can’t use cgi because we can only support 100 concurrent users per VM” is meaningless, concentrate on the real problem of building a site that doesn’t crash out silently
- littlecranky67 5y ago
  It is not necessarily about scaling the number of requests, but scaling for developers & security. You will pretty soon hit a point where you need smarter cookies access, CSRF protection, multipart/form-encoded POST requests etc. Sure, you could implement everything yourself, but this is stuff those "frameworks" already solved. I think it is also worth to mention there are plenty of "slim/light" frameworks that do very little (i.e. take care of threading, provide html request/response as writable streams, have the http headers parsed for you into a Map-like data structure etc.). Those lightweight frameworks exist i.e. express without middleware (nodeJS), Nancy (.NET), Flask (Python) etc. The "full-blown" counterparts would be ASP.NET or Django which bring far more to the table than you might need.

iratewizard 5y ago

Definitely overly strong. I don't personally use CGI because I've got a whole toolbox of pre-built starters that can scale if needed. Still, I've worked many projects that needed a simple, infrequently used microservice to do something that couldn't be done inside of an enterprise management system (read SAP, CRM, Salesforce). CGI would be an easy to maintain and perfectly acceptable solution.

bawolff 5y ago

I think its just that everyone on hacker news likes to pretend they have to scale to the size of google even though most people aren't even in the same ballpark.

midasuni 5y ago
Currently trying to order room service in a hotel from xxxxx.menu.org.Uk It isn’t loading, just sits there spinning. Pile of shit. I wish they’d chosen to write the service as a reliable cgi rather than some web framework where errors are eaten and hidden in Ajax calls. Uber eats let’s me place the order then vanishes when it comes to paying. Nandos yesterday told me error UK03 when I tried ordering in the restaurant, slightly better, but perhaps those more concerned with scaling to a million concurrent users could deal with 1000 reliably first.
- whelming_wave 5y ago
  I mean, on the other hand you could be dealing with an unreliable CGI-served page where errors are eaten and hidden in ajax calls, wishing they’d used a reliable javascript framework[1] instead. [1]: an oxymoron, I know
  - midasuni 5y ago
    The point is that people spend far too much effort worrying about the ten millionth user rather than concentrating on making a reliable product for the hundred or two they have. “Can’t use cgi because we can only support 100 concurrent users per VM” is meaningless, concentrate on the real problem of building a site that doesn’t crash out silently
littlecranky67 5y ago
It is not necessarily about scaling the number of requests, but scaling for developers & security. You will pretty soon hit a point where you need smarter cookies access, CSRF protection, multipart/form-encoded POST requests etc. Sure, you could implement everything yourself, but this is stuff those "frameworks" already solved. I think it is also worth to mention there are plenty of "slim/light" frameworks that do very little (i.e. take care of threading, provide html request/response as writable streams, have the http headers parsed for you into a Map-like data structure etc.). Those lightweight frameworks exist i.e. express without middleware (nodeJS), Nancy (.NET), Flask (Python) etc. The "full-blown" counterparts would be ASP.NET or Django which bring far more to the table than you might need.