If using a PHP framework is recommended for its reusability, maintainability, popularity; why would a developer create a web application which does not have many reusable parts, which is not easy to maintain, and which takes time to learn even though you can easily find another developer who used it before?!
Here are some interesting web frameworks benchmarks.
I’m always investigating, evaluating, learning and criticising. The applications I have seen so far are;
1. Old fashioned
e.g. still using ZF1.x, Symfony 1.x? Then, you missed the train!
People move on, technology moves on; you should, too!
PHP is nowadays a server-side programming language.
JavaScript is shining on frontend-side; so, use it!
Stop, using template engines and generating HTML pages on your servers!
Hence, MVC does not make sense any more, especially REST and JSON is the way to go.
SOA has always made sense!
2. Difficult to maintain
It is not the framework, it is the way you write code, that decides maintainability!
If it takes couple of hours to add a field to your schema definition, to update your ORM models, to generate upgrade scripts for your database, to update relevant templates; if you have not even thought how to manage date/time fields, boolean fields, nullable fields (I don’t even mention JSON fields yet because it can upset some NoSQL buddies); then there is something wrong! If it takes a month for a new developer to learn your codebase; then there is something wrong, seriously! If they call you in to update the codebase every year for 3-6 months; then you have not understood the software engineering course well if you ever been to one!
3. Illogical
3. a. Where can I start?! If you are using (hierarchical) YAML configuration files which are injected into a Zend_Config object, instead of simple PHP arrays, then you are a lazy programmer because you would want to edit YAML files and cache them in Memcached which will cost more unnecessary use of memory and CPU time. Why not just keep configurations for each environment in separate PHP files (i.e. production, staging, testing, etc.)? On the other hand, I think, they don’t make sense. First of all, the configuration files should be outside the codebase/repository. Simply put, developers may not be allowed to see or change configuration for some servers. That’s why you should have a simple configuration file which can be compared, replicated and modified easily for different environments.
Someone checked YAML parsing benchmarks.
3. b. If you are using 1 database server node and 15 web server nodes, then you live in a different world and you are complaining about the speed?! I’m sorry, but without pushing your database server to its limits, you have NO right to introduce other technologies to increase the performance of the overall system.
* You have to use the latest version of your database system;
* You have to do your research and fine-tune the database settings;
* You have to use proper hardware according to the role of a node in the system;
* You have to try materialized views, indexes, full-text search, replication mechanisms, etc.;
before installing another system – such as Elastic Search or Solr. If you do so, then, you have to create Gearmand jobs on every change on the records in order to replicate them in your search systems, you have to notify other web server machines using RabbitMQ or ZeroMQ, etc. It won’t be immediate.
3. c. If you create one Gearmand main worker (with subworker objects inside) to handle all the jobs, then you didn’t get the idea of processing multiple tasks. E.g. If you generate a queue of 100K emails, it will prevent any other type of worker from running.
3. d. If you created a RESTful JSON service layer in each web server node which is called locally (over HTTP) to be able to communicate with an MVC layer (Zend) which uses an ORM layer which uses DBAL (database abstraction layer) which uses PDO which uses native library to communicate with your only database server in your architecture; then, you are wasting your time there, genius, you should start your own company and become famous and rich!
3. e. If you are using a system that generates HTML pages using XML/XSLT, or another template engine because of discontent of PHP as a template engine; you are the reason why some companies are moving to Python!
3. f. If you are hesitating to use JavaScript in general but relying on it on some crucial web pages of your web application; you are one PHP web developer bound to be exterminated by Node.js
3. g. If you are using SVN (not git?) and all developers are working on the trunk and you are hoping that trunk will be kept stable all the time, then you are mistaken. Also, if you are using Continuous Integration and Unit Testing and every commit triggers a full build job and runs all unit tests, which take “ages” to complete, then you are not efficiently using your integration server. You are also not aware of advanced branching methods and you find it difficult to release features and hot-fixes on-demand, especially when a team is working on long tasks and sometimes they need to commit incomplete code to share between each other. If your team does not have advanced repository management skills then teach them!
3. h. If you are writing test cases and thinking they are unit tests but they are really not, you need to read more about unit testing. Maybe it is not really needed, and blackbox testing might suit well to test your services.
4. If you are using JIRA and you haven’t created any epics, components, target release dates, labels, etc., and if you haven’t got a physical white board and story/task tickets, you need to learn more about SCRUM/Agile methodologies. If you are not aware of JIRA plugins that connect to your code repository to relate commits to stories and allow code reviews, you need to find out.
And all of this costs money! If you ask “how?” you have to go and figure it out!