A few weeks ago, I started a small project with a purpose. It’s been a while since I’d done any coding at home that would potentially be beneficial or applicable to my career. I firmly believe that developers must push themselves constantly to stay up on things, to make them not forget how to learn, and to remain nimble and able to change direction with the markets in which they live.

So I started evaluating the toolkits I’ve been hearing a lot about lately. I’ve used WebWork (prior to the Struts 2 release) and don’t feel there’s anything there for me to learn. I hate hibernate (heavy!), I’ve used iBATIS (light, but tedious!), I’m sick of Java (on the server), I run a LAMP stack on my Ubuntu server at home, and I haven’t touched PHP since 4.2.

Surprise, I settled on a LAMP stack. I need to get up to date on the latest PHP, and investigate it’s OOP model. The next question was what PHP framework to use? Oh holy dog crap in an old shopping bag. Like in the Java world, there’s a million of these frameworks for PHP. Each one has it’s own load of poop implications. Some of the frameworks seem slicker than others. Some are insane with how many ‘guidelines’ and naming-conventions they rely upon to properly generate code. I don’t want machine-generated code. I want to generate the code. It’s all part of the ‘practice’. That little requirement knocked a ton of potential frameworks off the list. I don’t want to learn YAML. I know several SQL dialects already and I know how to properly define constraints, references, and deal with locking. I don’t want a tool to do that for me. I’ll have to take more time learning the tool than I will writing my own darn SQL. So I looked and looked, and eventually I came to the same conclusion for PHP that I’ve come to multiple times working with java over the last six years.

I call this conclusion “Varner’s Paradox,” and it goes a little something like this:

Framework authors get their jollies off writing frameworks rather than solving real, honest-to-god problems. The problems they continually fail at solving are self-inflicted as a consequence of the technology stack they have chosen. These framework non-solutions to non-problems only exacerbate the situation with a new set of unacceptable trade-offs in exchange for the original set of trade-offs that first led to the development of the framework. The existence of these trade-offs leads to the development of more frameworks with entirely different approaches to solving the same set of initial problems plus the trade-offs of the prior attempt and end up delivering entirely new sets of trade-offs. Every so-called “framework” out there fails to address the one single root problem. The faulty assumption that web browsers (and HTTP) constitute a viable application interface and communication protocol for the single reason that they (browsers) can make application delivery simple.

Framework developers are trying to solve the wrong problem. Instead of focusing on improving the delivery system of real, usable applications written with rich component / event / object libraries using protocols that make sense for a client->server state-full application, they’re trying to fix the issues of how to deal with a crappy interface on a crappy protocol. They do this because the delivery of their crappy non-solution is dead-simple. Clearly, this is retarded.

So I decided to break with tradition. I wasn’t going to write your standard web-app. I’m not going to have a tightly coupled set of views that render a domain model that maps to a database using an ORM tool. I’m not going to code-generate views or controllers based on some parameters placed in specifically named files in some retarded source tree that I don’t understand. I’m not going to have something generate my database schema based on a series of YAML statements that could just as easily be bog-standard SQL92.

I’m going to write a back-end service that handles authentication, authorization, and exposes (in some way) a set of methods that can be invoked. Then I’ll write a front-end application that provides rich user-interaction, uses an internal data model that’s populated / created by parsing the results of server-side services. I’m going to write a client-server application that just happens to be delivered via HTTP, in a browser (or not!).

So I started by writing a dead-simple set of PHP clasess to allow me to invoke SQL statements and render the results as XML. I actually had to learn the semantics and syntax of PHP 5 as it relates to classes. I don’t hate it. It does a few things less nicely than other languages, but it’s not atrocious. The ability to write a destructor gave me pleasant flashbacks to C++. I’ve added user authentication and authorization and have created a baseline set of methods that allow for a client application to interact with the services directly through HTTP requests. No, it’s not SOAP or XML-RPC. I didn’t need anything that heavy-weight, and I didn’t want to deal with serialization / de-serialization of shared domain objects. That would be retarded and defeat the entire purpose of my light-weight solution.

Having the beginnings of a back-end, then next decision was what to use for a client — and that was a much more simple decision to make. I’ve used Dojo. I’ve used Prototype. I’ve used YUI widgets. I hate them all. A web browser is not a presentation component library. It never has been. Until we get past this “browsers are for presenting text” and start to model our browsers off the concepts of REBOL, they will continue to suck as client platforms. Call me a heretic, but I spit in the face of AJAX.

There’s a reason cross-platform component libraries, network protocols, and languages exist. They’re better than AJAX + HTTP. I’ll make the trade-off of using HTTP as the network protocol for now. I may manage to change that in the future, but for now, it makes sense, and I can work around the lack of state. That was the least of my concerns. As for the client component of the stack, I’m going to use Flex3 and the free SDK. I won’t be using FlexBuilder. I may end up packaging the final product as an AIR application. I may even make it work in an ‘offline’ mode. But for now, it’s going to be online only, and Flash (as opposed to AIR) delivered. So stay tuned as I start an “Adventures in Flex3″ series.

This entry was posted on Friday, April 17th, 2009 at 2:56 pm and is filed under Flex, Rants. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.