5 ms·

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

by zobzu 15y ago

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/ http://www.256bytes.net/

teaspoon 15y ago
None of these demo binaries will actually run on my OS, so maybe the extra 768 bytes are a fair tradeoff for abstracting away the platform.
- thibaut_barrere 15y ago
  These binaries will run on your OS if you install the corresponding runtime (DosBox or similar actually). Interestingly this runtime happens to be way smaller (2MB) than Firefox, Chrome or even Safari.
  - dalke 15y ago
    There's DosBox for the iPhone now?
    - thibaut_barrere 15y ago
      If you're not living in Apple's wallen garden, it seems so: http://litchie.com/blog/?page_id=123 http://litchie.com/blog/?page_id=123
  - daleharvey 15y ago
    now we just need to write google search, google maps, facebook, twitter etc for dosbox, some type of linking mechanism, have it installed on all computer by default and we are sorted!
    - thibaut_barrere 15y ago
      Most demo competitions do not assume you'll require internet connectivity at all, so that won't be required ;) 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 :)
magicalist 15y ago
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 15y ago
  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 15y ago
    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 :)
Skalman 15y ago
I'm sure the assembly code is shorter than the JavaScript code, right? Cause it makes no sense comparing the compiled/minified versions...
lunarscape 15y ago
Pouet [1] also has some has a great archive of demos. [1] http://www.pouet.net/ http://www.pouet.net/

by zobzu 15y ago

teaspoon 15y ago

None of these demo binaries will actually run on my OS, so maybe the extra 768 bytes are a fair tradeoff for abstracting away the platform.

thibaut_barrere 15y ago
These binaries will run on your OS if you install the corresponding runtime (DosBox or similar actually). Interestingly this runtime happens to be way smaller (2MB) than Firefox, Chrome or even Safari.
- dalke 15y ago
  There's DosBox for the iPhone now?
  - thibaut_barrere 15y ago
    If you're not living in Apple's wallen garden, it seems so: http://litchie.com/blog/?page_id=123 http://litchie.com/blog/?page_id=123
- daleharvey 15y ago
  now we just need to write google search, google maps, facebook, twitter etc for dosbox, some type of linking mechanism, have it installed on all computer by default and we are sorted!
  - thibaut_barrere 15y ago
    Most demo competitions do not assume you'll require internet connectivity at all, so that won't be required ;) 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 :)

magicalist 15y ago

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 15y ago
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 15y ago
  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 :)

Skalman 15y ago

I'm sure the assembly code is shorter than the JavaScript code, right? Cause it makes no sense comparing the compiled/minified versions...

lunarscape 15y ago

Pouet [1] also has some has a great archive of demos. [1] http://www.pouet.net/ http://www.pouet.net/