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

There are several architectural issues in our code that could be improved; mostly because it was built to CGI.pm era standards which are a hodge-podge, string-manipulation oriented mess. There are dozens of issues in our code that cannot be improved. The average page loads something like 30 subpage/resources, many of which are dynamic because of deep, and legally mandated, permission issues. Lots of heavy data image processing, a dozen encrypted IO and CPU intensive dæmons running all day, indexing and reindexing millions of records all the time, and six or seven different code bases and toolsets glued together. If you suggested customer facing compile on demand code, CGI.pm or otherwise, was viable at work at Google or Amazon or any company with big, deep webapps…

Our code base has north of 30K lines of in-house code—the main code lib file alone has 17K and the main JS file has 10ishK—before a single module or C, Perl, or Java lib is loaded. With persistent execution (and enough RAM to throw at the problem) it’s a non-issue.

I wanted to outline why an MVC framework is better than home-rolled CGI.pm for a couple days. It’s too deep to go into except superficially. It boils down to a professional web application can be written in BASIC, the code library isn’t the issue. You can build a mansion with bronze age tools every bit as well as modern tools, there is no contractor in the world who would voluntarily do so and it would cost a thousand times more. The amount of work, the cost of revisions and changes, the risk of regressions, the ease of testing, the flexibility of deployment, the ease of additions like Oauth or model changes, the free development and support from the community. These things matter more than the actual application. In a framework, 90% of the support details are done for you and tested and continuously improved by dozens if not hundreds of other developers and teams. I am a CGI.pm expert. I’ve written a couple thousand CGIs with it going back to the late 90s; including Intranet stuff at Amazon that was used by thousands of employees. locate .cgi | ack -v COPY | wc -l on this new computer, a decade since I’ve written a CGI for professional reasons, still gives 218. I am not a CGI detractor. I am a webdev supporter.

I would like you consider the hubris necessary to believe that home-rolled code is going to be better, on any level, than what two decades of iterative development, deployment, and testing across several languages by the best developers in each can produce.

Replies are listed 'Best First'.
Re^11: Alternative to CGI.pm
by kbrannen (Beadle) on Mar 29, 2017 at 18:53 UTC
    It sounds like your app has some special needs. I also understand "history" influencing the design that exists today; it's something we fight here and the improvement never comes as fast as we'd like.

    > I would like you consider the hubris necessary to believe that home-rolled code is going to be better, on any level, than what two decades of iterative development, deployment, and testing across several languages by the best developers in each can produce.

    You obviously have enough experience to know that the answer to "best" is "it depends on the situation". It also sounds like you probably have the experience, like I do, to have scars from frameworks that promise so much and almost do what you want yet don't quite fit your needs.

    Perhaps the system I work on is "simplistic" enough that I don't have the same needs you do. The vast majority of our code sits in PM and SQL files that understand how to do the business logic that drives our system (the Model). The "GUI handling" parts are actually quite small in comparison, so the "Controller" aspects are simple and don't require all that much effort. Auth/Sessions are the only hard parts for us and they aren't hard given a few modules from CPAN.

    It may be a misunderstanding on my part, so feel free to educate me and anyone else who reads this, but how does a PSGI framework help me when the vast majority of our code is to support the Model part that that would have to be the same no matter what framework I use? The majority of my time in bringing up a new page is spent on (largest time sinks first) the Model part, then the Javascript for the dynamic pieces, then a page template, and finally the Controller (CGI and calls to the Model). The first 3 are framework independent (meaning I'd have to do them regardless of the chosen framework). For us, the last piece which is framework dependent is quite small.

    Please note, I'm not saying the PSGI framework couldn't be used or even helpful to us, but when you have a fully working system, then any large architectural change requires a pretty high "wow factor" to convince us that we need to learn a new framework and change. That's where I'm coming from. Perhaps we're in a niche, but the "CGI framework" we have works well for us. Performance isn't an issue either.

    If I was doing a brand new system from scratch, I'd seriously consider a good framework that made my life easier, but I've yet to find an article/something that communicates to me concrete whats & whys that the various frameworks have which will make my life significantly easier. I fully recognize that's most likely a failure on my part and why I ask for pointers to places that have good explanations. I also fully recognize that what I probably really need to see is not some simple tutorials, but a fully working medium-sized system based on a PSGI framework. One of these days I'll go look for such a beast on Github and see what I find and if that helps me understand.

[reply]

In Section Seekers of Perl Wisdom