PHP is a turing complete language, and MySQL is a relational DB, so between the two there is very little you can't accomplish, unless you want to start doing full text search against millions of records in a database - at which point you need to augment the stack with something like ElasticSearch, or switch from MySQL to Postgres. If it's a traditional request/response site, or a simple API to power a rich client-side app or mobile app, yes, absolutely . In fact, I wouldn't choose any other language for this since PHP gives you great architectural design features like object type safety, but without the need to for a manual compile step. So you get similar benefits of Java or C#, but with the instant interpreted language feedback of Ruby and Python. And because of the stateless nature of PHP, you don't have to restart a server like you do in Python. Have an error? Correct it and refresh the page. Done (unless you switch over to a looped process with PHP PM, but that's not standard PHP). However, if it's a real-time app with live growl/push notifications, chat, and all sorts of other things, then no - you cannot really do this with your requirement of plain PHP + MySQL alone. PHP must be either made to run in a loop with a runtime like PHP PM or react PHP, or you must augment the stack with Node + Socket.io + Redis.

I started off writing PHP like a typical newbie programmer: procedural -> "OOP" (in quotes because I was just putting random classes together without any sort of concept of what OOP really was), and eventually more sensible OOP. The more I learned and applied OO designs, the more I began relying on PHP's object type hints and interfaces to make it easier to reason about my code while also keeping it loosely coupled. Later on a switched to UI engineering via JavaScript because that's where the jobs were, and I deeply miss even PHP's relatively loose typing, but typing nonetheless. It's a free-for-all of object literals, and while JS can be quite terse and elegant, you lose much of that terseness by writing unit tests or null checks to cover scenarios that PHP type hinting covers for you at the language level. And square peg / round hole bugs absolutely do manifest themselves in JS because of this. More regressions happen, the meaning and intent of unit tests gets lost in all of the additional safety checks you need to write etc. Plus I've found PHP code to be FAR easier to reason about because of all of the type hints in function arguments. You KNOW what's expected of an argument because it flat out tells you.

I've run a gaming community with a general "Mess hall" forum for ~12-14 years now, and Engadget is making the same mistake I did a few times: expecting too much from their discussions. From the article: because so many of the replies are hateful That's a matter of moderator opinion. I've seen overly sensitive moderators consider any strong opinion "hateful" merely because they disagree with it, or because it has the word "hate" in it. I hate politicians that try and push for backdoors into encryption, but it's really childish if a moderator would want to censor such an opinion. Articles that mention Apple deteriorate into arguments of iOS vs Android So what? Again, it's moderator opinion that such debates don't add value. Nested comments help isolate these debates to as single thread. replete with grade-school name calling So what? At the end of the day, Engadget has failed to understand that comments are a form of content in and of themselves, and a draw for traffic in and of themselves (like on Reddit and HN). Sometimes they add meaningful points and counter points, sometimes they're hilarious, sometimes they carry strong opinion, sometimes they carry questionable logic, and sometimes they're flat out mean or stupid. That's how things go. You simply accept the bad that comes with the good, try not to play God when it comes to deciding which comments are valuable and which aren't, and moderate the really bad stuff. Where you run into problems is when you get YouTube quality comments - the kind where spelling, grammar, punctuation, and any semblance of structure or intelligence is absent.

Pagination all the way. I can't tell you the number of times I've seen an image or something, and want to get back to it shortly after closing a window or something, and have to scroll, and scroll, and scroll, and scroll. Let me quickly get back to the page I found the content on. Infinite scrolling still is pagination, but a less-useful form of it IMO. A hybrid approach would be ideal. Pagination that updates as you scroll.

If you want true realtime in PHP, you need an event loop version of PHP like ReactPHP. Else you must have Node.js and socket.io running in tandem, in which case those will be doing the heavy lifting of the realtime part of the app (which isn't a bad thing). At the end of the day, all laravel event broadcasting is doing is making an event available in a cache store like Redis. It's still up to a separate technology (again, like Node) to read from and push that data through a web socket to the browser.

A focus on JavaScript, not TypeScript. TS focus/priority is a barrier to entry in Angular 2, and it manifests in two ways. The documentation and examples are largely TS-biased. The architecture of Angular 2 seems to be more complex than it has to be, but it uses TS features to alleviate and justify some of that complexity. E.g things that are difficult or verbose to configure or declare in JS are more terse and straight-forward in TS, so a JS-friendly architecture is a second-class citizen. In short, you need to know TS to use A2 effectively, and people who are happy with JS, or who are just barely wrapping their head around JS, don't want to learn what is effectively a different language. And not just a new syntax, but also the idioms and patterns that go along with that language - new patterns that you can see Angular 2 using a lot - patterns and idioms largely unfamiliar even to an experienced JS dev. The analogy is this: You want a new car, but to drive it, you need to relearn how to drive, rather than taking your existing driving experience and applying it to the new car. Maybe the new car isn't worth that hassle to some...

This was really a very useful presentation, but I would like to make a plea to the world: please stop using whatever this library/thing is used to format these presentations. I see it everywhere and it's HORRIBLE. The rotating animation totally breaks my train of thought, especially when trying to step through the execution of code like this presentation does. Also, sometimes it lets you navigate up and down through a slide, which makes it extremely easy to get lost. At least your presentation doesn't do it, but I've seen others that do. If you navigate down, it lets you navigate left/right, which makes it immediately unclear as to whether navigating left/right is the next main slide, or just another sub-slide of the sub-slide you're viewing. It's like a maze, and awful user experience :/ I seriously loathe whoever built this silly presentation library, because it ruins otherwise good presentations. /rant

Either. Both languages can accomplish the same thing. The choice really comes down to the framework , not the language: Rails or Laravel/Syfmony/Yii/Cake. But even then a social network is still easily implemented in Rails or any PHP framework, so at that point it comes down to a matter of preference. Try Ruby/Rails, and try PHP/Laravel (Laravel is by far the easiest, most intuitive full-featured framework in PHP), and see what you like. From a pure technical point of view, there are no meaningful pros/cons to either for the problem you've presented. That said, let's say you wanted the network to be fully real-time, with lots of notification messages appearing without having to refresh the page etc. For that, you may want to consider using Node.js and Express.js with SocketIO. You can get the same functionality in PHP/Ruby, but not as easily as in JavaScript running on Node.js. Node.js is a better choice for stateful, realtime applications.

I'll use a simple example that you might encounter in a game: class Weapon and class Tool . Weapons are used for attacking enemies, and have properties like damage, range etc. Tools are used for exploring the world: prying open lockers, breaking down doors. They have properties like weight, lifespan, etc. So what should a Crowbar extend from if the game rules say it can be used as both a weapon, and a tool? To add even more complexity, what happens when you have class RangedWeapon extends Weapon and class MeleeWeapon extends Weapon ? The crowbar is both. You can throw it, or beat people with it. So even if you decided it should extend from Weapon , which sub-class of weapon should it extend from? Instead, it would be better if you could combine different behaviors together. Combine RangedAttack , MeleeAttack , Leverage , and Smash behaviors together into a new game element called Crowbar . There is no inheritance tree or taxonomy to worry about - only discrete behaviors which can be combined in different ways to form new weapons/tools/gameplay elements.

MicroServices introduces network complexities. Everything must be async, everything must be made more fault tolerant, and you need to deploy a whole host of service watchers and routers. For example if service A is dependent on service B, it generally has to go through a router of some kind to know where to find service B on the network. That router then has to know when service B goes down, and where a new instance of it has spawned, so that it can tell service A where to find it. Monolithic apps don't have these complexities, and don't suffer from network latency as much. I would honestly adopt microservices as a last resort. The scalability argument doesn't really track, as any codebase can be spun up in a new instance and put behind a load balancer, monolithic or not. The challenge comes with managing state - user sessions, databases etc, between those instances - but that's a challenge regardless of which approach you take. A monolith doesn't mean a tightly coupled ball of spaghetti. It's perfectly reasonable for different modules to be built and maintained by different teams in different repositories even, but then compiled into a single application for deployment. Different modules within that monolith still act like services to other different modules in that monolith, so service re-use is just as much a part of monolithic architecture as micro-service architecture. Microservices make the most sense when two TOTALLY DIFFERENT applications should share a common service (e.g. authentication), AND that common service is responsible for logging and aggregating all activity from all of the client applications that use it. Without that second condition, all you're using the micro-services for is code-reuse, which is a horribly complex and round about way of doing that.