Laravel isn't going away, even if Taylor gets hit by a bus.

There's a huge and active Laravel community, it's just that Taylor is the benevolent dictator.

If Taylor was hit by a bus, there would be plenty of others who would be willing and capable to take up the baton.

Seems to me pretty remarkable to rule out Laravel on this basis, yet keep CakePHP, ignoring all its other flaws.

Excellent input, thank you!

fwiw http://www.google.com/trends/explore#q=Laravel%2C%20symfony%...

Updated to include Symfony2:

http://www.google.com/trends/explore#q=Laravel%2C%20symfony%...

Ive been watching a few of the Laracasts episodes this week to get a feel for Laravel. https://laracasts.com/

I am really off the PHP train now, but I'd also recommend to have a close look at http://www.phalconphp.com/en/ .

Their approach is to have the whole framework compiled as an extension. Seems well documented.

Personally, after years of dealing with PHP and the regularly occurring panic when inevitably something is going wrong during deployment, I'd consider PHP's dependency on other moving parts a bit of a nono. There's just too many pain points around deployment, versioning, server conf, extensions that are compiled in etc. Admittedly this has gotten much much better since the advent of composer and tools like chef, vagrant etc, but that's another whole learning curve right there. Compare that to go, where you just compile your binary, scp that up and then launch it. Done!

To add to that: I also think that these days you will need to have some sort of JS framework on top of your server stack. Angular and Ember are bot nice to work with, React would be something I'd look into next time.

In this context (Restful JSON or XML from the server, JS client consuming it) Go again makes a great choice, as it's coming with great JSON and XML capabilities that make it easy to marshal/unmarshal into GO types.

I suppose a third option would be Composer and picking only the modules you need.