Quantcast
Channel: DeepElement » HTML5
Viewing all articles
Browse latest Browse all 6

HTML5: A Call to Software Architects

$
0
0

The Word is Out about HTML5

If you are a nerd, this is not anything new. We have been seeing little bits and specs of the api slowly dropping in over the last few years. Some of us have even been daring enough to mention the features to our clients, to then recall with “Not yet supported reliably across major customer environments”. But recently, given the real progress in the spec implementations, I have noticed that clients in almost every industry are asking about HTML5 and what it can do for their businesses by their own direction. To clients, “HTML5″ means they can now build rich applications that excerpt the many eccentric behaviors of a full-fledged client-framework at the low low price of a few web developers. This is being initiated by the big guns (Google, Microsoft, Mozilla, Apple) over-publicizing the technologies so their browsers can get market share before the big shift. Why is this a problem?

Almost all of the javascript online today was written, tested and proven solid in a world of constant refreshes

This means that a majority of developers, responsible for existing client-side web patterns, are not prepared for the shift… Even worse, it means that technical architects must rely on a wave of ‘reinvention’ of major libraries, frameworks and ideas in order to pull off the browser-driven marketing need.  

The “New Web Order” Laws

Based on my experience working with clients on large-scale HTML5 Applications, here are the golden rules I bring to my teams:

Online is Offline

  • Decouple Data “Consumers” from Data “Sources”
  • Cache Everything
  • Manage the User-Experience such that offline feels identical to online

Build Real Business Layers

  • Design Strong Classes, Not Modules – see Building Strong Types
  • Separate Model and Behavior
  • Use Inheritance and Polymorphism
  • Create life-cycles for Objects
  • Employ Factories, Strategies and all of the proven methods of Domain Driven Design

Be the Memory Manager

  • Separate Domain Objects from the Visual Tree
  • Track all Object Lifetimes
  • Dispose Javascript Objects using Delete and Null – see Snagging Javascript Memory Leaks
  • Do not expect browsers Garbage Collection implementations to unravel your mess

Expect Exploitation

  • Build Applications with the Expectation that All data can be sniffed
  • Expect other processes to dig in your memory state
  • Realize that even Obfuscated code is open


Viewing all articles
Browse latest Browse all 6

Trending Articles