|
in reply to Re^4: Alternative to CGI.pm
in thread Alternative to CGI.pm
> You can pick and choose a templating system in Mojo just like in everything else
That's interesting to know, but in the scheme of things, it's not worth changing that. The Mojo pages we have work as long as we don't have to change something on them, then the wailing and gnashing of teeth starts. ;-) If we're going to change the templates, we might as well rip out Mojo all together and just go with 1 tech: CGI with TT. Or at least I think that's far easier to justify as far as time spent versus what we get for the effort. IMO of course. :)
I do share the OP's thoughts on wondering why there is so much dislike for CGI. Some days I feel like there's been a "oh look, something new and shiny in the Perl world, we must migrate" phenomena at times. That's very tongue in cheek but something like that does rattle around in my head from time to time. Perhaps I haven't seen enough of the world, but I haven't seen a place where CGI really falls on its face and makes me want to search for something better. It's just so easy for all those little screens where you need to collect a some info (usually smallish) and do something with the database to show a result, which is most of what I've had to do over the years. CGI works in a practical way and gets the job done.
I'm not saying there aren't "web apps" where CGI just doesn't cut it, I'm simply saying I haven't seen them. If someone has, please bring on the tales and explain why CGI failed while PSGI worked. I'd love to read that perspective to give me something to think about.
|
Re^6: Alternative to CGI.pm
by Your Mother (Archbishop) on Mar 27, 2017 at 02:53 UTC
|
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.
| [reply] |
|
|
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] |
|
|
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] |
|
|
|
|
| |
|
| |
|
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] |
Re^6: Alternative to CGI.pm
by Anonymous Monk on Mar 27, 2017 at 02:45 UTC
|
That's interesting to know, but in the scheme of things, it's not worth changing that. The Mojo pages we have work as long as we don't have to change something on them, then the wailing and gnashing of teeth starts. ;-) If we're going to change the templates, we might as well rip out Mojo all together and just go with 1 tech: CGI with TT. Or at least I think that's far easier to justify as far as time spent versus what we get for the effort. IMO of course. :) At least this language is more clear that the limitations aren't with Mojo
The problem is choice
| [reply] |
|
|
For me, the problem is lack of understanding of what the new platforms really give me for the time I'd invest to learn, despite visiting the various sites that promote the tech. They make all kinds of claims, but I can't see significant benefits when I look at the tutorials. So I'd say it's a communication problem, probably 90% on my side, :) but still the message isn't coming across in a way that makes me think, "hey, that'd be really useful".
| [reply] |
|
|
