Before I worked at ITS, I worked at the Weatherhead School of Management where I had a host of responsibilities one of which being developing some of the homegrown web applications. We were immersed (by our own choice) in an extremely heterogeneous environment: Debian box running Apache connecting to a MS SQL Server with authentication/authorization happening through an NT 4.x domain controller (don't even ask about the voodoo that got that all working) and all the code in tens of thousands of lines of PHP.
Well, back then, there was no PEAR::DB; and there was no Smarty. A cohort and I developed our own web application framework — a specialized web application framework, but a framework, nonetheless. We hand-rolled our own database abstraction layer to hide the MS SQL Server specifics. We turned all of the "pages" ("states," if you will) and applications into OO classes that were instantiated per use and tracked via PHP builtin session IDs passed along the URL. We had the "views" defined within each class definition leveraging a simple templating engine called FastTemplate.
No, Ruby on Rails it was not; but it worked very well, especially given the state of web development at the time and our own relative inexperience(s).
Nowadays, I primarily spend my development time doing Middleware. I don't do web application work, anymore (other than when I dip my hands into the Blog@Case internals).
As a note, doing work in the Middleware layer does not preclude HTTP. It's just that the payload going over HTTP isn't for the consumption of a browser.
Occasionally, though, I do need to program a user-interfaceable web page. Porting the mail alias web tool from Berkeley DB to Oracle or something like that. Or, maybe a new tool for internal administrators to use to view/manipulate a person's identity/account information. Whatever. What it is is not the point. How it is done is. They are done with regular, plain
chmod +x CGI scripts.
A lot of different reasons. Quite simply, the biggest reason is that I just don't have the time to install, learn, configure, tailor, and tweak a full fledged MVC web application framework just so I can port CRUD mail alias stuff. But, as more and more off these quick CGIs get cranked out; the closer and closer the lines come to showing a net win by using a full fledged MVC. Say, it takes 20 hours to get the MVC running and you, yourself, becoming comfortable enough with it. With the MVC, it only takes you an hour to deploy a simple CRUD doohickey. Just writing the CGI code, it takes you 4. At what point does it become useful to go ahead and dive in with the MVC? (Assuming the lack of prescience on your part) If you develop 4 CGIs, you've spent 16 hours doing them (4 hours apiece) versus the 24 hours with an MVC (20 hours + 1 hour a piece). 5: 20 versus 25. 6 CGIs: 24 versus 26. 7: 26 versus 27. So, at 7 CGIs, it would have benefited you to have just used an MVC in the first place. (For the sake of simplicity of comparison, I am ignoring characteristics such as maintainability, scalability, improved error reporting and logging, etc.)
What I am trying to get at is that it is time. It's time to revisit all of the scripts running off of ITS-Services and to convert them to a real web app framework.
I have no idea when I would find the time to do this between my other priorities, but I'll stick it in my super-future-work-todo-list. I just need to focus on the net win aspect of it.