Re^6: Alternative to CGI.pm

CGI.pm != CGI, and PSGI is sort of a false comparison here because the only indisputable part of the equation is that webapps should be persistent and CGI.pm is historically not so while the assumption with PSGI is that is it so; though it’s not necessary, it’s just the modern expectation and the tools are geared to it, unlike CGI where FCGI or something similar is necessary.

It’s certainly possible to write CGI.pm apps well, even big ones, and to deploy them persistently. It is just about a thousand times, quite literally, harder to do than it is to use a modern toolkit. The modern toolkits prevent you from painting yourself into corners and handle tons of best practices and prevent easy mistakes; giving oodles of plugins for everything from sessions to authorization and clean separation of concerns to make code portable and reuse and testing fairly trivial.

I like CGI.pm and I will still fire it up for certain things like one-offs or small site search forms. It’s lunacy or masochism to use it on a big app today. It’s not about the newest, shiny, fad. Catalyst is 12 years old and it was loosely based on an even earlier Perl framework and Ruby on Rails. This isn’t fashion, it’s webapp evolution for the better.

Everyone has different taste, needs, and tolerance for new development and learning. CGI.pm is a perfectly functional relic. It is certainly a relic though and I don’t recall seeing a webdev job posting in many years that mentioned it while they all mention Catalyst, Dancer2, or Mojolicious and most of those mention DBIx::Class.

Comment on Re^6: Alternative to CGI.pm

Replies are listed 'Best First'.
Re^7: Alternative to CGI.pm by afoken (Chancellor) on Mar 28, 2017 at 05:16 UTC
the only indisputable part of the equation is that webapps should be persistent Why? Perl interpreter startup time? For the applications that use (and wrote) in several LANs, it simply does not matter. The machines are so fast that startup time is irrelevant. Keeping code in memory to prevent slow disk access? Well, at least in the LANs mentioned above, disks are fast enough when combined with the caching done by the OS. SSDs will reduce "disk" access time even more. And by the way: keeping large frameworks out reduces the code size and the startup time. Session management? The session should persist a restart of the application, so it can also persist one restart per HTTP request. Database connection startup? See interpreter startup. The machines are fast enough so that it simply does not matter. Guaranteed cleanup? Well, CGIs are guaranteed to start up from a clean state, simply because there is no old request lingering around. Responding to every keystroke on a web page within milliseconds? Well, yes, that's a point for having a persistent application. But is that really needed in every single case? I don't think so. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^8: Alternative to CGI.pm by Your Mother (Archbishop) on Mar 28, 2017 at 05:22 UTC
No, not under every single case, especially not internal or personal—I did say I still use CGI.pm—but persistence is always better and often necessary. Just loading the libs and the DB connections and config and such at Work™ takes 6 seconds and if we have just 30 clients connecting via CGI, which we did a few years ago, the application is unusable; our Catalyst app takes 30 seconds to start. Our public/demo webapp can have a hundred clients at a time and thousands in a day + all the robots hitting it. Compile on demand CGI is ludicrous with a big app under real usage.	[reply]
Re^9: Alternative to CGI.pm by kbrannen (Beadle) on Mar 28, 2017 at 22:57 UTC
I'm going to go out on a limb and say that there is an architectural issue there. I've worked on multiple CGI projects and we start to wonder what we're doing wrong if a page takes more than 5-6s to run, starting from click to beginning to draw ... with the caveat of network latency not counting in that time. That's for the normal pages, exceptions like running reports don't count as that could require pulling GB of data out of the DB. The last place I worked doing CGI, we had nearly 300 hits per second during peak times and CGI kept up just fine, including auth/sessions and DB connections+retrievals and processing. Sure, you could feel the site slowing a little at that rate, but it wasn't painful. I'll agree that modern hardware removes a number of the old issues of CGI. Of course, your app may have special needs, lots of back-end calculations or whatever, that prevent quick take some user input to the server, process, return the result. Part of the reason I'm not overly keene on Mojo is that it pulls in over 30K lines of Perl last I looked (including parts of Moo and who knows what else). Yes, I know that CGI.pm isn't a lightweight, but changing to CGI::Simple or something like it isn't all that bad and yet gets me the basics of what I need to get the job done. I think a lot of this boils down to the choice of do you want to 'roll your own' or use someone else's code? There are so many frameworks out there that I'm very choosy when to learn a new one and it has to really wow me before I'll spend the time on it. I've yet to find a good wow-factor for the PSGI stuff; if I ever do, I'll look at switching.	[reply]
Re^10: Alternative to CGI.pm by Your Mother (Archbishop) on Mar 29, 2017 at 03:19 UTC
Re^11: Alternative to CGI.pm by kbrannen (Beadle) on Mar 29, 2017 at 18:53 UTC
Re^10: Alternative to CGI.pm by Anonymous Monk on Mar 28, 2017 at 23:56 UTC
Re^11: Alternative to CGI.pm by kbrannen (Beadle) on Mar 29, 2017 at 17:58 UTC
Re^7: Alternative to CGI.pm by kbrannen (Beadle) on Mar 27, 2017 at 14:41 UTC
Thank you, that was a thoughtful reply. If you can provide a pointer to more of this, that would be nice as it makes some sense and I'd like to read more. I do agree that it's how you put your app together, as I can write OO in C despite the language not helping out, and I can write sessions/auth/persistence/etc with CGI. Sure, you need a few helpers along the way, but CPAN is there to help so it's not all that hard. If the modern kits can be so much easier, I'd definitely like to have a pointer to some places that discuss and show that, if you have time. I've never found a good discussion on that; I guess I was searching for the wrong thing. CGI certainly has some worn spots and it's own short-comings, but it works ... or at least I'm used to it. ;)	[reply]