It was the single most requested feature on the bug tracker by quite a bit.
It's not something I want, but apparently there are quite a few people who do.
It's not something I want, but apparently there are quite a few people who do.
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!
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.
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.
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.
Is there a MySQL-like solution on GAE as well?
Also what people request and what google's vision is are two different things. Who are they targeting with this PHP stuff. Yes sure, for free-tier stuff, I'm sure lots of kids playing around with PHP would love to have a sand-box to play around. But this move seems inconsistent with their prior action that signaled a move toward enterprise sales.
Also, it feels like one side of google is not talking with the other side. They're building a whole application scripting system hosted on google Drive to work with google apps, etc. Why not provide the javascript on GAE to allow further application development and integration.
To be honest, this feels like: Oh shit! Google I/O is coming up and we need to have something to show than a vision of providing cloud-based computing solution that fits within their big vision.
Google's vision is "developers deploying scalable apps on App Engine". Being developer-friendly is good for that.
> Who are they targeting with this PHP stuff.
Existing PHP devs. Which is a lot of devs.
> Yes sure, for free-tier stuff, I'm sure lots of kids playing around with PHP would love to have a sand-box to play around.
Lots of apps that end up making money use PHP.
> But this move seems inconsistent with their prior action that signaled a move toward enterprise sales.
Enterprise is an area that Google would like to get their Cloud Platform, including App Engine, more sales in, but its never been anywhere close to their sole target for it.
> They're building a whole application scripting system hosted on google Drive to work with google apps, etc.
"Building"? Apps Script has been around a long time (longer than Drive itself; maybe longer than App Engine.)
> Why not provide the javascript on GAE to allow further application development and integration.
Javascript on GAE would make a lot of sense, too (especially in light of App Script and Google's work on V8 and the emerging popularity of Node.) So would Dart-on-GAE. I wouldn't be surprised if either (or both) of those happened. But the fact that it makes sense doesn't make PHP make any less sense.
> To be honest, this feels like: Oh shit! Google I/O is coming up and we need to have something to show
App Engine PHP wasn't even the big Cloud Platform announcement tied to I/O; general availability of the Compute Engine IaaS (and the associated new pricing and instance types for Clound Engine) was the big Cloud Platform news.
> than a vision of providing cloud-based computing solution that fits within their big vision.
Google's big vision for cloud-based computing is, well, big. It includes more than one kind of solution, for more than one market segment.
Your attitude is ridiculously arrogant.
PHP powers most non-corporate website on the web. The wast majority of wikis, blogs and forums. You know, things that are used for actual communication and knowledge sharing by millions of people.