1k Rose - How a 3D Rose was made in under 1K of javascript
romancortes.com
romancortes.com
And guess what. The 256 bytes demos are nicer and more complete than the js1k! They've sound, better 3d effects, etc.. plus they actually run those nicer demos on much, much older hardware without lagging (js demos use quite a bit of cpu even on modern hardware)
Four times as much space, not nearly as good. Show how much went into "language abstraction". Scary!
Reference: http://www.256bytes.net/
Interestingly this runtime happens to be way smaller (2MB) than Firefox, Chrome or even Safari.
I understand your irony and do agree that using standards of today is expected.
This doesn't remove any validity to the OP point that what we use today (apart from WebGL or other hardware accelerated code) is several orders of magnitude behind what was already there 10 to 15 years ago.
I do hope though that we'll see more and more widespread/standard techniques to grab back a bit of speed there without only counting on Moore's law :)
So, good work, you've declared all such competitions with languages less terse than assembly "scary" and no doubt a harbinger of some slippery slope. I hope there aren't any competitions with ISAs smaller than x86, or your world really might fall apart.
[1] 'rgb(,,)'. converting to hex might be a good size optimization there, actually, but it would still need a '#' and be a formatted string.
For instance, 256b.net demos aren't 256 bytes of assembly, they're 256 byte executables. If you download a demo, you can see that the ASM files, even with comments removed, are typically 1 or 2 kilobytes.
So now we have less functionality and worse performance in the same or half as much space, and that's still ignoring the fact that the mapping of source code bytes to actual instructions don't in any way resemble each other. If you included some measure of information density, you should probably be allowed at least another kilobyte of Javascript.
Then we get to functionality and performance. We all (hopefully) know the tradeoffs inherent in dynamic and JIT-compiled languages running in a browser that's trying its best to be an entire OS with all the intervening cruft between code and hardware that that implies. On the other hand, the 256b demos require DOSBox because they use extremely specific hacks, so should js1k demos be allowed to use one specific version of a browser, with (for instance) a known math and canvas object key order so it never has to refer to anything by name? Should it be allowed to use WebGL? The actual competition requires them to work in all "current browsers", including IE, but if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos...but what would that even mean?
In other words, it's an important consideration but this is a terrible comparison :)
- "dosbox" 256b demos don't use extremely specific hacks: they use what was 10 to 15 years ago the standard platform (ie: DOS, Bios, VGA...); that will be the fate of today's javascript cool WebGL/Canvas stuff, including my own (see [1])
- the question about weither to use extensions or not (ie: WebGL, OpenGL, soundcards hardware...) is there for both assembly and javascript demos (see [2])
- basically IMO, unless you use WebGL, the performance of what you'll get is an order of magnitude or two slower than the equivalent in ASM so far on my tests at least
- please note that I'm not an ASM "freak": I tend to use ASM only for the small loops that require it (for instance, I released [3] which 95% Pascal and 5% asm roughly)
So I stand on my point: unless we rely on hardware and WebGL, we have lost several orders of magnitude of performance, by replacing a standard by another.
But please note I still enjoy these things coming out and I seriously hope WebGL et al. will get widespread usage!
[1] http://thbar.github.com/playground/
[2] http://www.geeks3d.com/20101126/demoscene-38644-mandelbulb-i... 1k intro of an OpenGL Mandelbrot set in 3D coded in assembly
[3] http://www.pouet.net/prod.php?which=17268 1995 demo
As you said, "if you could get the WebGL syntax overhead to work in 1k, you could kick the crap out of the 256 byte demos." I believe that's exactly the point. Even if there is all this theoretical power in our JS environments, we aren't using our environment nearly as efficiently as the 256 byte demos used theirs.
It's also worth noting that those 256b demos ran on the standard platforms of their day, which yes, required MS-DOS, but then could run on any intel compatible processor, with any standard motherboard, with any standard bios, with any standard video card. And I would be surprised if they actually called into MS-DOS at all, and didn't just talk to the hardware directly.
I prefer startup news and programming advances. That's not really programming news, it's just a rather dull writeup about how someone made a picture of a rose, something I have no desire to do.
And we've been able to do it for decades. Apart from some reason now HTML5 has a canvas a lot of people seem to have the need to reinvent the wheel.
My point, we're all different, there's no such thing as perfect. These kind of articles are fun once in a while but HN would be fairly useless if that kind of article was all that dominated it.
You can get quite interesting and very creative solutions when you apply artificial constraints.
This stuff happens in the real-world all the time, especially in consumer electronics. I've had to do video-rate unpacking of samples that were aligned on really nasty boundaries. Far cheaper (in this instance) to do it in software . . . so we got clever.
http://canonical.org/~kragen/sw/dofonts.html
Edit: yes; a 1023-byte version, specialized for the 4×6 font, is now linked to from that page. The 1023 bytes includes the entire HTML file, including both the font and the code to render it.
My tinfoil-hat conspiracy theory is that the Canvas element was spec'ed into HTML5 by CPU fan manufacturers.
I got lot of downvots on HN previously by saying HTML5 was the exact same shit as Flash, what's better is that there is no way to block canvas animation ads yet.
Think about dozens of canvas animation ads embedded with Javascript. It will be as shitty as Flash. I'll switch to the first browser that allows me to selectively disable all HTML5 crap.
There was a time when algorithms for decoding an audio file put your CPU in the red, yet we found many applications for them :)
A lot of these cutting edge HTML5/WebGL demos are put on a separate page from the thing explaining it. One of the reasons we have this technology is so we can put this stuff right there on the the page, seamlessly available to the user.
Sometimes it makes sense for performance or aesthetic reasons to have it separate, but certainly in many cases including this one it doesn't.
Keep a separate demo page sure, so people can link directly to your demo. But have it right there in your blog post as well, personally I think it adds to the wow factor!