Packages and frameworks are great, but they exist because they solve problems that core PHP doesn't solve well. That's why there are so many different ORM layers and databases classes and templating frameworks. For example PHP gives you the nuts and bolts to put together a database class, but there still isn't a good, reusable library I can plug in to my next web app without having to mess with details like handling exceptions for update operations and so on. (PDO is close but not there yet.)
Instead of centralizing a bunch of 3rd-party packages, PHP might better benefit by putting together a cleanly designed, optional, STL-like layer on top of the exposed nuts and bolts. Something like the powerful classes .NET provides. That way, a person could point to the official, well-documented, core-supported way of doing something like querying a database or subtracting two date objects instead of pointing to yet another "ultimate" PHP extension repository, maintained by who-knows. It might include things like rich database encapsulation, clean and obvious escaping of output for PHP's built-in template functionality, better datetime classes, and so on.
SPL is kind-of-sort-of heading in that direction, but right now it's more for things like iterators and lists--still nuts and bolts. PHP is building some of the stuff I described into the core--there's an equivalent DateTime class now, though it's still in its infancy, and PDO is getting closer and closer to being a pluggable database object. But we've still got a long way to go.
End the need for massive 3rd-party extension repositories and frameworks by building the necessary basics into the core. My dream would be to be able to have a PHP object library like the .NET ones. (Just the basics--DateTime, String, etc., not nightmares like DataGrid.) But I suspect PHP is too weighed down by its syntactical baggage and twisted history to be able to rise up to that dream.
> Packages and frameworks are great, but they exist
> because they solve problems that core PHP doesn't solve
> well. That's why there are so many different ORM layers
> and databases classes and templating frameworks.
This isn't just a PHP-centric problem. All the popular languages have package management tools that far surpass PHP's, with NPM and Ruby Gems being the most popular of the bunch. To say that packages and frameworks exist because core PHP is lacking isn't wholly correct. Packages and frameworks exist because they increase developer productivity and help to avoid recreation of the wheel on subsequent projects. While the concept of a STL-like layer is appealing, I fear it'd be hard to find widespread support. It'd be great to see the community get behind some core OOP libs for routing, request, response, auth, etc. The problem is the powers that be over at PHP.net are pretty set in their ways. This would have to be something that side-steps that altogether. The more approachable solution is to mimic NPM and Ruby Gems, allowing the community to help curate packages over github and decide which tools are appropriate for specific jobs via reviews, download counts, word of mouth, etc. It's definitely not perfect, but opens the doors for increased user contributions.
Anything that increases the friendliness and usability of PHP is a win for the community since the language isn't perceived in the greatest of light. The only way to combat the negative perceptions is to prove people wrong by making continuous improvements and keeping up growing web requirements.
Primative Objects for all basic data types would be lovely, but that is another "Wishlist Feature" that may or may not happen at some point.
The point of this article is not "What languages should PHP copy to get better", I am talking about "What PHP developers can do today with the available tools to fix things for tomorrow".
PHP has everything it needs to move to a more package-based way of working, it just needs the community to take it up.
But I think it's exactly these "wishlist features" that make frameworks/packages a necessity in the first place. If PHP had these functions well-implemented and -documented in the core, it wouldn't be necessary to have 10 different flavors of PHP frameworks and packaging systems. That's why you don't see any (or very few) 3rd-party .NET frameworks.
Instead of the community fragmenting again and creating yet another packaging system, the community should contribute directly to the PHP core to eliminate the need for frameworks and package galaxies in the first place. (Though packages would still be useful for lesser-used or shiny and new features.)
Is that practical given the political and code state of the PHP core? Maybe not. But I guess that's why I called it a "dream situation" in my OP.
I think you misunderstand. Packages are not built to fix missing features in the core of a language, they are built for everything else.
OAuth, Authentication, Twitter API interaction, ORM's and all that jazz. None of that fits into the core at all.
You say that if the core of PHP got better then we wouldn't need MVC frameworks? What about things like ASP MVC? PHP is a language. A framework is an architecture that allows websites to be built in a certain way.
Building Composer is not "splintering by building yet another package manager", it is building the package manager we never had. Barely anybody in the community uses PEAR (I have met one PEAR developer ever, and I meet a lot of PHP developers) and there are not other existing options that work.
Composer works, so the more packages can be made generic and reusable instead of just depending on one framework the better it is for the whole community. This is the only way to reduce splintered efforts.
That is all entirely beside the point of "Adding various new good features would be good". Of course it would, but I'm not talking about trying to make every PHP developer learn C and send a pull request. That is outside the scope of this article.
Very interesting! Are you thinking something more along the lines of Python's "batteries included" style standard library?
Also, it'd be great to move away from PHP's functions-in-global-namespace style standard library, towards having a set of more well engineered core OO libraries. The first examples that come to mind are: OO strings and collections libraries. I'm thinking along the lines of Ruby's Enumerable.
That is what PHP are doing, but slowly. When features are added they are often as PECL or included as classes, and not as proceedural functions.
Moving forwards it seems like PHP is making the right calls, but backwards compatibility is important to the project as PHP has more legacy code than any other web language. That doesn't mean it's dead, it just means they can't say "sod it, lets re-write everything overnight".
ZF is yet another framework, and a fairly complex-to-setup one as well.
Problem is that when a newbie searches for "how to query mysql in php", they get 100 different tutorials doing it 100 different ways using the core functions. You won't find one using ZF unless you look for it. By the time a newbie is done digesting a mountain of tutorials, they realize that they need a framework, and they either build one of their own or turn to a 3rd party one. (And ZF doesn't seem to be the most popular one either, outside of the corporate environment.)
Having a clean object library in the core would go a long way towards eliminating the very need for a framework like Zend, and give newbies a place to go for guaranteed development and documentation instead of being at the whim of a framework developer.
It's a little unfair of a comparison as .NET was released at the same time as C#. So C# never got the chance for little incorrect "how to query mssql in C#" articles.
But I agree, whatever ZF original intention, not being simple and in-core is unfortunate.
I never found ZF difficult to setup, its a core part of a lot of the PHP work ive done...not saying it solves this problem but i am surprised people find it hard to use.
Instead of centralizing a bunch of 3rd-party packages, PHP might better benefit by putting together a cleanly designed, optional, STL-like layer on top of the exposed nuts and bolts. Something like the powerful classes .NET provides. That way, a person could point to the official, well-documented, core-supported way of doing something like querying a database or subtracting two date objects instead of pointing to yet another "ultimate" PHP extension repository, maintained by who-knows. It might include things like rich database encapsulation, clean and obvious escaping of output for PHP's built-in template functionality, better datetime classes, and so on.
SPL is kind-of-sort-of heading in that direction, but right now it's more for things like iterators and lists--still nuts and bolts. PHP is building some of the stuff I described into the core--there's an equivalent DateTime class now, though it's still in its infancy, and PDO is getting closer and closer to being a pluggable database object. But we've still got a long way to go.
End the need for massive 3rd-party extension repositories and frameworks by building the necessary basics into the core. My dream would be to be able to have a PHP object library like the .NET ones. (Just the basics--DateTime, String, etc., not nightmares like DataGrid.) But I suspect PHP is too weighed down by its syntactical baggage and twisted history to be able to rise up to that dream.