in reply to Re^2: Alternative to CGI.pm
in thread Alternative to CGI.pm

If the PSGI frameworks work for you and speed you up, that's really great and I'm happy it's a positive there.

For us here, no one really knows Mojolicious, so it's a struggle to work on it when something goes wrong. Yes, we could invest the time to learn it, but it's only like 3% of our code and we have so many other important things to do.

When we do have to work on the code, we find it hard to figure where/when things are happening or how it gets called. There appears to be a lot of "black magic". Now, if we understood the framework, it probably wouldn't be considered magic, but as it is, it looks like subs get called for no reason we can discern.

I don't particularly like all the code that gets pulled in because of the framework, as in many thousands of lines in extra modules no one else uses, plus an extra service (I guess you'd call it): morbo. This appears to be a problem only because our entire app isn't written with Mojo. If it was, I probably wouldn't complain about it because it'd be used for everything. But when only a tiny amount of our app uses it, it seems like a large overhead.

Mojo forces another templating system on us; we normally use Template Toolkit. OK, Mojo's templates aren't not overly hard to understand and there are even a few cool things about them, but the problem is that it's yet another exception to the rest of our code base.

There are probably a few other issues, but those are the main ones. Sure, some of this you can throw into the category of "you don't like it because it's different" and I'll even agree. But a large part of my problem with Mojo is that I can't see the benefit the framework is supposed to give me ... the small examples in the tutorials don't strike me as "wow, that'd be so helpful". Maybe I haven't found the right tutorials. (shrug) It might be great tech, but I just haven't seen why. I'm open to understanding if someone can explain it.

If you're wondering how did that bit of Mojo code get here, the answer is someone wrote it as a proof of concept and then checked it in just before he left for another job. At the time there were no controls in place to prevent that like there is now. It was also from before I started working here.

Replies are listed 'Best First'.
Re^4: Alternative to CGI.pm
by Anonymous Monk on Mar 24, 2017 at 23:47 UTC

    Mojo forces another templating system on us; we normally use Template Toolkit. OK, Mojo's templates aren't not overly hard to understand and there are even a few cool things about them, but the problem is that it's yet another exception to the rest of our code base.

    You can pick and choose a templating system in Mojo just like in everything else

    Mojolicious::Plugin::TemplateToolkit -Template Toolkit renderer plugin for Mojolicious

    Template::Provider::Mojo - Use Mojolicious to provide templates

[reply]
      > 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.
[reply]

        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]

        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]

In Section Seekers of Perl Wisdom