Jacob Seidelin writes about JavaScript and HTML5 canvas experiments, including Wolfenstein and Super Mario Kart recreations and visualizations.
HN commenters link his canvas tools and demos, including a Wolfenstein port, Canvas2image, a WebGL cheat sheet and an early JS-in-image technique.
the overhead of the interpreted language is going to slow things down as compared to something compiled down to the metal
Welcome to the Java vs. C debate, previously the C vs. assembler debate, previously the assembler versus hand-coding machine code debate. Computers these days, even netbooks, are fast. Very, very breathtakingly fast.
There has also been a significant amount of work done in VMs, much related to Java, which has delivered tremendous performance boosts to interpreted languages. Google has a very talented VM team working on Chrome's JS execution engine (SpiderMonkey or something, can't remember off the top of my head).
But really, after you get past Wolfenstein done in Javascript (http://www.nihilogic.dk/labs/wolf/ ) how more does the typical user actually need? After that it isn't a matter of CPU cycles, its the programmers coming up with non-painful ways to develop software to use them.
Whenever "vector look" is not what you aim for.
One huge example is games - vast majority of games use bitmap graphics.
Or if you want to do some pretty data visualizations like heatmaps.
----
Edit: Here are some examples showing what fast canvas bitmap graphics can do (and what would be very very hard to do with SVG):
http://29a.ch/2010/3/24/normal-mapping-with-javascript-and-canvas-tag
http://mrdoob.com/lab/javascript/effects/fire/01/
http://mrdoob.com/lab/javascript/effects/water/00/
http://www.nihilogic.dk/labs/canvas_music_visualization/
http://www.nihilogic.dk/labs/strange_attractors/
http://www.p01.org/releases/512b_jspongy/jspongy.htm
http://www.p01.org/releases/20_lines_hypno_trip_down_the_fractal_rug/
http://www.p01.org/releases/20_lines_dynamic_hypnoglow/
http://www.ehkä.fi/
The CANVAS tag allows per pixel placement. It's what makes things like this possible.
From the Source-
This file is part of the article series by Jacob Seidelin about
creating a ray casting engine with JavaScript, DOM and Canvas.
If you have questions or comments, please contact the author at
either jseidelin@nihilogic.dk or http://blog.nihilogic.dk/
The code samples here are freely available under the MIT license.
See: [http://www.nihilogic.dk/licenses/mit-license.txt]
The graphics for sprites and walls are property of id Software.
This technique has been around since prior to 2008 at least, the biog entry below introduced the code[1], along with providing a tool to compress your js into an image using ruby [2].
The technique has a legitimate use as a suave compression method and was termed "super packing" in 2011 [3]
[1]http://blog.nihilogic.dk/2008/08/imageinfo-reading-image-metadata-with.html
[2]http://www.nihilogic.dk/labs/canvascompress/
[3]http://daeken.com/superpacking-js-demos
"... Processing ported to JavaScript ..."
My project just got a lot more interesting. One of the things I was having trouble with is generating an image from data with severe constraints on modules & processing time.
Processing.js fills the gap of PIL which I couldn't use. I'm finding more and more interesting JS modules. Take this one for instance ~ http://www.nihilogic.dk/labs/canvas2image/ Converts the canvas to a binary image.
Thinking about it a bit more, it's actually worse than that.
http://www.nihilogic.dk/labs/imageinfo/ shows how to extract EXIF data from JPEG files, so using EXIF + the cache hack is possible for sure.
http://www.nihilogic.dk/labs/id3/ shows how to extract ID3 metadata from MP3s in Javascript, so you could do a similar thing like that.
Can anyone think why just using the cache hack + a JSON data file wouldn't work?