Overheads

Recently there has been a lot of criticism of PHP in larger applications. Virtually anyone in the sphere is moving away from the language, some are stuck. Some others are getting clever about and develop their own frameworks around it like Facebook HipHop. But is it all that bad? Sure, as your solution grows it becomes less and less maintainable with PHP. At some point it’s actually hard to change stuff without breaking some other and the reason lies indirectly with lack of development environments that could refactor code with enough of confidence. You can allieviate the issue with cramming more unit tests, breaking up bigger problems into services but it all can only go that long. Is there really no space for PHP in development of larger projects. Possibly. There’s still a lot of space for all the other efforts like prototyping MVPs ( (Minimal Viable Products) and really small services built up with structured code. If you think about it PHP was never built with intention of classes, types and objects. It’s all about structural code and if you take it to any other directions problems are inevitable with performance degradation leading the pack. Not all of the applications however need complex classes and object oriented approach. Think about weather broker app, or a flickr facade. Just few lines of code, hardly a screen worth of coding with some json output. This can be easily done without specifying objects and methods, or even any data types. You just need some input, a function or two and format the output. Anything else would be an overhead