Hacker News Reader

Comment by mgkimsal | Hacker News Reader

"Jeff Atwood has stated publicly that one of his ulterior motives with the Discourse project is get people to stop using PHP and start using Ruby."

This just won't ever happen. The people that wanted to drop PHP for something else (Ruby, etc) largely did so years ago. The hosting/running situation for PHP is just too basic and easy for people to get in to vs having to 'run a server' (Rails, etc).

PHP is still the only language that assumes HTML output by default. Put a file on a web server, hit it via a URL, and get HTML output. It's that simple. You can start at 'simple' then graduate up to complex stuff like Symfony if/when you want to. Every other language or platform forces a lot of extraneous concepts on you on day one, which is always going to be a turn-off for a not-insignificant portion of the people coming in to the field.

View on HN

Exactly. I am still using PHP for pretty much all of my projects despite all of its shortcomings. The reason for this is just how easy it is to write simple scripts and deploy them. For most small hobby projects it is just not worth spending hours setting up the development environment required to create a Ruby/Flask/... project when you can achieve the same thing with a single PHP file. And when it comes to deploy it, virtually every single managed web hoster out there supports PHP, so you just upload the file and it works.

I did play around a bit with Flask a while ago and it does feel a lot cleaner and more efficient. But once you actually try to deploy your app you realize that hardly any web hoster actually supports the required Apache extensions and suddenly you end up having to set up your own server and fiddle with config files to get it to work.

After you do it once you realize its not that hard to deploy. Nginx -> Gunicorn -> your app

It is even easier if you use Phusion Passenger, either in combination with Nginx or with Apache. It is almost as easy as PHP. Put your Ruby app somewhere, set your document root to it, done. Nowadays, Phusion Passenger even supports Django and Node.js.

What faint praise this is. "Not that hard". :)

I've deployed a number of small PHP-based websites in a similar way for similar reasons over the years. However, I think the next "simple" project like that that I need to do will be statically rendered from frozen-flask and hosted on S3, with any small interactivity provided on the client, with JavaScript.

> PHP is still the only language that assumes HTML output by default.

For me, that's not a feature, it's an oddity that I have to work around. I guess it's a feature if you're using PHP as the HTML template language it was designed to be, but I suspect that's a minority use case these days.

But that's what it was designed for..

> For me, that's not a feature, it's an oddity that I have to work around.

Well, I would venture a guess that you should have looked up the language's name and its meaning, then the entire focus of PHP might not come as much of a surprise.

"Personal Home Page"?

> Zeev Suraski and Andi Gutmans rewrote the parser in 1997 and formed the base of PHP 3, changing the language's name to the recursive acronym PHP: Hypertext Preprocessor.

http://en.wikipedia.org/wiki/Php#History

Yes, to get back to my point, it is basically a templating language for HTML, hence the hypertext. I think the name made it clear being ambitious with it outside of HTML was going to be difficult, unless you like the challenge of making cars into airplanes, and submarines in to hang-gliders.

How is the default header of `Content-Type: text/html` Any different form a default header of `Content-Type: text/plain`?

It takes you about 3-4 seconds to change it for your entire project.

That's not what I mean, and I don't think it's what the person I replied to meant either. I assume text/html is the default content type for all web frameworks.

I was referring to the fact that the first thing pretty much all PHP apps do is say "Wait! Don't output anything yet! I have code to run!". I believe modern PHP frameworks generally borrow the controller/template pattern from other languages, because it generally makes more sense than PHP's default of outputting HTML unless told otherwise.

I would actually argue that using PHP as the templating language in a PHP MVC application has become the majority use case.

Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself?

There are cases where you may need to do this (if you can't "trust" the templates for example and you need to enforce some kind of validations or restrictions on them) but otherwise you just need to follow/enforce business rules about what can go in your views, and just use plain ol' PHP..

I actually agree with you. It's been a while since I used PHP much, but the last time I did some work in, erm, I think it was Symfony, I remember thinking that PHP was pretty nice for the template layer. That may partly be because I'd got used to Django, which had an aggressively simplistic template layer at the time.

Edit: By which I mean, Symfony improves things by working around PHP's suboptimal default.

> Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself?

From past experience: to stop shittier developers at your company putting controller logic in the templates. Using something that does nothing but templating ensures that your templates do nothing but present data.

I addressed that in my post actually. If you have shitty developers in your company who can't follow business rules, PHP isn't your problem.

With templating systems which 'compile' templates down to php anyway, that might be a distinction without a difference.

Fair enough. I know Smarty does this and caches the PHP-ized version.

I guess the difference could come from how efficient the template-to-PHP compilation is, but I bet you're right and it's trivial in most cases.

Twig too, and you can sandbox functions and auto-escape data. To me, using templates is more or less the same as using a framework with PHP -- it does add overhead and you could get by with, say, plain PHP and having urls point directly to resources but sometimes I think the benefits of that extra abstraction, even if it is a bit recursive, outweigh the potential costs of not having logical buffers between a request and its execution. An app that's too dumb can come back to bite you just as hard as one that's too clever by half.

Blade (used by Laravel) seems to be more along the lines of "bare PHP/bind to PDO object" but I haven't studied it too hard because i'm such a twig fanboy.

Relevant reference wrt this thread: http://www.phptherightway.com/

I think node can beat out php in regards of ease of hosting. I've simply never worked with a version or package manager that works as well as nvm and npm. Trying to do the same thing with Ruby or Python is like pulling teeth. Even compared to PHP it's a breeze. I know it isn't on all hosting solutions like PHP, but Heroku and Nodejitsu are free for small or open source projects respectively.

But you're right, PHP assuming HTML output by default is a huge boon. With node you have to set up your own server and routes, and more... That's a lot more work than installing WAMP, running it, and putting your php files in the right folder.

I use PHP because it is absolutely everywhere. If you're supporting shared hosting environments ... it is the JavaScript of the backend.

I opened the comments section to make a similar post. From the OP:

> The days when programmers opened up a blank file, named it index.php, and said, "time to start coding!" are over.

That is actually the only thing better about php than... well, pretty much any other option.

As for the rest of it... "lipstick on a pig"

I prefer rails specifically because the "hosting/running situation" for Rails is so FAR superior to that of PHP.

$ git push heroku master

...done.

you know you can do the same with php, right? $ git push fortrabbit master ...done

Not really. That only works with one host, whereas PHP works with just about any 5 dollar/month host in the world.

For loose definitions of 'works'

No. It works as well in one place as in any other.

I don't really want to stand up for php, but this just isn't true.

"git push heroku master" comes at a steep price. PHP hosting is, in general, ubiquitous, cheap, and incredibly easy. You can get comparable pricing for ruby hosting, but you'll be doing some server setup yourself.

> You can get comparable pricing for ruby hosting

Might I ask where?

eg:

https://www.digitalocean.com/pricing

"git push heroku master" comes at a steep price.

Um... what? 1 dyno is free on heroku. You host it for nothing. Am I missing something?

Yes, that 1 dyno is not enough, and there are tons of other limitations (db use, etc).

yeah you're missing something, unless you're just running something low priority like a personal blog:

Although an app may not require the resources of more than a single dyno, we recommend running at least 2 dynos for a production app. One reason for this is that dynos restart roughly every 24 hours, and dyno redundancy helps ensure that you don't experience excessive queueing or dropped requests while a single dyno restarts. Additionally, dynos and the processes running on them can occasionally crash, and having another dyno helps ensure that you don't have downtime while that dyno recovers. Finally, single web dynos sleep after an hour of inactivity, and having a second dyno means that all dynos will stay awake.[1]

[1] https://blog.heroku.com/archives/2013/4/26/introducing_produ...

Not to be overly pedantic, but Heroku does also support PHP.[1]

[1] https://github.com/heroku/heroku-buildpack-php

"his ulterior motives with the Discourse project is get people to stop using PHP"

Their is money in syntax now.

Reply on news.ycombinator.com