I've spent over a 100 hours this year to revamp the site and prepare for 2015. I didn't actually anticipate it to take that long but I'm quite happy with the results. I had typed this up before the competition started but hardware problems and busy life lead me to forget about posting this. So here you go anyways.
So, what did I change?
- Revamped whole site
- Demos in a new iframe template
- Demos now working in IE/Safari/mobile
- Fixed many demos broken due to updated apis/for-in
- Added reload button to restart a demo without reloading the page
- Reload button also fixes audio under iOS
- Fix was totally intentional
- Site completely regeneratable in backend
- Revamped details pages
- Synced up front and rule pages of old compos
- Added support for more social links (github, facebook, gplus, pouet)
- Added support for a post mortem link
- Added form to update meta data of existing demos
- Added short links to demos (js1k.com/XXXX)
- Added logo mods for old compos (thanks @feiss)
- Sprited images in old compos that weren't doing that yet
- Reduced sprite quality to drop size (1mb -> 300k for first compo..)
- Simplified top of non-demo pages (global tagline, compo tagline)
- Made demo headers more SEO friendly
- I hope
- All pages in all compos use same stylesheet
- Put the mailing list link everywhere for better exposure
- Made about page more in line with other pages
- The whole site is a template now (most pages were already)
- Improved "templating engine" *cough* ok, hacks.
- Built the 2015 site
- Found four 2015 jury members
- Finalized the rules for 2015
- Finalized the shim for 2015
- Merged regular with webgl shim
- Simplified the shim even further
- Submission form has inline-demo options for size and shim type
- Normalized some more vendor prefixed API classes/methods
- Asked some people to create invite demos to create some buzz
So about them rules. Let me try to clarify that a little.
Generally, I'm trying apply them to the spirit of JS1k. That means no externals, everything should fit in 1024 bytes or less and the submission should be JS and run in a script tag.
This year I'm going to experiment with allowing external input from webcams and microphones (getUserMedia). I'm going to be vigilant about abuse here, but I feel it should be okay if this was an extra functionality of a demo as long as it did not depend on it. I'm still explicitly disallowing external or local files, any kind of network connection, and local storage.
For the sake of site maintenance and performance I'm disallowing demos that reload the page. If you want to restart your demo you can call top.reload(). It's about as many bytes as it would take you to reload the page but a lot cleaner. I may make an option to have that reload bound to the r key next year.
I think it's too early for ES6 so I've disallowed that. I think it'll be okay next year though. That'll lead to some interesting minification and other feats I'm sure.
I know it's too early for webVR demos. I would love to see them though but since that's a personal preference I cannot allow them to compete for prizes. They'd win them anyways ;) We'll have to see how the whole scene evolves before deciding wherther it'll ever be in.
I will allow WebGL to compete. Last year showed that, yes you can do WebGL demos but your options will be limited.
I'm considering the 2k compo experiment to have failed. Yes there were a handful of demos but that's just it, too much effort for too little gains. I think people agree that 1k ought to be enough for anybody ;)
As far as the shim goes, it's pretty similar to past years. The main difference would be the configurability of width/height and the canvas-shim-type. Let me explain why I did that.
The canvas shim is pretty simple; For the sake of site maintenance I just want one shim. They fit together pretty well and there's no real reason to have two different shims. Before I exposed a d variable which was a function that would wipe the document to get rid of the boilerplate canvas element. This year I've decided to make that part configurable at submit instead. This means people that want to do an html demo won't need to call d() anymore, so basically no penalty for them. The second option is a 2d canvas, which simply creates and exposes the canvas (a) and 2d context (c). The third option is a WebGL canvas, which exposes the context as g and runs some basic WebGL initialization code (same as last year).
The other configurable is the size of the canvas. Last year I've tried making the canvas auto-resize to fullscreen. While updating the demos I realized this was a small mistake on my part; most demos won't/can't bother to update their internally cached canvas size after a refrehs. And I don't blame them. The canvas size affects so many things so it was kind of silly of me to expect demo's to be able to take that into account. So this year I'll do it differently. Nore more auto-resizing code. Instead you can submit the maximum size of the canvas. Some demos are very graphics heavy and limiting their canvas size will help in performance. You can basically choose between an explicit max size in pixels or just 100%.
Another thing to configure is whether you want your demo to restart when an onorientationchange event is fired. This is for mobile, of course, and after the change the dimensions will have changed. So sometimes it makes sense to want to restart the demo to make use of the new dimensions.
I still want to add a fullscreen button to the header to use the Fullscreen API, but due to a silly API choice that's proving a bit more work than anticipated. (The problem is that the method call doesn't return anything, no promise, no status code, no nothing, and the only way to know whether it worked at all is waiting for an arbitrary event to be fired. So if it failed, when do you give up? This mechanic is way too loosely coupled in my opinion. The method should accept a callback to be called when the element is rendered fullscreen, or if that failed. The method could return a promise with the same actions.) I'll check it out later but for now I have other things on my mind.
Similarly I wanted to add an enable sound button for iOS. But you'll have to make do with pushing the reload button for sound. The reason the reload button works is that if a demo uses sound, the reload button is a user event and iOS will only unmute audio once audio was used in a user event. (hint: Pressing the reload button is a user event ;))
At the time of posting the competition has about a week and a half left. There's already some awesome demos in there but I really hope we can at least double them ;) Looking forward to more either way!