Live data from Hacker News

JS1024 Results – 1k JavaScript Demos

js1024.fun

21–30 of 45 posts

Re: JS1024 Results – 1k JavaScript Demos

#21
post #11

Earlier quoted context omitted.

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

> 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 do…

Cloudfront & friends are pretty easy and cheap to do.

I was expecting an expensive hassle, but was happy to be wrong on that.

Re: JS1024 Results – 1k JavaScript Demos

#22
post #11
post #5

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!

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

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

Re: JS1024 Results – 1k JavaScript Demos

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

Re: JS1024 Results – 1k JavaScript Demos

#24
post #11
post #5

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!

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

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 34ᵗʰ place, a 1000×1000 PNG of a fractal being shown at 400×400), 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.

Re: JS1024 Results – 1k JavaScript Demos

#25
post #11

Earlier quoted context omitted.

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

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 treatmen…

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.

Re: JS1024 Results – 1k JavaScript Demos

#26
“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(n²) 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 6× as fast and power consumption 30× 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.

Re: JS1024 Results – 1k JavaScript Demos

#27

“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 becaus…

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

Re: JS1024 Results – 1k JavaScript Demos

#29

“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 becaus…

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.

Post reply on HN