

1k Rose - How a 3D Rose was made in under 1K of javascript - cleverjake
http://www.romancortes.com/blog/1k-rose/

======
zobzu
This is scary. js1K is what 256bytes was in "my" days. Thats right, 256 bytes
of asm to get a nice demo.

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/>

~~~
magicalist
This is a nonsensical comparison. Considering that the language chosen
_requires_ fairly verbose code (everything from a minimum 14 bytes for a
function declaration to longwinded API names, eg "fillStyle" that takes a
string with another 7 bytes of decoration[1]), this is exactly what you'd
expect. The challenges presented by the particular language and execution
environment are a large part of the entire point of these exercises, they
aren't a failing.

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.

~~~
thibaut_barrere
I don't find the comparison nonsensical (and I do ruby/coffeescript all day
:-) - we have at least to take into consideration that the abstraction here
came with an amazing cost nonetheless.

~~~
magicalist
There is always meat in looking at the tradeoffs necessary for
language/platform design, but the problem is that this particular argument is
completely specious.

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 :)

~~~
thibaut_barrere
I'm not sure to understand your point (maybe I understood you in reverse, not
sure!):

\- "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...](http://www.geeks3d.com/20101126/demoscene-38644-mandelbulb-
in-1024-bytes-openglglsl/) 1k intro of an OpenGL Mandelbrot set in 3D coded in
assembly

[3] <http://www.pouet.net/prod.php?which=17268> 1995 demo

------
willyt
Meta comment: This is a perfect hacker news submission. I started reading
hacker news because of articles like this.

~~~
mattmanser
Meta comment: For you maybe. I found it rather boring and skimmed it after the
first para. It's about javascript to begin with ;) And looks a bit poo.

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.

~~~
kragen
Sounds like you're unclear on the concept of "hacker" and "hack". Remember, if
people never reinvented the wheel, we'd still be rolling our carts around on
discs made of three pieces of wood.

------
rplnt
I remember this site because of another 1k js competition, result of which was
a Christmas Tree -- [http://www.romancortes.com/blog/how-i-did-the-1kb-
christmas-...](http://www.romancortes.com/blog/how-i-did-the-1kb-christmas-
tree/)

------
kragen
That's pretty nice. I wonder if you could squeeze my <canvas> font rendering
engine under 1K? The base64-encoded PNG font is 635 bytes, but you could
probably use the 4×6 font by Janne Kujala to cut that down to ≈512 bytes.

<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.

------
nhebb
1k is impressive as a coding feat, but I'm not sure of the practical
application of this - i.e., I'm less impressed with 1k of code when my CPU
meter gets into the red zone - and stays there.

My tinfoil-hat conspiracy theory is that the Canvas element was spec'ed into
HTML5 by CPU fan manufacturers.

~~~
est
Same rant as Steve Jobs claimed why Flash should die years ago.

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.

~~~
k33n
The only reason this demo uses a lot of CPU is because it uses a lot of tricks
to stay under 1K. Any JS guy could get the same result with far less CPU
usage. Also, HTML5 has nothing to do with CPU usage. JavaScript performance
(which is quite a bit better than Flash, even with SVG and/or Canvas
manipulations) is the thing that actually uses CPU.

~~~
est
It's no help that JS is faster than AS for now, AS used to be much faster than
contemporary JS, but how about display ads with dozens of Flash embedded? Fast
is only relative.

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.

------
hartror
This a great piece of code but the author does one thing that has gets my
goat.

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!

~~~
LVB
The demo is very CPU intensive to the point that the fan on my MBP comes on
shortly after starting it. If I'd stumbled onto it with my wife's BlackBerry
it probably would have caught on fire. I think he chose correctly in leaving
the script off of the blog page.

~~~
kalleboo
It doesn't seem like it'd be that hard to add a "render" button.

~~~
LVB
Or to click on the flower at the top of the blog post.

------
lnanek
Beautiful. Lots of interesting techniques detailed too that could be useful.
I'm a big complainer, but even I'm having trouble complaining about it not
being practical. Nice.

------
RvbNews
Now I know why I should have taken math in school :) This is very impressive.
This is sooo far removed from my daily job as "business application"
developer, which makes it the more interesting. Thanks for posting.

------
visegrip
I'm giving a dozen of 3d flower to my sweetheart on Vday.

------
dpakrk
awesome piece of hacking! great job

