Can you use PHP without frameworks nowadays?

The PHP community mindset

For example, I met Ilia Alshanetsky, a contributor to the PHP core, at the PHP Barcelona conference in October. He said he’s not considering frameworks in his work. I don’t know if he meant going procedural or only avoiding incorporating frameworks as external code, but that’s a start.

The costs of frameworks

• Learning curve and lock-in: you have to work for a certain amount of time with the framework in order to become accustomed to it; then you’ll find difficult to come back as you have invested a lot of time (which is money) and lines of code into that framework. I developed my Bachelor’s thesis with SMILA, a Java framework for search applications, and half of the time went away to get it to work.
• Upgrading and version management: frameworks are similar to libraries, and they have to be upgraded regularly, and embedded in the build or in the repository.
• Errors, bugs, missing features that we difficult to push in, magic features which we would want to push out. Frameworks are another level of abstraction which opens new way for bugs and errors to get in. Thus typically, the costs of libraries integration are underestimated, and frameworks are not an exception.

How to integrate a library

The first thing you do when you integrate a library is to wrap it in an interface that your code finds easy to work with, and define only the functionalities you use in this Facade.

That’s a good way to keep a library isolated, far from the core of your codebase, so that you can swap it in the future with a similar one in case the project dies or take new directions you don’t like at all.

The catch is – you can’t do that with a framework. Framework are defined as ** libraries that call you, instead of you calling them. ** For example, in Zend Framework you define controllers as

1.class MyController extends Zend_Controller_Action
2.{
3.public function indexAction() {}
4.}

and an object of this class will be instantiated and called for you. That’s incredibly handy for generating an application from scratch, but it’s difficult to isolate. While a layer of abstraction over a library is simply a couple of interface and class, I’ve never seen someone trying to abstract away a controller by implementing different “controller drivers”. The best we can do (in PHP) is to keep controllers as small as possible.

Frameworks are catch-all facilities, that have to support many different use cases

Zend Framework, which is actually an hybrid, is easy to use as a library: you create ZendLocale, ZendTranslate, or Zend_Filter objects and compose them.

But the framework side (ZendController mainly) pushes for defining ZendLocale and ZendTranslate as global objects which magically intervene in your input and output handling. Testing code that involves a framework is a blood bath, unless the framework provides you some utility as workarounds for the magic functionalities, like ZendTest (which disactivates exits(), redirect, and Zend_Session).

Is this really cool? To manage a full application, the framework is ** littered with Singletons and global state ** (which are under rework in Zend Framework 2.0), lots of configuration, and many issues on how to define ini values, and with what names.

The folder structure is also different from standard autoload but somewhat a standard in the framework’s application (another lock-in). There are many different conventions you have to follow – uppercase names, lowercase ones, underscores, camelCase, and all-lower case.

And for what? For example, supporting multiple paths for view helpers so that some paths overwrite the previous ones magically. In your view, you could call $this->url() and the right Url view helper will be dispatched.

Do you really need that? Some of us do, but it’s a minority. I would just provide an hardcoded list of view helpers classes to inject in my view (I know class maps will probably do something like this).

The same goes for resources, plugins, form elements and decorators; Zend_Form supports filtering, validation, rendering, decoration, display groups… I never use more than half of them at a time.

** Each moving part adds to the complexity of understanding how the framework works, and how to fix it when it breaks. ** At the same time, it adds little to the developer as it is a generic implementation which will have to be tailored to the current needs anyway.

Conclusion

Summing it up, a framework tries to save you work by make you define an overly complex configuration, that has to accomodate every possible use case. This declarative approach to building an application is not always superior to the programmatic one, where you build object graphs by hand.

Is this a reason to ditch a framework? Only if you already know that your application won’t need such a complex architecture. But meanwhile, I’ll continue to make my controllers as small as possible. Hope to see your opinion in the comments.

** Fat-Free Framework is a powerful yet easy-to-use PHP micro-framework designed to help you build dynamic and robust Web applications – fast! **

Condensed in a single 55KB file, F3 gives you solid foundation, a mature code base, and a no-nonsense approach to writing Web applications. Under the hood is an easy-to-use Web development tool kit, a high-performance URL routing engine, i18n support for multilingual applications, HTML forms processor, integrated multilayer cache engine, spam and bandwidth theft protection, unit testing tools, and code profiler. It’s so small and fast – it even has a throttle for controlling Web server traffic.

Whether you’re a novice or an expert PHP programmer, F3 will get you up and running in no time. No unnecessary and painstaking installation procedures. No complex configuration required. No convoluted directory structures. It’s all object-oriented, but you can use it as a procedural code library if you know nothing about OOP. There’s no better time to start developing Web applications the easy way than right now!

No other PHP framework has three object-relational mappers for data abstraction and modeling:-

• Axon is F3’s smart mini-ORM for SQL databases. It’s just as lightweight as the framework, and it supports MySQL, SQLite, MSSQL/Sybase, dblib, and PostgreSQL. No configuration needed.
• M2 is the MongoDB mapper. F3 supports NoSQL off-the-shelf.
• Think database engines are overkill, but you want a mapper to simplify data storage and retrieval? Jig is F3’s native NoSQL implementation. It’s a lightning-fast mini-ORM that uses flat files.