onGameStart strikes back!

It's already kind of tradition that September is HTML5 Gamedev month in Europe. Since 2011, when first onGameStart took place, we've hosted events for more than 900 game developers, designers as well as business and marketing teams. With more than 60 talks, 25 hours of workshops and 1200 liters of alcohol during the parties (so far), onGameStart is the most important web gaming event in the world. This year (September 18-20) we will try to push it even further. We have just updated our website, and announced new speakers in our lineup. This year's edition is a unique opportunity to meet big names from the industry, like:

• Mrdoob - creator of the most popular WebGL framework, THREEJS.
• Collin Hover - author of Kaiopua engine and our last website (onGameStartUS). If you never heard of him - check his talk from the last oGS.
• Rémi Papillié - from Ubisoft, will teach us about console game dev tricks that could be useful in WebGL games
• Ivan Popelyshev - creator of Bombermine, the game that was in Top10 of HTML5 games in 2012 on NetMag. He will share his secrets about developing MMO game with canvas & Websockets
• Jasmine Kent - formerly worked for Sega, author of Trigger Rally, a WebGL racing game
• Jan Krutisch - will make some noise with Web Audio API (finally!)
• Yuri Dobronravin - will teach us how to run our HTML5 games with native-like performance on Windows Phone and Android, like he did with his Cannons & Soldiers
• and others, check our agenda

Besides the conference, on the day before we organize fullday workshops in small groups (up to 10 persons). This year you'll be able to learn how to create a 3D game using PlayCanvas (check Will Eastcott's Playcanvas presentation from last year if you never heard of it before) and how to create game graphics (and outstanding skeletal animation with tool called Spine!) if you have no artistic skills together with onGameStart veteran, Robert Podgórski.
If you still haven't decided if you want to attend, check videos from previous onGameStarts:
2011:

2012:

And all the talks in here: 2011, 2012+oGSUS.

For more details visit our site, Facebook, Twiter and Lanyrd. See you there!

JavaScript: The less known parts. DOM Mutations.

'JavaScript: The less known parts' chapters:
1. Bitwise Operators
2. Storage
3. Dom Mutations

At the beginning of last May, so not even a year ago, there was quite a buzz around a blogpost by David Walsh about detecting DOM Node insertions with JavaScript and CSS Animations. In the article, David explained that even if Mutation Events are deprecated, we are not powerless in detecting DOM modifications in our JavaScript code - using simple hack (and since we are web developers, we love hacks and we use tons of them every day), we can attach very short (0.001s in the given example) animation to every element that will be added to to DOM Tree, and then listen to the animationstart event. The animation will be to short to notice it, so the event will fire almost immediately after DOM modification. Full post is still online, you can find it in here - Detect DOM Node Insertions with JavaScript and CSS Animations. Great, but is it the only way to detect node changes in JavaScript? Fortunately - it's not. Say hello to the MutationObserver.

About three days after David's article, Jeff Griffiths presented MutationObserver on MozHacks in an article called DOM MutationObserver – reacting to DOM changes without killing browser performance. In just a few words, MutationObserver provides developers a way to react to changes in a DOM. It is designed as a replacement for Mutation Events defined in the DOM3 Events specification. It's way simpler and more efficient to use native browser's API than hundreds of hacks - we are creating more dynamic webapps all the time, so it seems natural that we would welcome the ability to listen for changes in the DOM and react to them.

Below, I've reimplemented the demo from David's blogpost from CSS Animations to MutationObserver. You can find the original example here: Detect code insertion.

Unfortunately, MutationObserver is still a fresh feature, and it isn't supported everywhere - we can use it in only in Chrome (Desktop) & Firefox (Desktop & Android) so far:

MutationObserver resources

DOM Mutation Observers & The Mutation Summary Library
Mutation Summary
MutationObserver on MDN
MutationObserver DOM4 Spec
Detect DOM changes with Mutation Observers - HTML5Rocks
DOM MutationObserver – reacting to DOM changes without killing browser performance.

Do you find this kind of API useful? Do you know any other hacks related to DOM manipulation listeners? Comment here or catch me on Twitter (@michalbe).

JavaScript: The less known parts. Storage.

'JavaScript: The less known parts' chapters:
1. Bitwise Operators
2. Storage
3. Dom Mutations

Client side storage is almost as old as Internet itself. Back in the days we used cookies for this, but since Firefox 2 & Safari 4 browsers support DOM Storage techniques. We are probably all familiar with IndexedDB or deprecated WebSQL. Both of them are widely supported in almost all of the newest browsers:

localStorage

Thats not all - we also have well known localStorage & sessionStorage key/value client storage system. We can simply save the value in one window:
And load it in another:

The advantage of local/session storage over IndexedDB is that we can listen to an event that fires when something has changed - we can for instance propagate those changes to all the browser cards or iframes in our application. Choose the 'result' tab in the next fiddle, go back to the first one and save something using the form.
It's helpful also in IndexedDB based apps - for example PouchDB made by Dale Harvey use localStorage events with IndexedDB data to keep everything up to date everywhere.

window.name storage

We can also use window.name property to store data on the client side. This ancient method allows us to read and write data across pages and domains, even from outside the current origin. According to Wikipedia [HTTP COOKIE] we can store up to 32MB there (according to some sources its even around 60MB). It's also accessible even before domready event. And even if it's not really cleaver idea in times of tabbed browsing (every new tab starts with empty window.name), it's still used as a fallback in for older browsers. More on window.name storage:
Ajaxian: What’s in a window.name?
Cookie-less Session Variables in JavaScript
Session variables without cookies
HTML5 sessionStorage for "every" browsers

See you next Monday in the 3rd part of Javascript: The less known parts. Follow me on Twitter and stay informed about next parts!

My TV Shows list

I've updated the list of all the TV Shows I've watched since February 2008. So far it's 48 shows, 3295 episodes in total, what gives 1854 hours and 12 minutes (around 77 full days and nights). If you know anything I should watch, and it's not on a list (or 'Shows to consider' list), please fork my repo and update my proposals. You can also vote for other series in the 'proposals' part.

Github repo: michalbe/tv-series
Rendered list: gh-pages/tv-series