Yin and Yang of modern PHP UI Frameworks
I came over this old question on StackOverflow: “Which PHP Framework will get me to a usable UI the fastest?” I couldn’t help but wonder, why people are not aware of all those other PHP UI frameworks? There are few, right? If you google for “php ui” you can find them. Those are more generally referred to as UI toolkits. But why those toolkits are not known in the mainstream?
Why there is a gap between UI toolkits and mainstream frameworks? If UI is Yin and backend is Yang – why can’t they co-exist?
Here is what I think..
Mainstream frameworks which could not deliver UI
Looking over the mainstream frameworks the usual suspects come up: symfony, codeigniter, zend, cake. All of those frameworks attempt to be general-purpose back-end frameworks. They help you organize your classes, deal with databases but all of them share their low involvement with the UI.
I see 2 conceptual reasons, why this is not happening:
Building a UI components requires a constant attention and involvement. Adding more and more features is what some of the end-users are expecting. Collaboratively developed frameworks with no commercial backing often find no time to be able to deliver a polished set of components. If you compare jQuery UI with Sencha you can see what I mean. I believe that the backend of jQuery UI is much more powerful and flexible, but they couldn’t catch up to ExtJS. jQuery have lots of extensions, but they fail to meet coding standards of jQuery UI to be adopted.
With large developer base it is difficult to make decisions. While in the back-end people often agree on what’s best practice, in the UI there are many approaches and a lot of innovation being done by each development or design team – it’s difficult to find the right choices.
UI Libraries which could not become mainstream
Those would be the likes KoolPHP, DHTMLX, Yii and more. Many of those frameworks are commercial but none of them have became mainstream. What’s the problem with those?
Poor core libraries
I guess it wouldn’t matter if you only want to build a small temporary application, but if you are planning a serious project, then extensibility and layout of back-end is important. However UI toolkits focus around building a rich interface and often neglect the backend. I am not even sure how developers are getting around that. KoolPHP says it works with Zend, Symphony, Smarty etc, but what I think they mean is – not conflicting.
Most of the UI toolkits have a very small user base and are not even showing their source code. They do not release to the open-source and maintain a very tight grip on their code.
As you see those toolkits being more developed, they add more and more features to existing classes. Grid search, filters, paginators – those are getting crammed into new releases probably based on user requests, however users can’t add those features on their own.
Yin and Yang of Web Development
My own belief is that the framework which would succeed must focus on the center of the Yin and Yang circle. It must define the UI and the backend, yet continue to be extensible.
Rule 1: Views and Objects
Look on the desktop. It consists of windows, buttons, menus and many other controls. Those controls all exist and connect with eachother. They are able to interact and send messages. Some of those views have data providers – the ways to get data from the backend.
The same thing must be maintained in a successful web application. Menu must be an object, form must be an object and a button must be an object. Like in desktop – those objects must be contained and must exist and talk with each-other. Any object should be able to render itself at any point in time by relying on it’s sub-ojects rendering capabilities.
As a result – you could say that each object on the page must have each own data provider and each other templates, which in most cases would be – the default ones.
Mainstream data-oriented frameworks fail to focus on maintaining those View / Render relationships. They do focus on models, but they pretty often leave the HTML and JS up to the developer which makes it extremely difficult to build any type of web application quickly.
UI Toolkits are great at maintaining common UI throughout application, but they fail at making those flexible. You can’t use those with your favorite jQuery plugin and you can’t affect their look in most cases. Also – apart from the ways how toolkit developers intended for those UI classes to be used – it’s difficult to create new scenarios.
Inside Agile Toolkit design philosophy of Views and Object is one of the most elegant found in any frameworks or toolkit. The interconnectivity of jQuery bindings, Data sources and connectivity between different elements keeps all the things in balance. This is one of the reasons, why implementing anything with Agile Toolkit takes so few lines of code and in most cases does not need additional HTML/JS at all. Agile Toolkit simply keeps things in control.
I have created 2 demo pages showing how much more Agile Toolkit is in control of things when compared to KoolPHP on the low level: http://demo.atk4.com/demo.html?t=31, http://demo.atk4.com/demo.html?t=32.
Rule 2: Give developers way to extend
While some may try, our approach is to build a flexible infrastructure and rely on open technologies and 3rd parties where it makes sense. How do you define extensibility? Well – Object Oriented Programming principles which I learned at the age of 12 in Pascal are very strong today.
A simple truth is – build a simple version of something. Then inherit and extend it into more powerful thing with more features. If this structure is not nicely built, you would often require to re-build classes from zero.
Both Mainstream frameworks and UI Toolkits fail to provide users a way to do something like this with user interface. UI toolkits often are compatible with PHP4 and their target audience would be clueless about inheritance anyway. They have no much reason to provide a multiple layers of UI.
The reason why there are no Accordion implementation in Agile Toolkit is because it’s so easy to create one yourself. Slap a Lister on top of a proper HTML and call $l->js()->accordion(); Or you can go ahead with 3rd party jQuery plugin. Avoiding limitations and keeping things simple and layered is another important design philosophy of Agile Toolkit which you can learn to appreciate after developing a real web application with ATK.
Rule 3: Know your limitations
It is impossible to code everything. We too – don’t have all the resources in the world. For instance – we can’t build a Grid which would suit everyone. We also can’t build a DB library which will work with all the databases. Similarly we won’t be able to build all form fields users might want to have.
Often you can find a framework which put tons of effort trying to re-invent things. Smarty tries to build language inside a template. Code-igniter maintains a set of database drivers duplicating PHP/PDO and input validation. Zend tries to re-implement Amazon AWS interfaces by duplicating all their functions in PHP instead of providing transparent SOAP wrapper. KoolPHP maintains a full-featured grid, something very similar to jqGrid.
We believe it’s not what you add into the library. It’s what you can afford to exclude – that’s what makes it worthwhile. In Agile Toolkit we did many choices when certain features were excluded. We will not create unnecessary layers and will always attempt to rely on a good 3rd party technology, which would make things work seamlessly. This is what users are used to seeing in Java and .NET and finally in PHP too.
Agile Toolkit also attempts not to make any mistakes as in other frameworks:
- Funding and OpenSource – Agile Toolkit decided to take a path between those two. To provide a completely open-sourced community version at the same time have a commercial release. To become a mainstream but at the same time be much more valuable to commercial projects.
- Core libraries – While a strong point of Agile Toolkit is UI, it does not loose in terms of good back-end design. Properly designed back-end is a ticket to longevity of any web project and it’s something we consider very seriously.
I can’t be more excited when I’m looking forward to when our website (www.agiletoolkit.org) will be launched later this year and when we will make our commercial version available.
Subscribe to our newsletter on this page: http://agiletoolkit.org/newsletter