Packages: The Way Forward for PHP
philsturgeon.co.uk
philsturgeon.co.uk
Like many Ruby developers, I left PHP because I saw the kind of stagnation the author describes at the beginning of this article. I saw lots of good ideas originating and flourishing in the Ruby world, and sometimes trickling back to PHP. I saw a more well-thought-out language that seemed worthy of all that attention. So I hopped.
The libraries and library management tools and frameworks available to me now are awesome. Ruby itself is getting faster all the time. Is there really any reason left to stick with PHP other than inertia? (I don't mean that dismissively; if you have a massive existing code base, that's real inertia and changing would be a tall order.)
You can substitute Python or Node or whatever for Ruby here, but my point is: why fight the uphill battle to bring good tools to a language when other languages already have them?
- PHP is still the best at generating web pages.
- PHP offers all the tools needed to build strong applications (PHPUnit, xDebug, XHProf, ...)
- PHP is not as bad as people like to say.
And I could go on for hours on why I (and others probably) stick to PHP.
Best for generating web pages is a meaningless metric, and...
To be honest my main issue with PHP relates to the defense that "PHP is not as bad as people like to say.". I mean, really - its true. PHP5 is significantly better language than the previous versions, and people always over-exaggerate how bad it is. The problem is that PHP is not a good language.
Whenever I develop in Python/Ruby I actually enjoy the 'feel' of the language, and I'm often impressed by the power it has to do really complicated things in simple concise instructions. Most of the time when I'm working with PHP the feeling is very different. I can perform the same operations but generally theres far more cruft, and a couple manual lookups to see why functions behave differently when hashes ("arrays") have numeric indices (I'm looking at you array_merge!)
What? No. Do you have any proof of this? I have yet to come across a "normal" shared/dedicated hosting service that doesn't support PHP. That is an insane statement.
Although, it is way, way cheaper.
In terms of actually finding website hosting for an application?
Saying PHP is the hardest was likely an over-exagguration, but the market for Heroku PaaS style hosting is growing massively and its Ruby runs on it very easily.
Its not hard (at all) to find hosting for either, the only reason in my mind PHP is harder is because of how beautifully PaaS works and that its free for small applications (good luck finding a reasonable free php host -- I know they exist but you'll have to dig through a whole lot of crud first)
If you like Heroku, check out PhpFog.com or Orchestra.io. It's like magic too.
"PHP is not a good language" what is a good language? To take your example, I do enjoy the feel of PHP, it feels natural to read to me, and after years of using it I rarely have to check the documentation for function behavior (such as array_merge...).
This should not be something that takes years. I rarely have to check the documentation for similar Ruby functions after using it for only a couple months. After using PHP for 8 months straight, all day every day, I still had to look up almost every standard library function call - even if I thought I knew how it worked, I still had to check because the pervasive inconsistencies in the standard library ensured that I could never be confident in my guess.
(This is only the tip of the iceberg for why I don't like PHP and don't recommend people use it, for other reasons see: fatal errors vs. exceptions, the strange implementation of OOP (late static binding? isn't that an oxymoron?), and the numerous failing test cases / bugs that reveal themselves in every new release.)
huh? Every VPS and shared hosting provider out there has PHP hosting.
"Whenever I develop in Python/Ruby I actually enjoy the 'feel' of the language,"
I use a language not because of its feel, but about what I can create with it. PHP is by far the easiest, most supported, and has a ton of real-world examples of sites getting millions of hits/day using it successfully.
"I can perform the same operations but generally theres far more cruft, and a couple manual lookups to see why functions behave differently when hashes ("arrays") have numeric indices (I'm looking at you array_merge!)"
I agree with you there. My one main gripe with PHP is inconsistent syntax/usage. However, I dislike frameworks like RoR because it is too high-level. I feel like I don't have enough power to do some customizations and when I do need to do them in something like RoR, I have to add hacks onto it.
I realized I could just as well be using Erlang, as far as shared hosting support is concerned.
Now I'm thinking about switching to Python or Node. Or even Haskell.
- PHP is still the best at generating web pages. What?!
- PHP offers all the tools needed to build strong applications (PHPUnit, xDebug, XHProf, ...) Testing - PHP is probably the worst language I've ever written tests in, it is horrible compared to Ruby, Java, Node, Objective-C, C#. Other languages provider far better testing tools and debuggers. xDebug is horrible to setup compared to other languages where the debugger just works.
- PHP is not as bad as people like to say. I agree with this point for sure, PHP 5.3 copes with most normal object oriented stuff, but so do all the other good languages for writing web applications, only the other languages have fantastic implementations, not "not as bad as people think" implementations. If this is one of your main points in recommending a language, that is shameful.
Everyone has their own languages of preference, and personally I really dislike working with python (not too much experience in ruby) while dealing with websites. I cringe each time I'm forced to check the manual for random function behavior, but its not enough to make me move over.
What I'm really looking for is an improved version of PHP. One that keeps most of its style but removing the backwards-compatible crap. It looks like HipHop may go down that path in the near future (they've already added python-style yield generator functions)
After a lot of thought, I've arrived at the conclusion that this is because PHP has its request handler and template language all baked into the same process. It's pretty great at that - no setup required to start slinging code.
Other than that (which is significant), I'm hard-pressed to find an advantage. It's verbose, inconsistent, lacks features that've been present in other languages for years, and as the article author complains about, has no real vibrant packaging system for leveraging code re-use. Code re-use in PHP is "copy-and-paste". Yikes.
Luckily, my colleagues at the day job are supportive and through them, I'm slowly getting my head round Ruby, but only as much as the front-end stuff goes - starting a Rails project on my own would be a massive undertaking for me.
Given the choice, I'll do things in PHP because it's quicker and I have more experience on it. Jumping ship would be like abandoning 10 years of experience so I can start from scratch - I don't have the time to do that.
I use Ruby sometimes, it sure is a lovely language. That doesn't detract from the fact that PHP is still the most largely used web programming language around.
I do development work in, consult about, get paid to write about and sell commercial products using... PHP. It has the biggest potential market for me so it has the most potential customers, the most potential readers and the most potential work.
Besides, even if you personally decide to switch to Ruby the PHP community will still exist and still suffer the same problems. Those need to be fixed, no matter what.
Please do not detract from a single topic with a random "PHP v Ruby" thread. I'm not surprised but I am disappointed.
Node for example is lots of fun, but most of the libraries come complete with their bugs and lack of maturity. These are exciting things to work with, but not always best bang for the buck if you're aiming at being productive.
As for Ruby itself getting faster, well guess what PHP itself is getting faster all the time too [1]. You left it behind and it's still evolving without you. Shocker.
If you really want to see something a bit different you'd have to look at npm and node which really buck the system by installing everything locally by default. The ability for different versions of the same dependency at different points in the tree is also pretty amazing. This is the direction that composer is going with it's included autoloader and similar package syntax.
If anything composer may go even one step farther by forcing you to document your dependencies in a manifest instead of allowing you to specify an individual installation via the install command.
More power to anyone with a vision and a goal, but I'll personally leave PHP to its strength as batteries-included templating language.
People use PHP and a package manager is needed to stop people constantly rewriting the same PHP. That means a package manager is required (we have a good one now) and support is required to take it forward (hence this post).
When will people stop the "RUBY DID IT" mentality and learn to get on with what needs to be done?
1. Build stuff. 2. Sell stuff. 3. Learn to make stuff faster.
While I do agree that there is a need for a real packaging system for PHP, I don't think Composer/Packagist is the answer.
Packaging is a real hard "exercise", I've dabbled with it, and it's certainly not an easy problem. Composer/Packagist is still not there yet and its ties to Symfony are "scaring" off developers (myself for example).
If it wasn't for the outdated code, the bad peer review system, PEAR is the closest thing we have, as PHP developer, of a working packaging system. If only the PHP team would invest a bit of time to modernize it and make it relevant again, I'd give it a go for sure.
If Symfony are the only framework to use it then Packist is just going to be full of their code and not a lot else.
We use Pearfarm internally for all of our shared code, and it's super-easy to build and share packages.
Frankly I don't understand why something like Pearfarm hasn't been widely adopted, since it is essentially the same as RubyGems which is a completely workable solution for the ruby community.
I think people just don't understand that PEAR has 2 parts, the "installer" and the "official repo" and basically they write off anything related to PEAR.
In any case I'd love to hear your thoughts on why the community doesn't rally around Pearfarm, Pearhub, etc since they are basically the solution you're looking for.
You can contact me via the email addy in my HN profile.
Just give it a shot, forget how it's built, use it and please give us feedback/report issues. We're improving things on a daily basis.
It uses the process, console, and autoloader components. That being said, as a user, you need not worry about that. You put the composer.phar somewhere and invoke it.
If that isn't more useable than pyrus, I'd be interested to here what is.
I'm happy to see Flourish getting some notice, even though there doesn't seem to be a lot of love for it with the small mention. I'm happy Flourish user for well over a year now, and I feel as if Flourish's BETA tag is akin to Google's BETA tag. I honestly haven't run across a single issue with the library that would discourage me from using it in a production environment.
It's an unframework, it doesn't force MVC, but you know what? I don't need MVC for 90% of what I do. What I need to do is validate form input, accept a few file uploads, log that to a DB, kick off a few internal emails, and provide user feedback.
I think that some day I'll dig into Code Igniter, but as the only web developer/designer in the marketing department for a small company a tool that lets me stay agile and do less than conventional setups, as well as easily integrate into existing environments has been a godsend for me. It smooths out a lot of PHP's weird quirks, comes pre-baked with an amazing focus on security (oh thank god for your passion for security, @wbond), and in general just helps me get my job done.
Oh, and when people ask me what framework I use, I say "Flourish, it's like jQuery for PHP".
/fanboy
edit: One downside to Flourish is that I'm almost useless without it. What do I use to sanitize a POST variable again? How do I unescape before output? I've gotten so used to the Flourish classes I spend more time on Google than coding when I don't have access to it.
From the site: Please note that Flourish has undergone a good deal of real-world testing, and can generally be considered production ready.
It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.
At some point you need to have more classes, and where do they come from? One team of developers cannot forever add in more and more classes, that would be ridiculous.
If they allow other people to add in other classes they have an ever expanding codebase. If they dont allow developers to add in other classes then you are back to the original problem: where do I find new classes that will work with my code.
By using a package management system you distribute the workload to people who need a class, and so make it. People who have a vested interest (client project, some web service they are making, whatever) are responsible for working on a set of classes that really benefit them, like a payment library that works with Recurly, Spreedly, whatever. That should be made buy one developer, and a second developer could add in a new driver - instead of building the whole damn thing from scratch.
That is the approach package managers take, and they are much more useful than a one-man-army trying to build all the libraries.
Again if Flourish meets your requirements then great, but it certainly doesn't meet all potential requirements of the whole PHP community, package managers can with the "use whats there, build what isn't" approach.
If you dig into Flourish for a bit, you'll find that Flourish is basically aimed at being a portable, secure base layer to build stuff on top of. It gives you a platform to work in PHP one layer above the PHP functions that are largely derived from C libraries. It includes stuff like UTF-8 string functions, input filtering, arbitrary precision math and whole bunch of other stuff that will work with any kind of (semi-popular) DB on any platform with any version of PHP 5.1+.
Because of this, it isn't going to use PSR-0, or namespaces, or other new language features in PHP 5.3+. However, due to the architecture, you can successfully use it with PHP 5.3 or 5.4 and use all of the new language features in your part of the code. However, when you need to actually send a standards-compliant email with an attachment including UTF-8 content and inline images in the HTML version, fEmail has your back. Oh, and it prevents email header injection along the way. :-)
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.
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.
But I agree, whatever ZF original intention, not being simple and in-core is unfortunate.
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.
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.
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.
The open source .net community has adopted NuGet and Microsoft even endorses it by adding support into VS. This is pretty old news actually.
The need for package and dependency management is legit in the php community just as it is in every other language/community.
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.
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".
The structure of Go's standard library could be a good inspiration for restructuring PHP's standard library.
> 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.
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.
It appears frameworks can implement their own package type handlers, and specify alternate target directories, which goes a long way towards making it possible to integrate it with their own package formats.
I can see in a year or two's time the standard across PHP apps and frameworks becoming "add this add-on to your composer.json and install via `composer.phar install`"
No, you don't. You can have a system wide installation, but you can also install local copies that are just used for certain apps, and it can be managed using pear.
One of our devs even wrote a PEAR app called "comice" that allows you to easily create a sandbox and use it from the CLI.
In shared hosting, you don't have the ability to add system-wide packages. Good luck asking the hosting company to add arbitrary packages in any language. You might not even have a proper shell. There are a billion security issues to take into consideration when you try to access anything outside of your home directory. There's no standardization whatsoever about where to put files that don't need to be publicly accessible, though you could argue that cPanel's monopoly offers a quasi-standard. It shouldn't come as a surprise that just-upload-the-whole-damn-thing-yourself is the default method of deploying PHP packages and libraries.
You could come up with the best packaging system to use on your own server, but you won't be able to get any popular apps and frameworks to adopt it as long as those apps and frameworks need to support shared hosting customers. Shared hosting needs to be fixed before you can have a packaging system for PHP that is as powerful as npm, gem, and easy_install.
Composer and Pyrus both are able to install packages local to the project.
So just grab the dependencies before and then upload the "damn thing" to the server to deploy and this will work on every shared host out there.
A good packaging system, for example, will track your PHP version and extensions and make appropriate adjustments. But what if your host uses a slightly different version of PHP with a slightly different list of extensions? At best, the packaging system makes adjustments again, and you cross your fingers hoping that nothing breaks. At worst, everything breaks because your host uses the wrong version of GD or whatever.
Every shared host that supports Ruby gets mired in requests for and complaints about specific versions of gems they've installed. I don't think it will be any different for PHP.
System-wide packages are a massive pain, especially on shared hosts. That's why we took the approach of installing everything local, much like virtualenv or npm do. You get your dependencies for the project, in the project. Upload, done. It comes with an autoloader to load classes and it all works with relative paths, so moving it all around is no problem.
Obviously this only handles php libraries, not apt-get packages or whatever, there are tons of great tools for managing system configuration, and we did not set out to reinvent those. But php libraries can just be downloaded, a few of them might depend on specific extensions but mostly if you have a recent-ish PHP version stuff works on most shared hosts worth their name.
As for your point on adoption, I beg to differ. Symfony which is one of the largest frameworks will use it in it's upcoming 2.1 release, I know of a few other frameworks that are looking into it, many libraries are already made available. Even major apps like Drupal have been looking into using it, not for their plugins at first, only for their own dependencies, but once they also discussed the adoption of it for plugins, and I know a few other CMSs have looked at it for just that, because it's easy to wrap into a web frontend to manage installation of dependencies from anywhere. I'd even argue you could convert an entire ecosystem if you have it all in one controlled database already, generating package metadata on the fly and installing from existing sources, then giving the option to plugin authors to start requiring other plugins and plain libraries instead of bundling everything in their code.
Composer is quite new and it's definitely not widely adopted yet, but things are looking way brighter than you picture them. Given the ease of use of publishing packages (basically you have to write one package definition like in npm, and then for a new release you just have to git tag and push to github), resistance from people should be pretty low. Please see docs on http://getcomposer.org/ if you are curious.
I'm all for composer if it's going to make library management easier at any level, either local or system-wide. Maybe if several well-known frameworks agree to standardize on composer as their plug-in manager of choice, you may even be able to obtain a de facto monopoly on PHP package management, and that'll be a good thing for all of us. (I'd love to see some sanity in WordPress plug-in management, too, but I guess that's a tall order.)
I just wanted to remind people that as long as you have to make concessions for the current state of shared hosting, you will hit limits at one point or another.
BTW, as for pyrus/pear, local install hardly works and it's more of an after-thought anyhow.
HN discussion: http://news.ycombinator.com/item?id=3184170
I'd like to use one tool. If you don't want files system wide - then perhaps that should be an option in the package management system.
It would seem silly and wasteful to have dozens and dozens of the same packages languishing on the same computer. So part of me thinks this needs to be handled at the filesystem level.
Or there should be a way for package managers to speak to each other. How about throwing something like apt-get and dpkg out and replacing it with something better - that can handle Gems, Python libraries, etc?
I was hosted on PHP Fog but just had to do a quick dash to Pagoda Box as their instance resizing doesn't happen quick enough.
It should be up now, might need a dscache flush. What a mess.