
Why PHP is obsolete (2014) - aoldoni
http://www.smashcompany.com/technology/why-php-is-obsolete
======
ChrisCinelli
Some people think PHP is obsolete because it has been around for 20 years.
Universities are usually teaching Ruby and Rails in their web programming
courses (at least in US). Not a lot of kids feel inspired to learn an "old"
language that has always had a bad reputation. And yes, the early versions of
PHP were quite a mess. The new generations of engineers prefer learning the
newest cool technologies. Nothing wrong with that.

However PHP has become a lot better. Starting from PHP 5, it started feeling a
legit language. Frameworks like CakePHP, Laravel and Symphony have shown that
PHP is capable of competing with Django with Python and Rails with Ruby.
Facebook drastically accelerated its runtime speed with the HHVM. And PHP 7
promises to be even faster.

What I like about PHP is how the runtime works: \- If something is messed up
in a controller only the requests that hit that code will have problems. The
whole application does not crash. \- The other thing I like is that you change
a file and the change is immediately available without having to restart
anything.

I love Node.js, C++, Go and Python but PHP is still a good tools in these
days.

PHP is only obsolete for those that choose not to use it.

~~~
wvenable
Programming in PHP these days doesn't seem significantly different than
programming in ASP.NET MVC or Node or maybe even Ruby. I started playing
around with Laravel recently to throw up a quick site on some free hosting I
have available and what tools does it require to manage the front-end: npm,
bower, and gulp!

PHP may be closer to death now than ever because it's becoming less distinct
as a platform.

~~~
waps
Exactly. PHP has been "embraced and extended". The essential features of PHP I
would say are easy database connectivity, and a built-in templating language.

Both of these features are now present in pretty much every server-side
framework and half the client-side ones (both angular and react have it). I
would argue that they're both messy, but it's there, and heavily used.

The big feature PHP still has that others are missing is the ease and
cheapness of deployment. Any PHP app can be very easily deployed on shared
hosting, which isn't true for ruby, asp.net, java, django or any of those. It
is "more" true for asp.net and django, but not much more.

This feature is more the result of PHP easily supporting shared hosting, which
is something all the others fail at pretty badly (yes, Google and Amazon have
implemented it in proprietary form ... that doesn't count. Needs to be open-
source, easy to implement for cheap hosters).

And really this boils down to efficiency. As ridiculous as it sounds, PHP is
currently by far the most power/money efficient language. Why ? Because of
thousands of cheap hosters easily implementing shared PHP hosting which
usually works well, certainly well enough for the vast majority of small
businesses. Ruby/Python/Go/C++/... none of them have anything like it.

Right now efficient hosting is having a "root" dns entry pointing to Google
app engine, and having an ec2/other cloud app that simply checks availability
of 2-3 cheap hosters and 403's to one of them. That means you effectively have
very cheap bandwidth (WAY cheaper than EC2 or any other cloud hoster), yet
retain the reliability/availability you need. Biggest problem is keeping
database in sync.

I can't believe companies like Microsoft/Amazon are letting this opportunity
slide, but they are (but of course that people use very power/cpu/money
inefficient hosting kind of works to their advantage).

~~~
jbergens
I think some things are connected. PHP does not have shared memory like static
members. This makes it very easy to run in on clusters. No one cares if one
server goes down and is replaced by another. This also makes it hard to write
large systems that are supposed to run in a controlled cluster and cache
things. Java and .NET are very good for those things. So PHP is good for the
web hotels and Java and .NET are better for company IT/devs or any project
where you can manage your servers for yourself (even if it is a cluster in
Amazons or MS centers).

I'm not sure what Microsoft i letting slide, they have PHP support in Azure
and .NET support (and Node etc). More expensive that the lowest cost PHP web
hotels but not expensive.

------
DigitalSea
TL;DR PHP does not have concurrency so the author has taken the viewpoint of
PHP becoming obsolete.

Concurrency is nice and while PHP out-of-the-box does not support it, I do not
think it is a deal breaker (at least not for me). As long as CMS's like
Wordpress are around and PHP remains easy to deploy and is installed on nearly
all web servers, we are not going to see PHP becoming obsolete any-time soon.

------
memracom
In particular, PHP should be obsolete now that we have many more ways of
integrating pieces of code rather than linking together subroutines in one BIG
BALL OF MUD. It is no longer necessary for an application to be written in one
language or run on one platform. Existing PHP applications could be evolved
using another language platform by taking advantage of the HTTP request to
integrate other language code. Or using a message queuing library like AMQP or
ZeroMQ.

Python and Ruby will be with us for a long time, but PERL and PHP will die an
ugly death. Facebook has already abandoned PHP in favor of a PHP subset that
runs on a modern VM platform (HHVM). We can't all do that, but we can adopt
tools that run on the JVM or take on a well-designed language like Python or
Ruby or Javascript.

On the JVM we have things like Grails on Groovy, Clojure and Scala which have
strong development teams and visions for the future.

PHP, like PERL, just doesn't fit in any more. We have moved beyond hacks and
incorporated computer science into our development platforms in order to save
time and money and fossil fuels.

~~~
ChrisCinelli
"take on a well-designed language like Python or Ruby or __Javascript __" I
like Javascript and Node.js BUT please do not call it a well-designed
language. Strict mode makes it a lot better and ECMAcript 6 is great. Even the
people that invented it recognized that it had more than a few design flaw.

As time passes and better engineers that understand computer languages get
involved in the core development, things have been drastically improved. This
is true for Javascript, Python, and, yes, also for PHP.

~~~
bhouston
I love JavaScript, but I completely agree.

Arguably the best JavaScript book is titled "JavaScript: the good parts." That
is a pretty clear message that there are a lot of bad parts around.

------
bhouston
I am pretty sure it is mostly just a few big companies whose critical code
bases are in PHP that are collectively keeping PHP alive.

Without the efforts of these few big companies, PHP would be much deader at
this point than it currently is.

BTW: When I say dead I mean for new projects. I haven't heard of anyone
creating a new product that chooses PHP unless it is the only thing they know
or it needs to interface with existing PHP. But my sample isn't scientific so
I could be very wrong.

~~~
eugeneionesco
Well, you're very wrong. PHP is the 5th most used language on github(4th if
you take CSS out)

[http://githut.info/](http://githut.info/)

~~~
bhouston
Switch to the percentage view of the languages, you'll notice that PHP's
percentage is decreasing: 7.7% -> 6.3%.

It isn't decreasing as fast as Ruby is (although that may be an artifact of
the Ruby community being a first adopter of Github), but it is still
decreasing.

C++, C#, Go, JavaScript, Java, Shell and CSS are not decreasing.

~~~
eugeneionesco
That does not mean anything. The point is, PHP is not being kept alive by just
couple of companies.

------
raspasov
I used to do a lot of PHP, and I love Clojure (all my work for the past year
has been Clojure only), so I totally get where the author is coming from.
Comparing Clojure and PHP is not even fair, whether we're talking performance,
concurrency, or elegance.

In the process of learning Clojure, I have discovered a "better" way to write
PHP:

1\. Use PHP namespaces (5.3+)

2\. Use functions in those namespaces that take mostly PHP arrays and
sometimes other params, modify them, and return new/modified arrays and params
(again, that's similar to how data flows in Clojure, albeit not "pure")

3\. Minimize or eliminate use of classes, objects, public, private, protected,
getters, setters, and other OOP goofiness; classes with static
properties/methods are OK

~~~
mst
I tend to have quite a lot of objects that are basically what I'd use complex
closures for in a lispy language - i.e. a bunch of read only attributes, then
some methods that use those as configuration/etc.

That's basically a 'bigger hammer' version of (2) though - mutable state is,
as ever, the enemy.

------
laurencei
Article is Jan 2014.

Lots has changed since then. PHP7 shows significantly performance gains that
make it super fast compared to previous versions [1].

[1]
[https://www.zend.com/en/resources/php7_infographic](https://www.zend.com/en/resources/php7_infographic)

~~~
aoldoni
Thanks, updated the title.

------
super-serial
"We have things like protected properties. We have abstract methods. We have
all this stuff that your computer science teacher told you you should be
using. I don’t care about this crap at all."

I'm a PHP developer by choice and I like that quote. I like throwing things
together - I don't use frameworks, I use libraries. By combining an ORM, a
template engine, and my own router... those things form an MVC framework that
I actually understand. The frameworks like RoR, people don't understand what's
going on when something goes wrong because they put on so much abstraction...
PHP remains simple, and I like it.

To be honest I like javascript better, but PHP has more reusable code on the
web so most things are still way easier to do in PHP than Node.js. Also I
think composer is a great package manager, it's not like PHP doesn't have a
good one.

I enjoy hacking things together and agree with Ramus that abstract classes and
protected properties are worthless. Wordpress was hacked together and it's
still doing fine... all that code and not one abstract class. That's the PHP
developer philosophy the author was looking for... we do what we want.

------
kayman
PHP is not obsolete. Quite the opposite.

HHVM by Facebook has made PHP a bit cooler.

An argument from a PHP developer (i'm not one, personally dislike it) could
be: "its good enough for facebook"

~~~
memracom
HHVM is one of the things that is making PHP obsolete. You simply cannot run a
top-level Internet business on PHP anymore. It does not work!! PERIOD!

Facebook realized this and solved the problem by building a proper platform to
run a subset of PHP which allowed them an easy migration to the new platform.
Massive companies can afford to do this, but the rest of use need to choose
safer tools with a long future ahead of them.

~~~
giaour
You're confusing the Hack language (the "subset" of PHP Facebook uses --
actually a superset, as all PHP is valid Hack) with HHVM, which is a PHP
runtime engine.

Wikipedia recently transitioned their PHP website from running on the Zend
engine to running on HHVM. It's still regular PHP code, though.

------
nine_k
PHP is not obsolete in the sense that it's still in very active use, and will
be for quite some time. There are reams of important code already written, and
some being written in PHP.

I still hope that PHP is becoming a _legacy_ technology, and fewer new
projects will be built with PHP over time, due to increased availability of
better tools.

PHP is not going to completely die any time soon, much like Cobol is still
alive and kicking in some narrow niches, to say nothing about Fortran.

------
c_prompt
This reminds me of the arguments people used to start with me (far too) many
years ago about mainframes and COBOL. "Mainframes are obsolete. They're on
there way out." "Sell your stock in any company who is still using a
mainframe."

My retort was always the same: there are many business-critical applications
mainframes run well at very large companies, and they are everywhere. It will
take many decades for that to change, if they choose to change at all. And the
cost to change over those apps will be far too large for many given the
limited benefits and IT as a cost center. Also, IBM has too much to lose if
they let the mainframe business die. They won't. They will keep improving and
encouraging the mainframe ecosystem.

(At the time, I acknowledge I didn't see Y2K as being a future issue that
would provide a burning platform that changed the industry dramatically.)

So many people walked away from those conversations shaking their heads and
saying I was crazy under their breath. 20 years later, the memory still brings
a smile to my face.

\- a proud PHP coder

------
zatkin
I think PHP is good for web development, but the syntax of the language is
really bad for people who might potentially go on to learn more languages. One
prime example of the really bad sides of PHP is the ambiguity of collections
contained within the PHP array(). Gone is the distinction of sets, linked
lists, and maps -- they're all contained in this single, uniform data type.

One frustration I encountered at a job this month was attempting to port some
code from Java to PHP, but it was a performance hit because some of the Java
code being dependent on these primitive data types that were unavailable in
PHP's core infrastructure. I heard they've planned to release these primitive
data types to resolve the ambiguity, but I have yet to see it released.

------
dsmithatx
My first real programming project was a ticket system for IBM in 2000 using
PHP 3. I have to say that I knew C, java and perl. However, for generating
HTML at the time PHP took far less time to create the pages I needed than any
other language. In fact I went from learning PHP to writing my first full
blown ticket system in a matter of two weeks. I'm terrible at programming. Now
I use Ruby and Python plus have to do C and Java for Android. I still feel PHP
was far easier to go from complete Novice to writing apps than any other
language. Maybe I just haven't become well enough versed in this web 2.0 to
know what it is I'm missing.

------
7Figures2Commas
PHP is obsolete? Apparently my bank account didn't get the memo.

------
Aeolun
I think it was quite interesting that the thing that originally made him use
PHP in 2000 is still something that's true now (integrated everything).

------
jv22222
It's a religious argument at best. Laravel is keeping php at the cutting edge
in terms of frameworks. Php 7 in terms of core features and optimization.

Essentially, the same php naysayer article crops up a few times a year for the
past 10 years.

Laravel is a pleasure to work with and excellent for any new company product
you might be building no matter how big or small.

------
thejosh
What do you call a PHP Developer? Employed.

~~~
fleitz
Just like sisyphus will always be employed.

------
kev6168
If the task is to create _content-oriented_ sites by _non-technical_ people,
who just want to put the darn thing online and maybe generate some income,
nothing comes even remotely close to PHP, after all these years.

------
brador
PHP is a fantastic hackers language.

Easy to pick up, easy to code, powerful, lots of quick tips and google answers
any problem. I'll be using it till the very end.

------
feketegy
If for the author PHP is complex, then I wonder what he considers to be
simple? :) Like CSS maybe?

------
wwweston
> The reasons to choose it in 2000 were compelling, but there is no reason to
> choose it today — the world has changed, and there are dozens of better
> choices now.

I'm not convinced that he has the reasons for choosing PHP quite right --
either circa 2000 or now.

If you're writing your own web application, really, you've always had complete
freedom in choosing the language. Saying your alternatives in 2000 were C,
Java, Perl and ASP captures the zeitgeist rather than the actual choices. For
example, Python was already a solid option (and Zope was a thing), and a few
people/companies you might have heard of even built a successful startup or
two off of _weird_ choices like Lisp or TCL. That's one of the great things
about the web: you speak HTTP/HTML, it doesn't matter what your back end is
written in.

What PHP always had going for it over other options were these things:

1) It was really easy to add to Apache-based commodity shared hosting. So
people running hosting companies did. So it was widely available on very
affordable hosting.

2) The document-as-program model. Yes, it's terrible from a "separation of
concerns" standpoint. Yes, you hate it for the right reasons. That's probably
part of what keeps you seeing its strengths:

(a) It's an easy model to grasp, and a particularly gentle step for someone
who's only written markup documents. It doesn't even _have_ to end in
spaghetti madness (though that's a popular path).

(b) The deployment story is _dead easy_.

3) Arguably one of the better online reference/tutorial sets for a long time
(much less true today, but circa 2000? yeah).

As far as I can tell, it still has most of these advantages which made it the
de facto runtime of the back-end web. And it's stayed more or less competitive
as a more serious option as various developers and high-profile users have
improved the language itself and shaped the practices of the community.

There are two things I see that may be potential sea changes, though:

1) The rise of JS on the back end presents another easy path for people who
might start as document authors and then move into front-end scripting.
_Maybe_. Node still has deployment issues and some other complexity I don't
think PHP presents. I'm keeping an eye on nginx+js, though... that story
sounds enough like Apache+PHP to me that I think there's potential.

2) Or maybe traditional shared commodity hosting doesn't matter as much
anymore. The VPS is essentially price competitive with generic hosting now. On
the other hand, that's just cost in currency, managing your own virtual server
often means more of a sysadmin/ops time investment (not always a gentle step).
But then there's containers, and I wonder if managed standardized package
configurations for them might finally mean the deployment story for other
stacks is going to get as easy as PHP (or even easier).

