[HN Gopher] JS1024 Results - 1k JavaScript Demos
___________________________________________________________________
JS1024 Results - 1k JavaScript Demos
Author : KilledByAPixel
Score : 155 points
Date : 2020-08-01 13:21 UTC (9 hours ago)
(HTM) web link (js1024.fun)
(TXT) w3m dump (js1024.fun)
| ggregoire wrote:
| I'm not into graphics/games development so that might be why, but
| I had never heard of Shaders (the third category), which doesn't
| look at all like JavaScript.
|
| Demo: https://js1024.fun/demos/2020/12
|
| Source code: https://js1024.fun/demos/2020/12/source
|
| Shaders: https://developer.mozilla.org/en-
| US/docs/Games/Techniques/3D...
| jjcm wrote:
| I really appreciate how well documented a lot of the source files
| are. There are a lot of cool golf hacks/tricks in these!
|
| i.e.: https://js1024.fun/demos/2020/16/source
| lifthrasiir wrote:
| Besides from being one of the winners (AquaPop1K), I also had a
| pleasure to read every single source code to rate submissions
| (as every submitter could rate other entries). I recommend to
| do the same if you have time.
| lifthrasiir wrote:
| Post-mortem writeups by submitters:
|
| Frank Force: https://frankforce.com/?p=7617 (1st place)
|
| Raimon Rafols:
| http://blog.rafols.org/index.php/2020/07/21/javascript-ballo...
| (10th place)
|
| Mattia Fortunati: https://www.mattiafortunati.com/detective-moji-
| postmortem-a-... (16th place)
| vanderZwan wrote:
| > Frank Force
|
| Hey, that's the guy who did Bounce Back[0] for JS13K! He's got
| some pretty cool stuff on his website
|
| EDIT: Wait a minute, that's KilledByAPixel, who submitted this
| link
|
| [0] http://frankforce.com/?p=6936
| dietrichepp wrote:
| I haven't written a post-mortem but I'll take a quick stab
| here, and post a more polished post-mortem on my website later.
|
| My demo is Star Traveler, which placed #1 in the 2D Canvas
| category. The GitHub repository is here:
| https://github.com/depp/demo-traveler
|
| Source code: https://github.com/depp/demo-
| traveler/blob/trunk/src.js
|
| What I like about 1K demos is that you can make them in a
| relatively short amount of time--something like a week or so,
| without taking time off. After a week of work I was happy with
| what I had written, out of space, and had diminishing returns
| when I attempted to reduce the size. By comparison, JS13K can
| be a lot more work.
|
| The first thing I did was set up a development environment
| which would reload in the browser every time I saved changes.
| The development page showed the number of bytes left at the top
| of the screen and put the exact, submission-ready code in an
| iframe. Saving changes would trigger everything to be minified
| and packed again. Packing is done with Terser -> RegPack. No
| potentially incompatible techniques like method hashing were
| used, but that's probably because I didn't see a size
| improvement when I tried them. There are some custom
| transformations on the code during compilation, mostly so I
| could have ESLint watch my back.
|
| The demo itself has three parts to it. Most of the objects are
| rendered by callback functions, and there's a big array of
| callback functions in back-to-front order. The function
| closures contain any generated data necessary for drawing the
| data. The parts are:
|
| 1. Mountains and clouds, which are just simple midpoint
| displacement fractals. The mountains were flipped upside down
| and stretched to make clouds. Various techniques for generating
| a fractal were tried, a recursive functional approach ended up
| being the smallest.
|
| 2. Stars, which are just randomly placed in 3D space and
| randomly resized each frame to make them twinkle.
|
| 3. The planet, which is drawn separately. The submitted version
| draws it over the clouds. This was fixed in the repo, but not
| re-submitted.
|
| Notes on technique:
|
| - Path2D turns out to be a very efficient way to specify a path
| for a Canvas. It uses an SVG path string to specify the path,
| which is more compact than using .moveTo() and .lineTo(). There
| is room for improvement.
|
| - The 'color' function is a beast, it lets you represent an RGB
| color as a 3-digit number from 111 to 999, and calculate things
| like gradients. There was a lot of tweaking to get colors that
| I liked.
|
| - Did a lot of inlining and un-inlining of functions at the
| end. For example, if a function f(x) is defined like f(x) = 4 *
| ..., then you can move the constant out of the function, or
| into the function from the call sites.
|
| - Checked the minified code to see how functions were being
| emitted. If they were emitted as (x) => { a; b; }, I would try
| to change the code so they could be emitted as (x) => (a,b).
|
| - RegPack gives you limited space savings for repetitive code,
| so use it.
|
| - If you need local variables, just add arguments to your
| function and use those.
| LeonM wrote:
| That 'Wetlands' demo (winner in shader class) is completely
| borked in my browser (FF 79, Linux).
| smusamashah wrote:
| I though this is same as https://js1k.com/ it's not
| chrismorgan wrote:
| "Shedding snake" reminds me of a game I made on my Casio
| CFX-9850GB+ Color in high school. It started out as snake, but
| keeping track of the positions of the snake's pixels in an array
| or matrix, even if treating it as a ring buffer so you weren't
| constantly shuffling all the values in it, was really slow, so
| that by the time the snake was even six pixels long there was not
| the slightest bit of challenge to it because it was moving less
| than two pixels per second (and by ten, below one). So I turned
| it into what I called Snail Trail, with it just laying down
| pixels behind it and never keeping track of them, because you
| could query "is this pixel filled?" much more rapidly (and it was
| O(1) rather than O(n2) or worse). That was much faster, and I
| rapidly worked out the optimal strategy. A year or two later I
| transferred it to someone's newer model of calculator which was
| generally about six times as fast, and... yeah, I had to insert
| busy loops to make it playable!
|
| I had good times with that calculator. 32KB taught me frugality
| not unlike that needed for competitions like JS1024, and how to
| find that there was a character/instruction akin to a semicolon
| in Python that took one byte, where the new line
| character/instruction took two bytes. (I only obtained a manual
| for the calculator after having it for two years. Figured out one
| or two new tricks after that, but I'd worked almost everything
| possible out by trial and error.) So power efficient, too: I
| changed the four AAA batteries only twice in more than three
| years of _very_ heavy usage (looking back on it, I probably got
| more than 200h of life from each set), while all the rest of the
| class that had the newer, faster version (except one other who
| had the same model as me) would need to change them around once a
| term, and they didn't use their calculators even a _quarter_ as
| much as me. I'm going to guess figures of a CPU 6x as fast and
| power consumption 30x as high. And those newer ones were even
| only monochrome rather than three-colour LCD.
|
| Then after I left they shifted to CAS calculators and battery
| life was a zillion times worse again. And laptops, phones and
| such will be even worse still. Ah well.
| skitter wrote:
| Same for me, except with the FX-9860GII and for the 'trails'
| feature originally being a bug in my ring buffer that triggered
| when it grew.
|
| It definitely was fun to experiment within such constraints. I
| can't remember being very concerned with program size, although
| after a certain size there was a boundary the jump statements
| weren't able to cross any more. Only having global one-letter
| variables and no function calls (and a 21*7 character screen)
| also made the code hard to read/write, but it was a fun puzzle
| and I ended up writing a ray caster (god it was slow),
| something akin to the game Concrete Jungle and a complete
| 2-player implementation of Settlers of Catan, amongst other
| things. Not sure if my math teacher was a fan of me not paying
| attention in class though.
| chrismorgan wrote:
| I say 32KB, but the actual usable space was more like 20KB,
| due to things like 4KB for a screen buffer if you went
| graphics mode rather than text mode, which I did for some
| things and needed to do if ever actually graphing, however
| much if you used lists or matrices, _& c._ Anyway, I kept
| writing programs (sometimes games, sometimes useful things
| like automating the techniques we learned, such as a surd
| simplifier or a quadratic solver or a prime checker), so
| every so often I'd run out of space and rename a multi-letter
| program down to one letter to save a few bytes, or comb
| through a program to find ways of saving a few more bytes. I
| certainly spent _many_ hours coming up with clever ways of
| saving single bytes. It was good fun. Even sold a few
| programs to other students for a few dollars if they had the
| necessary transfer cable. Occasionally I'd regretfully delete
| a program if it was no longer pulling its weight.
|
| I definitely never tried a ray caster or anything that
| complex. I can imagine that taking literally hours to render
| a single frame, if I even coded it right.
|
| I kept my calculator in my pencil case, so I always had it
| with me in classes. I think all the teachers (definitely not
| just maths) were pretty much resigned to me using it when I
| finished my work in their classes (or if I didn't want to do
| it and reckoned I could get away with it). Having three elder
| siblings that would read books or used calculators under the
| desk certainly helped. One teacher complained volubly about
| the first couple of us for this very reason (and I was very
| probably worse than them), but by halfway through my
| schooling he said to my mother once that he always loved
| having Morgans in his class. This amused mum greatly.
| Stockholm syndrome, we decided.
| Extigy wrote:
| My lockdown project has been hacking up my CFX-9850G
| calculator. So far I have physically removed the ROM of the
| calculator and replaced it with a new ROM (I was able to get
| old-stock chips from aliexpress) flashed with a patched version
| of the original OS that includes a new BASIC command to jump to
| a fixed location in RAM and start executing whatever is there.
| This means I can write and run arbitrary machine code in the
| calculator's RAM by abusing the built in backup feature. The
| Hitachi CPU in the calculator is quite strange but by working
| with the little information I can find online [1] I have
| written an assembler and linker for creating compatible machine
| code from a custom assembly language. The resulting code runs
| much faster than in BASIC because it doesn't have to be
| interpreted. Here [2] is a video of the calculator jumping into
| RAM and running a Game of Life program that I wrote when Conway
| died. I'm currently writing code to run the 3-colour display
| for a replacement Forth-like shell/OS with the aim to
| eventually get to the point where I can replace the calculator
| ROM completely with my own. Writing my own mathematical
| functions for a calculator is fun when (AFAIK) the CPU itself
| lacks even multiplication opcodes.
|
| [1] http://martin.poupe.org/casio/ [2]
| https://youtu.be/cTB5YM898g4
| jacquesm wrote:
| Bad time to have your cert go bad on you.
| tyingq wrote:
| The site is unusable in portrait orientation on a phone. You
| can't see the [X] to dismiss the pop up divs unless you rotate
| the phone to horizontal.
| vesinisa wrote:
| I only get a secure connection error with Firefox 79 (on
| ArchLinux) when trying to connect to that domain. The certificate
| configuration seems to be missing some intermediate certs:
|
| https://www.sslshopper.com/ssl-checker.html#hostname=js1024....
|
| https://www.ssllabs.com/ssltest/analyze.html?d=js1024.fun
| malinens wrote:
| Alway there is that one arch guy in the comments
| Tajnymag wrote:
| Having the same error on Firefox Preview
| vesinisa wrote:
| Same thing with Firefox for Android ..
| fasfsafsa wrote:
| i fucking hate javascript
| speedgoose wrote:
| I like poneys.
| nlh wrote:
| There's something ironic about a site hosting intentionally tiny
| snippets of code that's crashed / sluggish under the social media
| hug of death...
|
| BUT - the few that I've managed to see are super cool, so when it
| comes back to life it's worth checking out!
| jakear wrote:
| Question for people that run websites that have been "hug of
| death"ed: would your website be able to be statically hosted on
| something like github pages, if no why not -- if yes why do you
| choose not to, given it is free and would make all scaling
| troubles go away (or so I've heard).
| chrismorgan wrote:
| There are two reasons why sites fall over in cases like this:
| CPU saturation, where the solution is better caching (which
| includes going fully static), and network saturation, where
| the solution is either to get fatter pipes or to reduce the
| data transferred. Hugs of death are normally due to CPU
| saturation.
|
| But in this case, I suspect that the server is just
| saturating its network connection because of poor treatment
| of images.
|
| I have JavaScript disabled so maybe it's loading more if you
| have JavaScript enabled, but when you exclude images, it's
| only transferring about 152KB. Images are where it goes
| wrong: it's serving up a large number of images, and some of
| them are unreasonably large and high quality (like 34k place,
| a 1000x1000 PNG of a fractal being shown at 400x400), and
| most significantly it's using quite a few multi-megabyte
| GIFs, which is flatly stupid and wrong and they _deserve_ to
| have their site fall over for pulling that.
|
| So the end result is at least 20MB. 20MB = 160Mb, and if your
| server has only a one gigabit link (very common), you can
| suddenly only cope with about six visitors per second (though
| in practice things will start falling over before that, maybe
| round down to five), which is not quite enough for the peaks
| you'll get when high on HN, and it becomes a bit of a
| cascading problem, kinda like a capacitor but bad.
|
| The solution is to treat the images properly: actually
| _compress_ them, use videos instead of GIFs, that sort of
| thing. I reckon 3MB total is readily attainable here, which
| would allow you to serve 40 visitors per second, which is
| probably enough.
|
| So yeah, putting your pages on a platform with really fat
| pipes will solve problems like this after a fashion, but I'd
| argue that it's not really _solving_ them, it's just letting
| you get away with doing a bad job and shifting the burden
| onto users.
| lifthrasiir wrote:
| There was 5MB preview image limit for each submission. I
| was a bit surprised when my preview image went straight
| into the listing after review. The organizer was a bit
| struggling with the website (for example, there was no
| HTTPS for the first days of the contest and multiple people
| helped to get it working), hopefully next time it will
| improve.
| detritus wrote:
| You're assuming everyone expects to get Hug'o'Deathed. I
| suppose a site like the one here should expect a higher
| bandwidth around competition and announcement time, but for
| independent people who happen to get picked up on
| HN/Reddit/etc?
| dna_polymerase wrote:
| Sure most websites could easily served as static files on a
| server, but advocating for everything to be hosted on a
| single proprietary service is not a good idea.
|
| But hosting an Apache or nginx to serve static files is easy
| enough and a single $5 or $10 instance on any hosting service
| out there could easily survive a HN frontpage.
| jakear wrote:
| Not advocating for any service in particular (though
| disclaimer I do work at msft), I'm honestly wondering why
| someone would choose to ship a website as a server running
| on a hardware time slot rental with all the setup, cost,
| inscalability, and management that requires, as opposed to
| a free cdn that gives you a website with only some
| markdown.
| lifthrasiir wrote:
| Mainly because it was not a mere markdown. You can't see
| right now, but it had submission forms with previews and
| rating forms. Yes, you can route dynamic parts to
| elsewhere, but it was not really static for a while.
| hombre_fatal wrote:
| > if yes why do you choose not to
|
| Because there's more work in caching your dynamic server/CMS
| to static files and often isn't trivial. And the dynamic-
| rendered CMS is enough 99% of the time. You act like it's
| just a button you press, and you're wondering why people
| don't just press it.
|
| It's also not a money-making venture. So you have very poor
| ROI on making your charity site endure the rare hug of death.
| It goes down? Oh well. It'll come back up. It's also the
| reason you're using some cheap CPanel setup, not deploying to
| a $5 VPS.
| kristopolous wrote:
| Cloudfront & friends are pretty easy and cheap to do.
|
| I was expecting an expensive hassle, but was happy to be
| wrong on that.
| jakear wrote:
| Sure I can understand not migrating existing dynamic
| websites to a static deployment model - don't fix what
| isn't broke. I suppose the question is more about
| greenfield projects, where in my experience writing a
| couple markdown files and pushing them to github and
| checking the "serve this" box is easier than managing a
| server.
|
| > It's also not a money-making venture. So you have very
| poor ROI on making your charity site endure the rare hug of
| death. It goes down? Oh well. It'll come back up.
|
| This is a very strange statement to me. My impression would
| be that if you're running a charity site (or any site that
| makes money from being visited), you would want it to
| absolutely not go down during a hug of death, as that's
| money out of your pocket at a time when it's getting a ton
| of free publicity. Why make the site in the first place if
| you aren't expecting it to provide value to either you or
| the viewer?
| hombre_fatal wrote:
| >where in my experience writing a couple markdown files
| and pushing them to github and checking the "serve this"
| box is easier than managing a server.
|
| Making a site is more than "just some markdown files".
| Can you show me what you're talking about? Maybe I'm
| missing it. If you mean static-site generators (they
| aren't just a couple markdown files), they are very nerdy
| and have pretty bad UX for most people. I don't even use
| them. They are effectively developer-only, for one.
|
| > This is a very strange statement to me.
|
| Well, this is how things work. This goes back to the
| parable of the lumberjack who didn't have time to sharpen
| his axe, or the guy who didn't have time to write a
| shorter letter.
|
| You just want to get something online that others can
| modify. Any additional second your pour into it is
| probably a waste of time. A niche website like JS1024 is
| down? Maybe nobody really cares. Maybe the only person
| willing to host this just does things this way. Oh well.
|
| Edit: Your confusion here reminds me when I got my first
| dev job and was confused why the other developers never
| wanted to improve these obvious problems in the code. Or
| use new patterns. Or learn new things (16+yo VBScript
| app, the website was one 500k line switch statement
| running on IIS). "Doesn't anyone care?!" But as I got
| older, "I can't be fucked" or "cbf" made a lot more sense
| to me. Don't underestimate how often "cbf" answers your
| questions. ;)
| clddd wrote:
| Cloudflare is free, and will take most of the hit if you can
| serve a reasonable amount of it yourself.
|
| Just gotta make sure its setup to cache your html
| SimeVidas wrote:
| The website is loading megabytes of images from its own domain
| without a CDN. R.I.P. web server.
| throwaway_pdp09 wrote:
| It's slow AF because the smallish images are in fact much larger
| but shrunk and many animated on top of that. So far that page has
| pulled 15MB down and is still going.
|
| Edit: up to 24.5MB now.
|
| Edit: 34.5MB now and still going
|
| Edit: 44.4MB and still going. It's clearly slowing down badly.
| I'm killing it.
| flywheel wrote:
| If you enjoy this kind of thing, check out the wizardry/madness
| over at https://www.dwitter.net/ - javascript animations in 140
| bytes (the size of a tweet, hence the name, "dwitter").
___________________________________________________________________
(page generated 2020-08-01 23:00 UTC)