Hacker News Reader

Comment by cramsdale | Hacker News Reader

Our goal is to advance computing (via services such as HRD, Cloud Datastore, BigQuery, and Go) in ways that align with existing developer practices (investments in Java and now the release of PHP). There's no point in releasing amazing solutions if there is a huge barrier to entry.

View on HN

Which customers are you going after? People who want to play around with "hello worlds" with PHP or people who actually build powerful stuff.

Either case, help me understand why PHP was a better choice vs. Javascript? If the question is barrier to entry. Then javascript should have the lowest. Anyone doing any web development needs to do something in HTML/Javascript/CSS.

Additionally you could have made the case for further integration with your other services like App Scripts. Aren't google team talk to each other?

I personally would have rather seen Google focus on Go and remove "experimental" out of Go so people feel some amount of security developing and investing time building Go applications on GAE. Just my $.02!

I'm assuming that you're actually talking about Node and not just HTML + JS. Ultimately it wasn't a choice to do one and not the other, it was a choice of which to tackle first (and PHP had some technical advantages which allowed us to move faster). Ultimately we want to surface, or allow others to surface, any runtime in a fully managed way. Yes, Node, Ruby, C# are often discussed (as are many others, including moving Go to GA). We're investing, we'll get there, and this is only the first of many steps.

I don't necessarily mean Node, but serverside javascript. I don't really care for the event notification process of Node. It has its place and for many tasks it probably is the best solution. However for most web apps its probably simpler not to worry about it.

Yes, PHP is only used for amateur useless projects like Facebook, Wikipedia, Drupal, WordPress ... Our projects on the other hand are too important for this low brow language.

All the stuff you are talking about are valid examples, but they are from 5-10 years ago. None of these probably will be built on PHP again. I can use the same reasoning and list some major critical applications and argue for Cobol, Fortan, etc. But it doesn't mean it's forward thinking.

We get requests for PHP all the time. In Urs' presentation today, the audience response at I/O was the strongest for three things specifically - open signups for GCE, sub-hour GCE billing, and GAE support for PHP.

Slamming PHP is akin to slamming the x86 instruction set. It's besides the point. There are so many large "apps" that effectively use PHP as asm; we need to have a solution for customers that want to run open source CMS:es and CRM:s, for example, and this is all Wordpress, Drupal, SugarCRM, MediaWiki, Joomla etc.

And there are a LOT of startup companies building in PHP, believe it or not. PHP on the server is akin to Javascript on the client. You can argue that Erlang or Go is better, fine, but the reality is that most web sites are PHP. And similar to what happened with V8, there is a significant industry effort in just accepting this and making PHP run faster and better. We don't want you to compare GAE/PHP with GAE/language_X. You should compare GAE/PHP with [other platform]/PHP, and see if you like what we've done. And we're doing some cool stuff with it. We are working to support PHP code better than any alternative. We expect PHP developers to love it. But we're not doing it in order to advocate (or not advocate) PHP per se. You don't like PHP? Then move along, there's nothing to see here.

And as for the "small $5-6 dollar sites" (or free), that doesn't matter. Many of the apps running on GAE are within the free tier, which is one of the great things about the platform. So that's not news. Part of the GAE vision has always been to offer a place on the web to run small web apps for free.

Excellent points.

Is there a MySQL-like solution on GAE as well?

While PHP has low barrier to entry and there are a lot of people who tinker with it, PHP still powers a lot of production websites, far and beyond the hello world apps or the 'pictures of my dog' wordpress blogs. Your implication that there aren't "powerful stuff" websites running on PHP is just simply not true.

You can host HTML, javascript and CSS files to be run in the browser on GAE already, and have been able to do so since day 1.

What you can't do is run javascript server side. Given the unique requirements of server side javascript, and the fact that the single dominant implementation is maintained by a competitor in this exact space, it isn't a great fit.

> Given the unique requirements of server side javascript, and the fact that the single dominant implementation is maintained by a competitor in this exact space, it isn't a great fit.

Google already has a cloud based, server-side, javascript platform in Apps Script, and has purchased at least one company that operated a JavaScript PaaS, so its not like doing JavaScript serverside is out of Google's reach if they strategically wanted to do it.

I can see why, given the mass of PHP apps out there, PHP might be a priority for App Engine given what App Engine already supports, but I can't see JavaScript as having a significant barrier to practicality.

Serverside. Not static client side files.

Reply on news.ycombinator.com