Dear PHP,
I’m sure you noticed that I have been a bit distant lately. Our relationship hasn’t been functioning as well as it used to and I don’t know which one of us is to blame.
A Technology Blog by Alan James
Dear PHP,
I’m sure you noticed that I have been a bit distant lately. Our relationship hasn’t been functioning as well as it used to and I don’t know which one of us is to blame.
Recently, I have been working a lot with WebSockets, specifically with Socket.IO. As a former ActionScript developer I love being able to return to using events to send and receive data as well as having my application get real time updates from the server. It feels so natural and fits really well into the types of applications I like to build. However, I wanted some more organization. I wanted a library that was designed around CRUD and WebSockets. Something like Mongoose, but on the frontend. I looked all around GitHub and found some libraries that were close, but nothing that was perfect, so I decided to make one myself.
Since deciding to use WebSockets instead of AJAX calls with Node.js I have discovered some interesting things. Some of these things are good, and some are bad.
I’m in the process of converting a web application from an Apache + PHP backend to Node.js. The application being converted is based heavily around real time interaction between users, so, it was a natural fit for WebSockets.
In fact the old application used a Node.js backend for WebSockets, but an Apache + PHP backend for everything else, including page generation and AJAX endpoints. This means every AJAX driven form had a PHP endpoint which performed a desired action and a WebSocket event listener waiting to broadcast the event to other users.
Having to recode this application from the ground up in a new asynchronous language presented an interesting question to me.
Why should I use AJAX when I have WebSockets?