Thanks, I'll look at it ;)

The linked talk and the video seems pretty interesting, do you know of similar content in english? My Spanish is very bad ;)

Small addition: Guzzle and a few others install almost exclusively PHP files and are not extensions (therefore not compiled). The advantage is, that these libraries are then available system wide, not only per project. On my ubuntu they are installed in /usr/share/php , which is in the include path. However this can introduce issues with different versions of dependencies. You can see what is installed by using dpkg --listfiles php-symfony-eventdispatcher for the php-symfony-eventdispatcher package (dpkg works on debian/ubuntu).

Disclaimer: I was not a developer at that time, so my knowledge might not be very accurate. Correct me if I'm wrong. This is a fair question, considering today's practices. The name is, as often times, carried on for backwards compatibility I think. From what I read ( https://en.wikipedia.org/wiki/XMLHttpRequest#History ) XMLHttpRequest's API was at first more of a special purpose solution, which seemed to make sense to have in the browser as well. Considering browser wars, from back in the days, other vendors probably ported the APIs to make "modern" websites work on their browsers as well, not just in Internet Explorer. XML is a superset or general form of HTML/XHTML (Incorrect, see comments), and was the go to format for plain text data transfers (considering SOAP web services). Due to it's similarities to HTML it was fine to use it in browsers, as the parsing technology was already present. XML only recently (okay, some years ago) mostly got ditched for JSON due to XML's verbosity and weak performance when parsing. Furthermore JSON was pretty new at the time XHR was introduced. And the initiative to standardize it had just started ( https://en.wikipedia.org/wiki/JSON#History ). Major players started using the format about 5 five years after XMLHttpRequest was introduced. So using XML for data transfer totally made sense. The object was dubbed because of that, and nobody wanted to break the web. We might see a similar development, when Protocol Buffers, or anything similar will be standardized and in wide use.

Interesting piece, thanks for sharing. This is like a top-to-bottom approach for "beginners", where you start getting something done and follow best practices, instead of understanding every single piece of your toolchain. You can look into the pieces afterwards, in case you want to. But nonetheless, in web development there comes a time, when you need to understand a good percentage of your tools/libs to really understand what you're doing, in case you need to squeeze out some performance. So the simple way is not going to cut in all the time. And this is really where the fast paced JS library/framework world is tiring out the average developer.

This is interesting. At first I was confused, whether this is a desktop or web GUI. As far as I understood, it's a UI render loop for your browser, which publishes UI changes via a websocket connection. Unfortunately I found it hard to debug the socket connection, but that might change. What do you think might be a use case for this?

Google Trends is tricky. I got different numbers, when I used Symfony with the "Software" context (term might be different in your locale). I also threw Zend into the mix, but I see it's on a decline since some years. http://imgur.com/wFwDnMG (sorry for the german)

Hard to say from here, you could add the table structure

Invalid argument supplied for foreach() is the typical error message when you provide a foreach loop with something other than an array, or Traversable instance/implementation. For example null or a boolean. The docs help: PDO::query() returns a PDOStatement object, or FALSE on failure. ( http://php.net/manual/pdo.query.php ) You should use PDO::errorInfo() to get some more hints (Docs: http://php.net/manual/pdo.errorinfo.php ), for your code: $pdo->errorInfo(); This sounds weird actually, since this should not be a question of data. Maybe it's a matter of permissions. I first thought maybe terminal is a reserved word, but couldn't find any evidence. Otherwise, you might be better of if you set your PDO error mode to exception. Then you get an exception whenever something goes wrong. The default is silent (more info here http://php.net/manual/pdo.error-handling.php ) $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); This is probably more handy in development, than in production.

Eventually you would not need to instantiate the factory. Factory.load() should suffice. Angular instantiates on it's behalf when using DI.