PHP is the right tool for the job (for all the wrong reasons) | Hacker News Reader

PHP is the right tool for the job (for all the wrong reasons)

blog.samuellevy.com

87 pointssamuellevy143 comments

One thing I really like about PHP is it's execution model. Here, every request is mapped to a single static .php file which is executed by a single PHP interpreter process. The execution is essentially stateless (aside from any bugs in the interpreter which from what I've seen tend to be few when it comes to this issue). Essentially, every request gets its own execution environment and does not have to worry about anything outside of itself. You also get code reloading: requests currently in progress are handled by old code. New requests are handled by new code after you replace the .php file.

Contrast this with RoR/Django/nodejs/etc. Here you have to be the one controlling the process/thread. You can mess up and create a dirty execution environment. In your requests you have to be aware of what the other requests might be doing at the same time. Moreover, running two simultaneous applications requires two different execution environments (apache processes, nodejs processes, etc.) The common solution to this is to either provide some environment isolation by running one set of interpreters per application or to have a whole virtual server dedicated to every application, incurring the overhead of an OS per app.

Don't get me wrong, I detest writing code in PHP for many reasons, but the execution model is efficient: if you want more power for your applications, just increase the number of available interpreters. Moreover, every interpreter is the same, so by doubling your total number of available interpreters, you double the concurrency of all of your applications. This is the pinnacle of cloud apps: you have a simple single toggle that controls how many requests you can process concurrently. This is why shared hosting now costs $2/month while Heroku is an order of magnitude more expensive.

> You can mess up and create a dirty execution environment.

Then don't mess up. It's not that hard. If you follow best practices (don't use global variables) you should handle this fine. I haven't heard anyone having this problem in Rails at all.

> I detest writing code in PHP for many reasons, but the execution model is efficient

No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.

(Added later: Yes, this isn't how PHP actually works, and that was kinda my point: parent's concept of "PHP execution model" isn't actually used in PHP because it's stupid! There will always be some things that you want to share (connection pooling, opcode cache) so even PHP isn't a "perfect" share-nothing architecture.)

It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.

> No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.

What? This is all factually incorrect.

1) PHP has supported persistent database connections for ages. The fact is, persistent DB connections aren't really that great for websites, where you need a few resources quickly and then nothing for a long time. Having 10,000 idle DB connections is a great way to eat up resources. But you can do it.

2) PHP can use cURL's multi-handles, providing a per-application keep-alive connection pool (e.g. see Guzzle: http://guzzlephp.org/tour/http.html#managed-persistent-http-...).

3) While not part of PHP itself, most serious PHP applications use something like APC, which caches PHP opcodes to prevent constant reparsing.

>The fact is, persistent DB connections aren't really that great for websites, where you need a few resources quickly and then nothing for a long time. Having 10,000 idle DB connections is a great way to eat up resources. But you can do it.

Which is why you should be using connection pooling. Which can not be done efficiently with PHP. Necessitating that people create an entire extra layer of database proxying software to do the pooling for you.

Ah fair point, I misinterpreted the grandparent's statement in terms of persistence, not necessarily pooled persistence.

> Then don't mess up. It's not that hard. If you follow best practices (don't use global variables) you should handle this fine. I haven't heard anyone having this problem in Rails at all.

Sure, though how do you know all the library code you are using isn't going to mess things up for you? Granted, chances are small, but they are there.

> No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.

Use a cache for your bytecode to not re-parse all the time. Use a special purpose TCP proxy to keep connections open if that is your bottleneck (in most web apps it's not). Also, certain DB drivers let you have persistent connections out of the box.

> It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.

It hasn't been done yet for the price that PHP offers. It is very limited in some areas, but if you go with the grain, it is very cheap.

My main point is that two different applications cannot share an interpreter in RoR/Django/nodejs. This leads to overhead which is not there for PHP. Places like Heroku and Google App Engine try to be clever about this. You can technically shut down interpreters that aren't used frequently, and spin them back up when many requests come in, but guessing when to shut things down and spin them back up is tricky. This is why Google App Engine is so pricey: they suck at figuring this out. But even if you have a great way to figure it out, you are still going to have unpredictable performance, and the cost of waking up/spinning up an interpreter is fairly high.

> Sure, though how do you know all the library code you are using isn't going to mess things up for you? Granted, chances are small, but they are there.

> Also, certain DB drivers let you have persistent connections out of the box.

If you have connection pooling you have have a "dirty environment". PostgreSQL/MySQL makes it possible to set per-connection settings so you have no guarantee that the SQL executes in a clean environment. You might say that "oh, but the library handles the resetting for me", but how do you know all the library code you are using isn't going to mess things up for you?

You got me :). And not only is it a possibility, but actually a certainty, if you set your own settings and don't re-set them on every new connection. This is an issue with all frameworks that allow persistent connections. For example a while ago I was working on a Django app where I needed to have the timezone set to the user's timezone when talking to MySQL. This meant that on every request I'd have to re-send a query, setting the timezone even if it did nothing. Alternatively, if I relied on the default timezone being UTC, I still had to set it explicitly, because the prior request might not have cleaned up after itself properly.

In short, unless your database has a way of saying "reset all settings", you cannot have persistent connections in any environment.

Somehow I don't think that the other languages prevent you from doing what you've just described. It's entirely up to you how you write your application. OTOH, sometimes you need some shared state, if it's handled in a careful fashion (stats collecting, anyone?). The last time I saw PHP, however, low-latency shared state was really awkward to handle.

Yeah, and other languages certainly don't require a separate server instance per application. I have about 25 .NET apps running on my production server at work and it's humming along quite nicely.

So what if one of those apps gets lots of use and you want to re-allocate resources from the other 24 to it? Now you have to manually tune your server settings, or have some automated process that does this. With a PHP-like environment, that would happen automatically. Say you have 100 interpreters, so average of 4 per app. Now, app A gets 80 requests. apache automagically re-assigns 80 interpreters to app A, and others idle. No re-configuration on your part necessary.

What on earth are you talking about? You don't have to manually tune anything.

I think its a naive attempt at describing worker processes and application scope. if you have a worker process per endpoint which is common with .net apps and lots of endpoints, its quite hard to balance resources. This is true. In PHP, none of this is of consequence.

Now I've got a tiny (280mb deployable, 5 hosts, 37 application pools, 5000 in flight requests 24/7) behemoth on my hands and I can testify its an arse pain to manage resources.

I am not familiar with how .NET does this. Perhaps it has some kind of a mechanism for dealing with this. Here is an example from the Django/Python world. In your virtual host apache config you have to specify the following:

  WSGIDaemonProcess myapp processes=5 threads=5 display-name=myapp-name user=myappuser
  WSGIScriptAlias / /var/www/vhosts/example.com/apache/myapp.wsgi
  WSGIProcessGroup myapp

Notice the process=5 threads=5. This means that apache will run 5 processes, with 5 threads each. Now imagine if you have several of these apps, all configured to use 5 processes and 5 threads each, which eats up 80% of the RAM on your server. Now, app A gets featured on HN, and lots of requests come in to that app. You can only process 25 concurrent requests (and really fewer since Python's GIL prevents CPU-intensive load to be efficiently scheduled between the 5 threads per process). However, while app A is getting slammed, apps B, C, D, and E are idle. You could get more performance for app A by reducing the number of processes/threads for apps B-E and increasing the number of processes/threads for app A, but this means manually doing so and reloading apache. Less than ideal.

Edit: obviously, don't use this config example.

Your example is not a problem with using an efficient execution model, it is a problem with django/wsgi. In fact, your example is using the exact same model as apache, it just sucks at it and makes you statically define the number of workers on a per app basis. You can easily have multiple web apps running in a single application server, and the resource limits will be shared just like with a typical apache+php setup.

Note that in environments where this sort of thing is trivial to do (java for example), virtually nobody does it, preferring to run separate servers per application anyways.

The way I understand it is that you either have a pool of interpreters per app or per set of apps. In the second case, life is easy: you can have a simple system that allocates interpreters to apps on demand. In the first case, you have to have a more complex solution. Perhaps the process manage (in this case apache) could implement such a system, but thus far it has not.

There's no need for sets of interpreters at all, that's what I am saying. Python being worse at this than PHP doesn't mean PHP is good at it. Look at go for example, there's one app server, running as many apps as you want.

The terms I've heard for this is "shared nothing" - no state is shared or stored between requests.

Isn't this true for any CGI program? I know that PHP is typically run via mod_php, but what you have described is true for any CGI program.

It is somewhat expensive to startup a new interpreter process per http connection. This can be alleviated by using FastCGI, but then the interpreters are long lived and are no longer completely independent.

Yes, though PHP comes with a few goodies such as mainstream mod_php and FastCGI (which I prefer), and bytecode cache (APC). The implementation is pretty good compared to a ye olde CGI Perl script.

That may be a reason why, but far from the only reason why, Heroku is more expensive than a cheap shared hosting provider. Heroku provides a lot more than just hosting files and running server instances. They provide all kinds of value-added services in deployment, logging/monitoring, security and performance auditing, package management, git integration, database choices and plugin apps, etc etc.

>but the execution model is efficient

It is quite the opposite. It is incredibly inefficient, running hundreds of copies of the exact same code, building up an entire framework of objects to use for a single request, then trashing them all to do it again from scratch on the next request. It is easy for beginners, which is why it is so popular. But that is not the same as being efficient.

So what happens when you configure apache to run 100 processes of your Django code? If 100 clients want to view a web page, how many copies of the request object are floating around?

Or are you talking about parsing the code? At that point, something like APC would help immensely.

Are you seriously trying to compare the same execution model and then expect me to prove one of the two identical options superior? The shared nothing, single process per request execution model is the same as the shared nothing, single process per request execution model. It is not efficient compared to other models like node style non-blocking multi-plexing, or java style multi-threading, or the better options available in languages like haskell, go, clojure and erlang.

These threads always get "interesting" don't they?

A common problem I see in these kinds of discussions is engineers. Yup, you and me. In my case it took me years to move away from being a typical clueless egocentric engineer. I am sure I still am to some extent. Whatever is left pales in comparison to my younger self.

What made the change? Business. And the realities of the insanely simple business equation coupled with actually launching and running them with my own money.

There's a huge difference between holding a cat by the tail and watching someone else do it from afar. Huge.

Where I am going with this is that we (engineers and technical folk) tend to focus on, and talk about, FEATURES almost at the expense of BENEFITS. The reality of business is that the value of the former pales in comparison with that of the latter.

I love Python. However, when faced with having to do a benefits analysis it is almost impossible to not choose PHP these days. Liking it has nothing to do with making the choice. Well, it shouldn't.

I wish engineers could see what they sound like from the vantage point of a business person. You see this all the time at pitch events. There's an absolutely abysmal difference between presentations from "virgin" engineers and those who have had even a few business scars.

What type of benefits/features would you break PHP/python down to when making that choice?

I'm wondering if it is also influenced by long/short term view of the benefits. IMO PHP has extremely high short-term benefits, but many of those break down when taking a longer term view on development and maintenance (mainly because the benefits for one often end up being liabilities for the other).

>However, when faced with having to do a benefits analysis it is almost impossible to not choose PHP these days

For what? We were already heavily invested in PHP, but still our benefit analysis had it second last, only ahead of javascript. What benefits were we missing?

Each organization is going to be different.

If you have a team that already rocks on PHP, migrating people to Python is likely to be a problem.

Depending on where you are located, finding good Python programmers could be difficult (stats: over 10x more PHP programmers than Python.

If your project is pretty far along, translating to Python might carry with it a non-trivial cost.

In general terms I think it might be easier/cheaper to launch an MVP in PHP with a sensible framework (like Yii) and then migrate to Python + web2py or Django for the "real" product.

I prefer Python, but it is hard to ignore job market statistics when considering what it might take to put together a team.

I'll go out on a limb and piss off a bunch of people in the process. I'll venture the thought that most PHP-only programmers are really bad programmers. Someone not formally educated in CS or having no experience in a variety of languages (and paradigms) before adopting PHP will probably be "challenged" as a programmer in more than one way. I have a feeling that, because of the nature of the language, a larger percentage of Python programmers are really good "traditional" programmers with a good balance between theoretical and practical knowledge.

Let the flaming begin.

That's pretty much how it is, but I believe the why is largely to do with the large amount of bad PHP learning aides available for free on the internet (I'm looking at you, w3schools).

That being said, I have met (and work with) some "PHP first" programmers who are genuinely great programmers, and who get how to write clean, reusable code. "I learnt in PHP" isn't a blanket euphemism for "I'm a horrible programmer".

Your analysis of the benefits doesn't seem to be very favorable to PHP, so I am still confused as to how you came to the conclusion that using anything other than PHP is basically impossible. Again I feel the need to ask, what is it you are choosing PHP for? We were making a language choice for building a large web app that is the basis of the company. PHP rated terribly for that purpose. Setting up a blog for someone would presumably have PHP rating much better.

>In general terms I think it might be easier/cheaper to launch an MVP in PHP with a sensible framework (like Yii) and then migrate to Python + web2py or Django for the "real" product.

Why do you think that?

>I'll venture the thought that most PHP-only programmers are really bad programmers

Obviously.

Can you spot the outliers here?: "where PHP has excelled with projects like Wordpress, Joomla!, Drupal, Magento, Moodle, PHPBB, and so many more.".

Some projects "swing the PHP-way" and they are "retarded" but easy to use and fix and keep with the "fail fast, fail cheap" philosophy. Otoh, things like Drupal or Magento "swim against the tide", are hypocritically claiming to be newbie/weekend-warrior friendly, and basing your project on them lands you over-time and over-budget 90% of the time, ending up costing more than a custom made Rails app - unless you have the rare mystical creatures called "real Drupal (or Magento) gurus" working for you. It's a very weird jungle the PHP ecosystem nowadays, and lots of the creatures in it byte hard!. If you stick to riding a gentle sloth like WordPress, you're fine... but I'd suggest rapidly switching languages and technologies (something like Django + django-cms is almost as cheap and can be deployed even on dirt-cheap shared hosts) as soon as you grow over WordPress level, otherwise something will end up biting you hard!

Not sure where you work, but where I work the entire reason we are able to do websites quickly and efficiently is because of Drupal, Wordpress. We are very very rarely over budget/time.

Sure they have problems, but so does Rails, and Django.

Based on experience, I would agree with you on the Magento front (as my perpetually-in-the-planning-stages blog "I Hate Magento" will attest), but I have yet to find anything more usable (and customizable) for larger scale operations. I know there must be something less bad. Thoughts, anyone?

Agreed - its a stinking turd, but at least it's not oscommerce :)

I used to work in a Drupal shop, and all our Drupal projects were completed on time and within budget. However we also had good project management, so there weren't any 11th surprises about customizations that would be difficult to implement in the "Drupal way."

...agree, there has to be a way to do Drupal "properly", otherwise it wouldn't be so popular. But you have to agree that Drupal does need quite a lot of "special care", too much for my taste, in the way of planning and doing things its way and knowing that stuff will start randomly falling apart once you start working "against it". Things that are either "just a blog engine / just a CMS" (Wordpress) or "just a framework" (pick your fav here) are much harder to misuse and turn into a total mess. For me the whole point of using PHP is "fail fast, fail cheap, be 80% idiot-proof", and I just use Drupal as an example of outlier PHP project that went very, very far away from this mantra, but then again, maybe going away from this mindset is what you need for your projects.

The way to "do drupal properly", which makes it so popular, is to use it almost as a "lego" platform, which is also much the same as how you would use wordpress.

Both of them have such powerful plugin/extension frameworks, that most of the effort in building drupal or wordpress sites is finding the right plugins, and skinning. Very little actual programming work is required to get an operation site running for a client in either framework, which makes them ideal for many of these low-yield "corner store" sites.

That can be claimed for many other environments too. Ever tried to go outside the beaten path of Community Server?

It's an inherent issue with frameworks not with any particular language IMHO.

I don't understand why "low-skilled people can use it" is constantly trumpeted as an upside. If you can't work out how to set up the DB by hand (for example), there's little chance you're going to be able to get through the rest of the job without making a horrible mess which you (more likely your client) will come to regret.

Imagine if we took this attitude in civil engineering, or medical science. Not good. Obviously not every web project is as important as those two things, but "the barrier to entry for foot-shooting is low!" should never be a plus point for a technology. Especially when it's not your foot.

There's obviously a need for a tool for low(er) skilled people to make websites, but perhaps it should be less powerful to match? It should at least have abstractions that don't leak so much.

I'm happy to be lectured to about why this is wrong.

I think you may have missed the main point of this article. As an example, I can code to a reasonable standard in Ruby, C and PHP but I mainly work in PHP because if time or budget is low I can speed up development by writing horrible procedural code or other hack-jobs. I'd love to build MVC applications with well-structured architecture all day but many clients just won't pay for backend nicety. From an engineering perspective this is a horrible trade off but from a business point of view it's just what needs to be done sometimes, and I don't believe any other platform offers this.

PHP generally allows developers to just get up and go, both in terms of installing it on a server and building an application, and requires minimal learning. Unfortunately that does mean you end up with a large number of substandard developers, but at least they're getting things done.

EDIT: it's also perfectly possible to clean PHP up using e.g. autoloaders and the builtin interfaces and spl classes, if you want to work cleanly - this capability seems wholly underused outside of frameworks and I hope it gains more attention soon.

You're right, if we took this attitude in civil engineering or medical science then it'd be a problem, but hey, it's not those things, so why waste the time, money and effort that it would need?

You say "obviously not every web project is as important" as civil engineering, but I'd put it the other way "Almost every web project is not anywhere near as important" as civil engineering.

People build Ikea shelving units in their home all the time, without a civil engineer being involved.

Let's torture this analogy some more.

Ikea shelves often break, and thus commonly need replacing every couple of years. This might end up with a higher total cost/kg/year for holding your stuff up in the air, compared to hand building your shelves out of oak or whatever.

Of course, many people move apartments each year anyway, and the old shelves will not fit in their new apartment. So it makes sense to use ikea shelves in this case. Unless of course, the handmade oak shelves were modular and could be easily reconfigured in a way that the pressed-fibre ikea shelves couldn't.

The real problem comes when your ikea shelves fall down, breaking all your stuff. In which case, you were an idiot for putting your important stuff on ikea shelves. In this scenario, you may wish to hunt down and disembowel the interior decorator who told you the ikea shelves would be fine.

So yeah, the right tool for the job. Who'd have thought it? ;)

Personally I won't be giving up my life as a designer of premium bespoke home storage solutions for a job on the checkout at ikea.

God I hate analogies.

I don't think it's so much that it's considered an upside, but rather that it's basically impossible to displace PHP with something better unless the thing you want to replace it with is equally easy, or easier, to implement.

If building websites is like building bridges, you're right.

I think it may be more like communicating. In that sense, English is "better" than Esperanto, even though it's not as well thought out, simply because more people can use it at some level.

Very much agree, particularly as it seems to be the case that "low-skilled people can use it" rather than "low skilled people can use it well."

I'd argue while it's very easy to get started with PHP, it's very hard to build some of good quality with any significant functionality compared to say rails/ django (ignoring framework != language).

Not at all suggesting it's impossible to build good quality apps in PHP but that it's very easy to build bad ones so to build a good one, the programmer already has to be pretty good, making it a poor choice for low skilled people use imo.

Low(er) skilled or people with not a lot of computer language experience as I see it, should be using the language that makes them the most productive, in most cases this is PHP thats the simple truth, I have a programming assignment due in my college data structures in java class, if you really want to see a horrible mess

The question is, are we defining productivity as "the developer can bill and move on as quickly and easily as possible" or is it "the client's business needs are served as well as possible"?

Neither, because if you're using the latter there's only ever one correct way to go about a project, and if you're using the former you get festering piles of shit but hey at least the work got done!

Maybe "low-skilled people" can just stick to Wordpress?

Why is PHP so threatening to so many developers? Don't use it. Don't take jobs where it's the primary tool.

The complaining that it's a poor tool while many people create tons of value with it leads me to believe there's a disconnect between the two camps that I don't get.

Another reason, aside from inherited-mess, is that if you're an independent contractor, promises of cheap PHP projects make it harder to charge for quality work.

>Why is PHP so threatening to so many developers

Because we inherit the horrible mess of shit PHP developers leave behind when the company finally releases they've painted themselves into a corner and can no longer move forward because every time they try to fix a bug in their software they add two more.

>Don't take jobs where it's the primary tool.

It is so widely used that even avoiding jobs where it is the primary tool, you will still almost certainly be stuck dealing with some PHP mess.

"horrible mess of shit PHP developers" has nothing to do with anything. Horrible mess of shit Ruby developers can be just as ugly if not more.

It can be but in my anecdotal experience the mess left by PHP developers is the worst. Especially when it comes to blatant XSS and SQL injection vulnerabilities PHP holds a clear lead.

There is a strong correlation. PHP makes it very difficult to write correct code. An app written in a language that goes out of its way to help you create more bugs is going to have, on average, more bugs than one written in a language that does not.

That "mess" your talking about is called technical debt. Technical debt is a real thing in any language not just PHP. I usually try to take this approach: make that "mess" less of a mess. Even just a little bit less of a mess. If not for your sanity, at least for the next developer behind you.

>Technical debt is a real thing in any language not just PHP

Oranges are a citrus fruit.

Does my argument strike you as being somewhat flawed? Making a true but irrelevant statement is not an argument. PHP is worse than other languages, not equal to them. You create more debt, and it is harder to fix. That is why experienced developers spend the time explaining to beginners that PHP is bad, rather than just ignoring PHP as the original poster wondered.

> ... explaining to beginners that PHP is bad

But what makes it "bad"? Everyone says it, but I don't think I've seen any solid arguments behind it. If it's just because you get a lot of less experienced developers using it (for the reasons mentioned in the article), then I fail to see how that is a flaw at all. If you're 12 years old and trying to get started with web development, then you're probably going to use Apache and PHP to do your first "Hello world".

In the grand scheme of things, there are very few websites that actually require a more robust back-end than PHP. Unless you're pulling in millions of hits, you don't have to worry about the inefficiencies of the language.

>Everyone says it, but I don't think I've seen any solid arguments behind it

You haven't looked very hard then:

http://webonastick.com/php.html http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de... http://www.ukuug.org/events/linux2002/papers/html/php/index.... https://maurus.net/resources/programming-languages/php/

True story: Worst code I've ever inherited in my life was in Python / Django.

It's possible to design and structure something poorly in any language. Conversely, it's possible to write clear and concise individual sections of code in any language as well (assuming knowledge of that language, within reason).

That's why I never put too much stock into python arguments that feature syntax readability prominently. Unfortunately, being a perl guy I've heard quite a lot of those. There are plenty of other language features that could be used to make a point that have less well understood solutions (for perl, those are Perl::Tidy and Perl::Critic).

I don't see PHP as any more easily deployable than Node, Rails or even self-contained Go/Gorilla.

Python, maybe, but even that's trivial to get going. Most of these - save Go - are installed on shared servers anyway.

What this sounds like to me is "I'm most comfortable with PHP, thus it's faster (read: cheaper) for me to create freelance projects in it."

Which might be true; there is a cost associated with learning and thus becoming comfortable in another language. But that's a very different argument than you're making here, Sam.

If someone asked a freelance programmer to make X and you can make it in PHP, Python or Ruby ... the actual cost of development should be relatively even. What you're factoring in is an inherent time cost for your lack of comfort in the other languages.

Come on, I hate php with a passion and even I will admit it's easier to deploy than anything else. Go comes close, but still requires writing a service.

With Python, you need to create a service to run your WSGI server and proxy it from your web server. You also need to handle your static files properly. PHP, you just copy everything in there.

Hell, I have half a mind to create a project that will run Python scripts CGI/PHP style (run this file and send whatever it returns), just to make deployment easier for people. I'm not convinced the convenience is worth the cost of this horrible dirtiness, though.

The problem comes when deploying PHP to someone elses server. Since apache and PHP are usually tightly coupled together and PHP has a concept of global configuration that applies across the whole server.

So you have some PHP app that works fine locally but fails in weird ways on deployment because the server was configured using cPanel by someone who didn't know what they were doing and if you change settings you risk breaking whatever other random php scripts are running on the server. So you end up hacking around with .htaccess files to get things working.

With Django etc you get a to have a "clean room" and run in relative isolation, only interacting with the outside world via proxies.

What PHP is however is cheap to deploy. It's annoying to have to think about and pay for "instances" , "dynos" , "VPS" etc when you just want to put up a webpage with a bit of server side logic.

> Come on, I hate php with a passion and even I will admit it's easier to deploy than anything else

I don't see how this is true anymore. Setting up LAMP versus setting up LAMPython or Node are all one line of aptitude/(your package manager here). I can have a LAMP stack spitting out "hello world" in the same time it takes me to get a Node app running.

Say you're on a shared host. How do you deploy Python in the same time as copying a few files in? You have to copy the files in and do some more things, which is a strict superset of the PHP way to deploy.

there's mod_python, which has never worked in living memory, and there's PyHP which... went into beta in 2008, and hasn't noticeably changed since.

You can't get any easier then FTPing files. And maybe changing a config. That's all you need to do.

Uh, yeah, do that please.

Would this be useful to you? It might be a bit problematic to integrate with servers (as you'd need the server to support that sort of hackery), but, from what I recall, mod_python did support exactly this use case.

Not quite; I'm also factoring in support costs (both to me, and the client), as well as the ability to sell a higher-costing hosting solution to the client.

I'm quite comfortable deploying python projects, and I've done it for a number of clients, but the problems I'm faced with are:

- Sometimes the client comes with hosting for a previous site, and insist that it has to be hosted in the same location

- There isn't much in the way of reliable, cheap hosting where the client will get support for anything other than PHP.

- I am not going to manage a client's server for them. They do not pay me enough to justify waking up in the middle of the night to restart a linode that crashed. I am not in the hosting business (I used to be), and I like it this way.

I will often try to push the client towards managed business hosting, where there's a bit more freedom to move, but even then, it's an uphill battle. PHP is a (the) reality of my line of work.

Right, but you're still confused. In these cases, it's not that PHP is a tool for the project, it's that PHP is a part of the project.

Honestly, shared hosting rarely even handles PHP - I don't know many hosting places that will support the code you write. I can't see going to your host and complaining that your site is down because you wrote a script with an infinite loop that's eating up Apache.

They won't support the code; that's not their job. They will restart the server when it goes down, and handle firewalls/security/keep their servers clean of root kits, etc.

Dreamhost, as an example (seeing as I use them), just upgraded all of their servers to support PHP 5.4, which is much better than any of the other hosts I've found. They're cheap, give relatively good support, and have recent versions of PHP available. If there's a problem with PHP or apache, that isn't broken application code, they'll fix it.

With python or ruby, you're on your own.

So in other words, the application will work just fine the day you sign off assuming the client doesn't update the language core.

Which is no different than with Dreamhost in this scenario. If, for example, PHP 5.X or 6.X ends up breaking your code, it's not like Dreamhost is going to debug it.

There's no functional difference here between PHP and any other language except that the hosting provider will automatically update PHP. And there's no guarantee that won't bork something else (which they will also not support).

No responsible webhost would just roll out a new major version of PHP without warning. Dreamhost have made their servers support it, which means that it is now an option that you can pick, along with PHP 5.2, and 5.3, in multiple modes (cgi, fastcgi, etc.).

But even so, if I build some PHP code that isn't future-proof for even the warranty period that I offer on any code, then I've got to fix it at my cost. If I build some code that, in 3 years time becomes incompatible with a new version of PHP, then it can be fixed then. I can't be expected to predict the future of PHP and build forever-proof code, though.

  > just upgraded all of their servers to support PHP 5.4...

They start supporting the newest version, not upgrade everything to 5.4. They do not force you to upgrade, you decide if you do that.

How often does the language core actually break, though? That's an absolute fringe case.

So what you say is true: they won't support code, but they'll restart the server and handle core updates. That isn't a big enough benefit for someone who detests a language that much.

I still think you're more comfortable with PHP than anything, which is how your valuation is being assembled.

>I don't see PHP as any more easily deployable than Node, Rails or even self-contained Go/Gorilla.

Really? Rolls eyes.

PHP deployment = copy the files to the shared hosting area. Done.

Go even needs building a binary for god's sake!

And people paid Katz nice money to make RoR more easily installable.

That's really less about deploying than it is about setting up the environment.

PHP deployment = copy the files to the shared hosting center. Done.

Node deployment = copy the files to the shared hosting center. Done.

What's missing is the setup. Most shared hosting centers just preinstall a LAMP stack and call it a day.

>What's missing is the setup.

In PHP you only have to do the copy part. The setup is done for you.

>Most shared hosting centers just preinstall a LAMP stack and call it a day.

Which is our point exactly. If and when "most shared hosting centers" also do the same for Node, RoR etc, then we can talk again.

Until them, PHP is vastly easier to deploy for most people.

You might have to do an NPM install, oh lord! Seriously though, I don't understand how that is really any more work.

>Seriously though, I don't understand how that is really any more work.

Obtuse on purpose? For one, what npm install? On most shared hosting services there is no Node environment at all. Heck, in most of them you cannot even install one IF you want it. We're not talking VPS here.

If you read the article, our topic is where the vast masses get to deploy: in shared hosting services. No VPSs, no AWS, no Heroku, no nothing.

If you use a decent web framework for your project, I think PHP isn't a terrible solution. It will be maintainable, organized, thoughtful, and documented. Obviously in the end, it's still PHP, but a good framework makes those more complex PHP applications understandable.

If you're building a website (in any language) without a framework, you're doing it wrong...

If you are using a framework, then you've lost the "advantage" PHP had to begin with: simplicity. Once you are using a framework, everything is just as complex as with rails or django, so why not just use one of those?

And your last statement is terribly ignorant. There's tons of web sites and apps that are better off built without a framework.

I'm sure if you think of any successful web site/app they use some type of framework, even if they made it themselves.

I'm sure you are very wrong. Again, tons of sites a framework is counter-productive, not helpful. Do you think a framework makes sense for a 99% static site that just wants to use include($header) and have an email contact form? Or any of the tons of random admin interfaces people need to write for things that don't fit in to the assumed database backed web app mold?

I'd love to use Python or Go or whatever. But everyone wants to pay me to code PHP on some mediocre stack. So be it ...

At least I home I am free to use whatever I want. So I use Symphony2 ;) ... which adds verbosity and complexity to a language that still can't decide if 0 is something empty or just the number 0.

But this is a different issue altogether.

If someone asks for product X without a language specification, you're probably free to create it in any language you're comfortable (although admittedly it would be stupid for a client to allow this).

PHP is not faster to write, debug and deploy than most other languages. It is faster to write, debug and deploy if you know PHP well and language X not as well.

I guess it goes hand in hand. PHP is good enough for most of the jobs, cheaper/easier to host, and you get cheaper and easier-to-find developers

"a language that still can't decide if 0 is something empty or just the number 0"

Beautiful.

This is what the team behind Discourse is attempting to address somewhat, making Ruby software as idiot-proof to set up as PHP applications.

Whether they will end up succeeding is yet to be seen, but this does definitely seem like an area where competition will benefit the greater good, as displacing PHP with any one of the better designed languages out there would benefit the internet as a whole.

I do wonder though: is the procedural nature of PHP equally responsible for it's adoption by inexperienced developers?

Sure, PHP is cheap and widely available, but you also don't need to understand the concepts behind object orientation to hack together a "dynamic" website with a few includes. And at that point you're just familiar enough with PHP to favor it for future development.

Good luck! But that's going to be hard. LAMP on Windows is as easy as downloading a exe file and running it. LAMR (or what ever you want) will never be that simple. It's the nature of the language. They are completely different.

I'd like to believe maybe one day someone will commit the 6 months to make such a thing happen. But I really doubt it.

I think that's a chicken/egg situation there.

Agreed. As is often brought up in PHP threads, the biggest thing is universal adoption of PHP in web hosting. People learning how to stitch together web pages aren't going to grab a VPS, learn the complexity of managing the server, and use something complex like Rails (where there's a language, a framework, and MVC to learn).

With PHP --> the newbie just has to FTP the files up and it works. Fewer variables to manage, fewer things to learn. You go from 0 to 60 much faster. Now, you probably will go from 60 to 100 much much slower than with a different stack, but that's a different discussion...

I agree, and I think that means it will be very difficult for any language that requires more understanding of OOP concepts to get started with will have a hard time competing with PHP in this arena.

My opinion on the success of PHP has more to do with how it integrates with Apache... All of the other languages were designed as languages first, then web development was bolted on... HTTP is fundamentally request / response oriented and PHP provides brain dead access to GET and POST vars via simple to understand global variables... In addition, the same mechanism is provided for session state...

I would note that the article doesn't consider having to install any custom PEAR/PECL packages that your PHP application might require. Sometimes they need to be installed on the command line (as root), or sometimes as OS packages. If you're using managed web hosting, you will probably need to email the administrators and ask them to install the needed packages, and they might refuse.

In this context Ruby on Rails wins because of its standardized Gemfile approach. Every RoR application always specifies the dependencies in a standard way and their installation is always part of the deployment process. PHP has nothing like this.

The same applies to asset pipelines. When your application contains SASS/SCSS or CoffeeScript files, you need to worry about how they're going to be compiled, optimized and deployed. Ruby on Rails also standardizes this so that all you need is the same basic RoR application layout that you generated in the beginning.

So, as long as the web hosting provider supports Ruby on Rails, I think it's currently the simplest way to deploy full-featured web applications. Using PHP will require you to either 1) not use many modern web technologies or 2) build your own deployment processes to support them.

Composer (getcomposer.org) and Packagist (packagist.org) are largely a popular replacement for PEAR, though once you need a C extension (PECL), you're right, it does become a pain.

While I agree with you, I don't think PEAR/PECL a good exemple. Even with a good Gemfile if the libxml2-dev is not installed you will not be able to bundle your Rails app which use Nokogiri.

Where the argument of PHP run on any cheap shared hosting fail for me is more about the php.ini config. You can't rely only on the PHP version to know if your app will run.

You really shouldn't be deploying SASS/SCSS/CS/what ever. You should be compiling that locally and deploying JS/CSS.

This cuts both ways. My RoR apps use gems that require other non-ruby libraries to be installed.

"the only language that makes deploying a website effectively idiot-proof"

I work for a large web host and can assure you this is not the case.

I've worked for a reasonably sized (business) host myself, and yes - anything that's idiot proof is just waiting for a bigger idiot, but PHP is far easier to deploy for a non-programmer than anything else.

Have you compared to idiots installing RoR and Java apps on same host?

If not, then you're not assuring him at all.

Exactly. I detest PHP, but I've used it to quickly build a sign-up website for an event. If you pair PHP with an interface library like Bootstrap and an ORM like Paris/Idiorm you can have something up and running cheaply and quickly. Is it maintainable? No, but that's not important in this case.

edit: let me clarify, I don't assert that ALL php code is unmaintainable, just the quick site I built. Though if you're in the mood to argue: statically typed languages are infinitely more maintainable than dynamically typed ones in my opinion.

"Is it maintainable? No"

Anyone who has worked with codebases in multiple languages for any length of time realizes that's a wrong statement. Maintainable is, to some degree, in the eye of the beholder (and often author), but you can write unmaintainable code in any platform. Everyone seems to love RoR - I inherited a Rails 1 app written over 18 months that still didn't work right, and was essentially unupgradeable - every piece of advice from every Ruby person I talked to was "just start over in Rails 2 and port some of the old logic over".

OK - so now I'm talking 'upgradeable' vs 'maintainable'. Try to 'maintain' a Rails 1 app in 2011 - simply searching for how to do certain things in Rails 1 is pretty hard to do, because the docs are wrong/outdated or simply gone.

But hey - "Ruby is maintainable, PHP sucks", right?

Give me a well-thought out Zend Framework app written by a senior developer with experience writing good code vs Rails hacked together by someone with 2 weeks of udemy lessons under their belt any day.

> Is it maintainable? No

I think that's an exaggeration. Also, I have something to say about JIT.

"I don't assert that ALL php code is unmaintainable, just the quick site I built. "

Sounds like you're the problem here.

Simply not true.

Have you ever tried to install and setup PHP on a fresh server? It's almost as painful as writing code in PHP.

The article is talking about managed hosting, were that might still be true (Admins are incredibly conservative and stubborn individuals).

But for everything else? PHP doesn't work 'out of the box'. It's due to the work of a poor admin somewhere that you can just upload your crap and it runs.

In contrast, I can install and setup a complete Ruby server in about 15 minutes.

apt-get install apache apt-get install mod-php5 apt-get install php5-pdo-mysql

whatever the packages are - there's about 4-5 core packages (yum/apt/whatever) or other packages like xampp that set up a default environment in about 5 minutes on most modern systems.

There's certainly a lot of configuration that can be done, but getting a LAMP system set up to allow PHP/MySQL to work is trivial these days compared to 2000.

Cue the puppet and chef supporters who would suggest scripted recipes for everything anyway. :)

Really?

apt-get install nginx php5 php5-fpm php-pear php5-common php5-mcrypt php5-cli php5-gd

Takes about 2 minutes.

If you want to pretend that is all that is involved, then your argument suggests web development with haskell is just as easy to setup as with PHP:

    $ pkg_add snap

Well, that was easy.

It could not be any easier to get a LAMP stack up and running on a fresh server.

$ apt-get install lamp-server

I think you may need the caret at the end if you are using apt-get rather than tasksel directly:

$ apt-get install lamp-server^

And since most people in this world use managed hosting for their website projects thats the right thing to compare with.

Also you have MAMP which is as easy as it comes for setting up a PHP/mysql environment on your computer.

But the strength of PHP goes far beyond this simple point.

For developers it's very very simple to get started. The difference between writing a hello world app and a crm app isn't that big. Weaving HTML and PHP together with JavaScript, CSS, JS easy to learn with PHP.

I wouldn't even know where to start in Ruby or Python. Just too many dependencies before you can even get started.

So yes it's by any metrics it matter true.

Take it from someone who had to teach himself how to do it and have tried to get started with several languages.

Is it really that difficult? The last time I had to install LAMP stack was on Ubuntu and it was something like:

$ sudo tasksel install lamp-server

He could be implying shared hosting is the most common method of hosting. In these cases, they all tend to come pre-configured with a LAMP environment. No setup necessary for CLI scripts.

From scratch, everything is easy to install. I wouldn't say Ruby is any easier to install and setup than PHP. You're talking about installing something like Phusion Passenger on top of Apache. A LAMP stack takes as long as it takes to run `apt-get` or `yum install`. By no means is it 15 minutes; I'd say 5 to 10 with minor Apache configuration and a VirtualHost entry.

>He could be implying shared hosting is the most common method of hosting.

He's not only implying it, he states it explicitly. No need to guess, the article is there.

>Simply not true. Have you ever tried to install and setup PHP on a fresh server? It's almost as painful as writing code in PHP.

Which is so totally beside the point he makes, that I'm pretty sure you didn't RTFA.

The "market" he describes is NOT installing PHP from fresh on servers.

PHP "out of the box" is very easy, sudo apt-get install php5 mysql-server apache2.

apt-get install libapache2-mod-php5, edit create/edit your vhost file, upload PHP files to wherever you pointed the vhost file, reload apache?

But that work is reused.

The one technology that's nearly as ubiquitous on shared hosts as PHP is CGI. Plain, one-shot process-per-request CGI.

So if we want a language that can displace PHP in its niche, perhaps we should choose a language that's amenable to short-lived CGI processes. For this, I think a language that can be compiled ahead-of-time to fast-starting native code is appropriate. By fast-starting, I mean that startup should consist of little more than the kernel's exec routine.

I think the Go language would be a good fit.

So the next time you need to write a web app that should be easy to deploy on a shared host, try writing it in Go, using a web framework that supports FastCGI, which can then degrade to plain CGI. Then compile the app on a Linux box, upload it to the shared host, and thanks to the self-contained nature of executables produced by the Go toolchain, the app should be ready to go with no fuss.

Except that my web host runs freebsd.

When people complain about McDonalds being horrible food, not fit for human consumption, they will often talk about the health benefits of their favorite foods. And you know what? They're right.

But McDonald's is still better food.

Imagine a programmer from a top software company writing long-winded rants about how horrible PHP is; how PHP should cease to exist. Everyone would roll their eyes, and say "Well that's the bloody point of PHP, you idiot!"

McDonald's caters to poor people, especially those who don't have their own cooking skills. This is the challenge for all the people who want to complain about McDonalds - if your chosen food is so much better, then make it accessible in the way that McDonald's is.

"The easy path is often not the best path." -Me

"best" is a very subjective term. PHP is not the best language for making in-house web app stacks like many people on HN build, but it is the best language to deploy a basic marketing web page for the chip shop down the road. That's the point I believe this article is trying to make, and basically just boils down to "the right tool for the right job".

I guess that if "can be deployed my a non-technical user through FTP" weighs heavier than all other technical considerations put together, then I guess PHP is the right choice. Or you could just CGI.

Try dropping files in an environment where apache / php is not installed, or where db drivers or gd bindings are missing. Or try to set it up with nginx and php5-fpm.

There is a big difference in being ubiquitious and being easy to use, and lets not infer casuality where there is none. Most popular PHP projects come with a good installer, but go to sourceforge and try a lesser known project. Or go back to the 90s and see if installing drupal or wordpress was as easy.

I can argue that shell scripting is the best programming language by this logic.

I disagree. Deploying a Python site, for example, is equally easy.

So, you're saying that you can buy cheap shared hosting with a Python server set up, where you only need to upload the files via FTP and it will just work?

Deploying with FTP is harder than deploying with git.

Maybe, but even so, learning to use FTP is a heck of a lot easier than learning to use git.

Don't deploy with git. Have a build process which isolates your VCS from your deployed code. fab/Makefile/etc. make this easy.

Deploying a PHP site can be done with the use of one or two apt-get commands. In Python I'd need to do that plus write WSGI-related stuff in a script, alter the Apache configuration, etc. Check out the instructions for Flask or Django if you don't know what I mean.

So you're saying you can FTP a full featured CMS to commodity hosting and it just works?

Its sad no other languages have noticed this. PHP is a natural progression from HTML for beginners. Learn HTML, sprinkle a bit of inline PHP here and there, and bam you have a "dynamic" website.

An incredibly bad and impossible to maintain website, but a "dynamic" website none the less.

From there, ramping learning up to MVC / Frameworks / caching / templates / optimizers is all small leaps from the initial understanding of "put html here, sprinkle php here". Nothing else really has this apart from maybe ASP.

> It works, out of the box, for people who don't know what they're doing

here's the worst of all the bad reasons right here..

Absolutely nothing bad about it.

It's called empowering people.

Because only experts should be allowed to write code and try to build things? I'm sure you were writing shitty broken apps before at one point in your life, just to learn by experience and get better.

How cheap does the shared hosting need to be? DigitalOcean offers virtual machines starting at $5/month. At a somewhat higher level of abstraction, WebFaction offers shared hosting for $9.50/month with a broad selection of technology stacks.

When doing freelance jobs, I've rarely had the chance to choose the hosting provider for the client as they in most cases already have a web site which they need to extend with certain functionality (web shop, blog, etc). Convincing them to switch hosting provider without obvious (to them) benefits is pretty pointless. Of course, your point still stands if the job entails creating a platform from scratch.

Only way to "idiot proof" anything is to not let idiots build your software. Regardless of the tools, idiots will create a mess.

Reply on news.ycombinator.com