HTML5 applications that run (almost) forever

Twitter: @jeremypullen

Credits

Aaron Gascoigne

Paritosh Vemparala

Nandan Jain

Steve Nissen

Challenges

Practices - foreign to most web developers

Platforms - maturing but not quite there yet

Libraries - completely clueless

Tools - focused on spot debugging

Strategies for handling JavaScript bugs

Fix them (duh) - Brute force

You’ll miss some bugs (duh) - Resilient application architecture(s)

Typical JavaScript bugs

DOM leaks

Timer storms

Dangling callbacks

Exceptions

Beware of your libraries!

Timer storm example

Brute force debugging techniques

DOM leaks - Walk DOM tree, dump # to console

Timer storms - Wrap all timer calls with helpers you can instrument later

Dangling callbacks - Wrapper for all callbacks

Exceptions - window.onerror(), automatic iframe reset

Resilient Application Architecture

Break large apps (50K lines of code) into a number of small micro-apps

Run each micro app only when needed

Pick a sandboxing architecture (native, HTML5)

Resilient Native Application Architecture

Native Platform Application Management

Separate web context with web intents for communication

Automatically kills an app that is misbehaving

CPU hog

Memory hog

Automatically restart an app that is mission-critical

App prioritization

Sand-boxing

Process separation

Storage separation (cookies, IndexDB, web storage)

Native Platform Application Management – Limitations

Not always available

No help for problems in big apps (173K lines of JavaScript)

Resilient HTML5 Application Architecture

iframe sandbox overview

HTML5 Rocks!

Designed to protect you from others...but why not from yourself?

Negligible memory impact (Chrome about:memory)

Also used for secure data sandboxing: Devdatta Akhawe

Pattern #1: iframe bootstrap

Okay to restart whole app

Native app framework does not support automatic restart

Pattern #1: iframe bootstrap

Small amount of management code in root page

Whole app wrapped in iframe

Delete / re-create iframe on a schedule (daily), during idle time, or when app misbehavior detected

iFrame bootstrap example  

<script>
  function createFrame()
  {
      var f = document.createElement("iframe");
      f.name = "myapp";
      f.id = "myapp";
      f.sandbox = "allow-scripts allow-forms allow-same-origin";
      f.src = "myapp.html";
      var d = document.getElementById("app-div");
      d.appendChild(f);
  }
  function removeFrame(frame)
  {
      var node = document.getElementById(frame);
      node.parentNode.removeChild(node);
  }
</script><div id="app-div"></div>

Pattern #2: Multiple iframe sandboxes

Not okay to restart whole app

Very large apps

High data / network usage on start-up

More resilient user experience

Seamless recovery from bugs with only minor user disruption

More complex

More restrictions

Pattern #2: Multiple iframe sandboxes

Core management logic in root page

Segment different parts of your app into "micro-apps"

Each micro-app wrapped in iframe

Communication between root page and micro-apps via postMessage()

Most micro-apps started / stopped on-demand

Some micro-apps run longer – restart when misbehavior detected

Pattern #2: Multiple iframe sandboxes - limitations

Duplicate files loaded into each iframe

Extra work to proxy communication across iframe boundaries

PureMVC iFrameMediator

With a little work your libraries can be iframe sandbox friendly!

Credits: Aaron Gascoigne

iframe example: basic usage

Conclusions

Test the heck out of your apps

Watch out for the key bugs

Break large apps into micro-apps

Manage app / micro-app lifetime

Use native app sandboxes and/or iframe sandboxes

Modify your frameworks to be iframe sandbox friendly

Q & A

Code on GitHub

https://github.com/jpullen/html5-hardened