One of the PHP demos that goes over pretty well is my Flex socket demo. It used to be that Flex/Flash was really the only way to take advantage of WebSockets but with browser vendors implementing bleeding edge support for HTML5, developers can now use the WebSocket API in JavaScript. I wanted to combine that with the Canvas API and try to recreate a basic example of my Flex socket demo in HTML5/JavaScript. It mostly works (demo embedded at the bottom).
Code
- socket.html – HTML/JS file for connecting to the socket server
- socket.php – PHP file that creates the socket server
Who Can Run This
It’s been kind of cool to see the browser vendors really move forward to implement support for various bits of HTML5 and CSS3 without a defined spec. That can be problematic because the spec is still changing, causing code to break in new versions of browsers, but in general it means that web developers can live on the cutting edge for most browsers. Currently, the WebSocket API (and this example) should work in the latest version of Chrome and the Firefox 4 beta.
Differences in WebSockets with Flash and HTML5
Overall the WebSocket API is pretty easy to use. I took my existing PHP socket server code that works in Flash and tried to use it for the HTML5 version but all I was getting was the “close” event. The problem was that I wasn’t thinking about the handshake. Flash uses a policy file to determine whether or not it can connect, but the WebSocket API uses a handshake. I was able to grab some example code, change my PHP server to add the handshake then everything basically worked. The only other small change I had to make was to add a character (chr 0 and chr 255) to either end of the message I was sending through the socket_write method. I’m still not entirely sure why this is, but my onmessage event wouldn’t fire until I added those.
Charting with Canvas
I’m very excited about the Canvas API in HTML5. If you’re a Flash developer who has been working with the Flash drawing API, you’re going to be able to do some very cool stuff. The APIs are fairly similar with some syntax changes that you have to be aware of. The biggest pain I found was that once something is on the canvas, it’s on the canvas. You can’t reference specific drawn elements like you can in ActionScript. That makes doing things like the hover effect on specific charting points basically impossible.
Partly because of that, and because I’m still getting used to JavaScript I went with a very scaled down version of the chart. All this chart does is draw some grid lines and then plot the points as it gets them from the socket server. When you get to the end, the points are drawn off the page. I also couldn’t really figure out how to add to a path in a function call so I just went with the points instead of making it an actual line graph. I’m fairly sure that most of these are due to my JavaScript incompetence and not a limitation of Canvas.
Conclusion
It was both a lot of fun and very painful to go back to JavaScript. It’s an incredibly powerful language but if you come from Flash, you’ll find yourself banging your head against the wall because of subtle differences. The one thing that keeps tripping me up is figuring out how the DOM works compared to Flash. Another sticking point is the tooling. We have very good tooling on the Flash side compared to JavaScript. Chrome’s developer tools and Firebug both help a lot, but there’s no tool out there that provides code completion for the Canvas drawing API. When you don’t know the API that well, it means a lot of Googling, and a lot of the examples are pretty basic. I think a tool with basic code completion for Canvas would make it a lot easier to start creating complex content in.
It’s definitely rough to go from Flash to JavaScript but hopefully I’ll be playing around with the new stuff in HTML5 more, especially as Dreamweaver gets more support baked in.
TweetRelated posts: