Anyone starting out in web development, specially PHP, will find no shortage of frameworks vying for attention. Frameworks purport to make life easier for the programmer in the long run by providing a higher-level interface with which to interact with user input.
While they have their advantages, the studious developer will be wary of any solution that projects itself as a panacea. In the end, this desire for adoption and use in every possible scenario invariably results in feature creep and bloated software.
In this article, we make the case for the use of libraries, small batches of code which provide the needed abstraction on a modular, on-demand basis. Instead of having to modify your applications to comply with the artificial confines of a framework, libraries give you, the developer, the flexibility to "plug-and-play" any needed functionality.
Advantages of frameworks#
PHP is infamous for being embeddable within HTML code. This feature promises to retain existing HTML markup while small snippets of dynamic content are strategically inserted. This is great, and even appropriate, if the only pieces of dynamic content your site requires are one-liners such as the current date, or similar.
But if you are creating a web-based application, then the best piece of advice to heed is:
Never mix code (PHP) with content (HTML).
PHP frameworks, in a nut shell, force the developer to divorce the presentation layer from the application logic, the former usually handled by HTML (or XML, JSON, etc), and the latter handled by PHP.
This is an important, and necessary step. Many frameworks, having imbibed the buzz-word Kool-Aid™, like to refer to this practice as using a Model-View-Controller (MVC) architecture. The end result is the same: the web application exposes URLs through which a user can view the current state (using the HTTP GET method), or control the state (using the HTTP POST method).
If done correctly, the same PHP logic could be made to interact with the user in any suitable presentation format, such as HTML, or XML, or JSON; these last two being specially useful as part of an API.
The problem with frameworks#
As discussed, this separation of presentation and logic is a commendable goal. But in order to achieve it, most frameworks handicap the PHP language by stuffing it inside an artificial containment, essentially creating a new, less powerful, programming language.
And they are complicated! Oh, how complicated! Extra layers upon layers of complexity added by a third-party, made impenetrable to inspection, even though it is (begrudgingly) open source! How can a consumer (in this case, the PHP developer) begin to debug the inevitable mishap with a system so thickly veiled in unnecessary obscurity?
Alternative: libraries#
By contrast, libraries epitomize the concept of staying out of the way. They operate like tiny black boxes of well-delineated functionality called upon on an as-needed basis; letting you, the developer, to continue to leverage the full spectrum of functionality proffered by the programming language.
Need to ineract with the user in XML? There's a library for that! You can call upon that library only if needed, and ignore it otherwise. Want to use HTML instead? Create a library for XHTML that derives from the XML library! Need to interact with a database? Use a well-crafted set of classes to interact with the database: a verifiable and reusable interface that can grow with the programming language, or expand to cater to different database engines.
Build your own library of tools. Make use of object-oriented programming (and, if possible, of namespaces as well) to create self-contained classes that you call upon only when needed, and never unnecessarily. The result will be code that is easier to maintain, and also easier to debug. Libraries naturally subscribe to the maxim of divide and conquer, a sage strategy for experts and novices alike.
Continue the discussion on Twitter. Follow @OpenWebSolns