New Theme, Digging Into WordPress

I just recently changed to a new theme for my site. Since then, I’ve been doing my first real digging into the internals of how theming works and how to talk to the back end of WordPress. It’s been a suprisingly pleasant venture – all your content is easily accessible and the interface is clean. I’m just starting to learn PHP (from a .NET background), and it’s been nice to find that I can hack around and usually get the code right on the first or second try.

I’ve also been making some progressive enhancements to the site at the same time. If you came in via a webkit-based browser, you’ll hopefully notice the webkit-only light blue gradient behind post titles, as opposed to a solid color. I also animated the RSS button in the upper right hand corner to grow 10% larger on hover. These are examples of ways to embrace progressive flourishes on your site without breaking the experience for anyone. Next up, I’m going to incorporate rgba into the footer somehow. Hope you enjoy the new layout!

Full Screen Canvas Particle Demo

Full Screen Particle Demo

I created a new version of my particle demo using the HTML5 <canvas>. This version is full screen, inspired by this amazing canvas demo at Iteration Six. I’d seen their demo prior to my starting to tinker with the canvas tag, but I never really tore it apart and looked inside. From what it appears, my code and their code were achieving a lot of the same things, so I decided to update mine to take advantage of some of the exciting features in their demo, including the full screen mode and the mouse interactions.

This demo uses a bit more jQuery than the previous one to handle mouse events. The canvas is much larger than the previous one, so I had to make some small changes to increase performance. Most notably, I had to halve the framerate – this demo runs at 10fps rather than 20. I sped up the particle speed so they cover distance quicker as well.

HTML5 Canvas Particle Example

Canvas Particle Demo

Here’s a cool particle demonstration of the HTML5 <canvas> tag. It’s a tremendously small amount of JavaScript code that is responsible for pushing some radial gradient particles around a canvas. You can check out the source code to see how things are done – it uses jQuery a bit and the demo itself uses a free color picker control.

The demo works best in Firefox. Chrome has some ugly rendering artifacts when the gradients cross over one another and Safari can’t push a lot of particles on the screen without dying, but Firefox can render several hundred particles with ease (Internet Explorer doesn’t support <canvas> at all). If the computation for this demo were to be done on a GPU rather than a CPU, you’d probably be able to pump out thousands of particles with no issues.

Jaxer – Great Technology, Needs a Little Love

Jaxer

Jaxer is a somewhat new technology that I’ve recently started to delve into. Jaxer is billed as the first AJAX server – basically, it’s a combination of a ‘web server’ and a set of APIs that can be used to develop web applications that transparently utilize asynchronous XMLHTTPRequests instead of postbacks as the standard way of communication between client and server. Jaxer development can be done in the Aptana IDE or via an Eclipse plugin.

Jaxer is somewhat unique in that the language used for both client and server is JavaScript. The server itself is basically the internals of the Mozilla platform (the DOM engine, the parser, the Javascript engine) along with a bunch of glue and a Jaxer API that facilitates, amongst other things, database and file access on the server side. The server is not standalone – it must be run as an Apache plugin (and IIS support seems to be planned for some future time).

What are some of the benefits of using Jaxer? One of the most obvious is the embracing of AJAX. As long as you understand the Client-Server paradigm, making AJAX requests is trivial. There is no extra markup needed – if you call a server-side method from the client side, the request is XMLHTTPRequest wrapped and sent to the server.

Another benefit to Jaxer is that there’s no new language to learn. Since Jaxer is built on JavaScript, it’s easy to add whatever JavaScript framework you’d like into the mix too, such as jQuery and YUI. These libraries are even available on both the client AND the server, rather than on the client alone.

Jaxer also comes with support for the Aptana Cloud built into the Aptana IDE and the Eclipse plugin. Once you have a Jaxer application working, you can do very easy deployment to the cloud service and be running in minutes with no additional configuration needed. You can also easily connect to the cloud to view your database and files through Aptana.

So, Jaxer sounds pretty cool. What are some of the drawbacks of it? One of the biggest currently is there’s no support for an Object-Relational Model (ORM). Many market leading web languages have ORM built in that make data manipulation easy. All database access must be made with straight SQL, which feels a little dated now. On the plus side, Jaxer comes configured with SQLLite out of the box, so no database setup is needed to run locally.

Another huge drawback is that there are not many places to host Jaxer on the web. Neither Dreamhost nor Godaddy have support for it (and, it’s been out for a year and a half!), so you’re pretty much relegated to a virtual private server or the Aptana Cloud for affordable hosting. Both options can be had for as little as $20 a month, but that’s a lot of money to just tinker around with some ideas.

Another drawback to Jaxer is that there is a hefty cost for a commercial license for the IDE (though a non-commercial license is free). I understand that the people behind Jaxer are a business, but it hurts particularly badly when your platform target is Linux-Apache. Both Ruby and PHP have free development tools available, so getting a company to fork over $500 a seat is not trivial to do.

There’s also no support for master and child pages in Jaxer. Jaxer was built as a tool to create web applications rather than web sites. You can’t easily separate your HTML files into a container and content frame, so building multi-page websites is not something that I would recommend in Jaxer.

Make no mistake – Jaxer is a compelling product. It is simple, easy to learn, intuitive, built on existing technologies, and it can make some wicked applications. It has support from some major industry players, including John Resig of jQuery fame. It has a long road ahead if it’s going to break into the big leagues, but I certainly would recommend giving it a spin. If nothing else, it will open your eyes a little on how to write world-class AJAX web applications.

Firefox 3.5 Supports CSS Transforms, no Animation Support Yet

Firefox 3.5, the recent release of the latest version of the Firefox web browser, now supports CSS transforms. CSS transforms are effects, such as scale, rotate and skew. This is a step forward for the Gecko rendering engine, but in plain terms, it still clearly lags behind webkit, which supports 2D and 3D CSS animations.

I’ve lately been very interested in how browsers handle the leading edge – browser technology that is still years away from widespread adoption. The question I’ve been having as of late is whether Firefox can keep up in this arena. They certainly aren’t slouches when it comes to new technology, but they are definitely being outpaced, particularly by Webkit. With the support for plugins, the rendering engine of Firefox is burdened with cumbersome functionality that must be maintained as new elements are added. This slows down the process of technology adoption. On the other hand, Webkit-based browsers have decreased plugin capability, which is a hindrance to their widespread adoption (and also a significant factor in why they consume less memory and perform faster in real-world use). Clearly, Firefox is a market leader, so their strategy has paid off in many respects.

This also begs the question of whether we would ever see a convergence of technology between Firefox and it’s closest competitors, Chrome and Safari. It is technically feasible that Firefox could be chopped apart and refueled with Webkit, but I’d expect that the effort would be far too difficult to go into hesitantly. The other side of the coin is that Webkit-based browsers will eventually support plugins. Google has openly stated they are working on robust plugin support, a front on which they’ve already made a few strides. One has to wonder if this will be a turning point – it certainly has the potential to be so.