I spent quite a bit of time playing with Processing.org a few years back, mainly using it for video processing (video effects, blob detection, etc) but also for 3D. I recently stumbled across a javascript port of Processing called, logically, Processing.js. This is a really nice idea, taking the established processing syntax (a subset of Java) and rendering it to a HTML5 Canvas. The Processing framework uses a “dont call me, i’ll call you” inversion-of-control pattern which makes it very easy to get something up and running but that, and the fact that it is not standard javascript, can make it tricky to integrate.
I also found a very slick library called three.js which I used to create the header animation on rayh.com.au. It provides a basic set of 3d concepts such as points, lines, renderer, camera, etc which can use to draw and animate basic 3d scenes. There is no special loop function, you just use setInterval to trigger your animation to update every once in a while.
My personal site, rayh.com.au, was in need of dire attention. I had originally made it a flat html/js/css site to show off some jQuery skills. However, even though I really like the idea of a site built entire from static files (damn fast) and using javascript to drive the dynamic elements, it is not search engine friendly.
Biting the bullet, I decided that I needed some sort of server-side scripting. By day, I mainly use Java and sometimes Ruby. So my choices seemed to be Java, Ruby or PHP. Many moons ago, I was a PHP developer and I bailed out of that technology in favour Java. For me, PHP just sucks in far too many areas for me to adopt it for a one-off tiny website, but the reasons why is another story. Java seems way to heavyweight and verbose for my needs and so Ruby seemed like the natural choice.
Previously I had used Rails for projects, but it’s full-stack solution was still too much for my needs as my site has no database access. This led me to look at Sinatra, a super lightweight and declarative approach to a web application. I simply converted my existing html file to a .erb and told Sinatra:
require 'rubygems'
require 'sinatra'
get '/' do
erb :index
end
This code is pretty much all that is needed to get up and running. It tells Sinatra that when a user accesses the root of the site using GET, serve the index.erb file from the views/ directory. This approach allowed me to just add the features I needed to perform the simple set of requirements I had rather than trying to convince Rails to do less.
When it came to deploying the app, I used Passenger (AKA mod_rails) with apache which was an absolute breeze. I highly recommend this approach if you need something more powerful than simple javascript & html without resorting to full-stack web application frameworks or ugly php scripts embedded in html.
