Thursday, December 3, 2009

Java and PHP

I have been talking to friends from both sides of the aisle about Java and PHP and finally had a moment to get some thoughts out on the topic. To start I have grown to respect both platforms. I find while working on one platform I tend to miss attributes of the other. However those attributes are not syntactic differences, but rather concepts that impact building applications, architectures and organizations.

1. PHP, the web request engine.

To have a singular purpose allows a greater focus on getting the job done and hopefully getting it done right. PHPs one focus on being nothing more or less than a web request engine is an example of the singular mind. In contrast java has baggage. I don't just mean the technical baggage but expectations required of developers. J2SE and J2EE are volumes and developers are expected to have an understanding of diverse technologies. Some suited for building business objects, others suited for building web applications and others for building the engine itself.

2. Java, objects from the start.

In interviewing developers and asking about past projects I always found a concrete difference in java projects and php projects. Most (close to all) PHP projects started as scripts which grew out of control, could not scale and then migrated to a php-mvc framework. In contrast all java projects start off with objects and a structure to the application. Java developers will ask what does your data layer look like?

3. Java. Type Suggestions (not safety) and Package Scope.

My reasons for liking type suggestions and package scope are not to build strict applications they are to build frameworks that can scale within an organization. When building in PHP I adhere to a strict separation of API and DATA/CACHING layers. This helps developers navigate a code base, reduce time to get people up to speed on projects and diagnose root cause of bugs. You might consider type suggestions bad form but I would be fine with function setThing( string $x ) where if we passed in an array for X it would work but emit warning. My interest in type suggestions is to know how to call a method. While documentation is standard in all projects things get missed.

4. PHP. Simple Controller.

As the controller will be the entry point for every web request it's best to be as lightweight as possible. To that end since PHP is built around the web request lightweight controllers are the norm. While there are always a proliferation of frameworks out there I suggest you build your own. You can do this two ways take one from out there and strip it down or start from scratch. The basic components are the autoloader, a naming scheme and of course the logger. Why I am against committing to an existing MVC framework? Because if there was one to beat them all it would have been done already. I have been asking myself why no single framework to rule them all for 10+ years. Years ago I thought it would be struts but it never reigned supreme. Optimizing a controller/MVC framework requires company specific details. Those details are technical, strategic and process oriented. There are so many options for what is a M, a V or a C that the possible combinations guarantee that everyone will disagree on the right combination. Perhaps Domain Specific MVC requires a deeper look.

Perhaps it would be easier to build web applications and development teams from some hybrid of java and php. To me it feels like a J2WE would be the distribution of choice for building web applications. Perhaps the J2EE Web Profile, but I think just a re-invention would not gain real traction as there are some new paradigms coming. Some PHP + Java hybrid would need to treat the cloud request as a primary citizen, maybe the only citizen. The cloud request being something which understands the web request and the self determination if it was human (browsing pages, submitting data), browser based (ajax ) or machine based (api).

No comments: