Last few years there has been a huge hype around HTML5 and especially web apps, but what does it really mean to go for HTML5 and build your apps with it? Is it really something that changes everything or is it just a huge hype? This article tries to explain how HTML5 app development differs from traditional web development or native app development. This is not that much about particular technologies, but instead about fundamentals of the approach for building your apps mentioning some key technologies that you need to learn.
Traditional Web Software Development
Traditional web software development expects you to be always connected and your application or web site generates HTML for you with every requests. In many casess where this approach is used, data is simply wrapped into HTML at server side and that HTML is returned to client. Of course this is a bit harsh generalization, but often the workflow looks somewhat like this:
- Choose you server side language and framework, for example: PHP (+ Pear), Python + Twisted or Ruby on Rails.
- Write your server side code that hooks into your data storage, pulls data and wraps it with generated HTML.
- Optimize your code to provide as good as possible caching so that you could avoid code execution as much as possible so that your server will not get overloaded.
Key point to understand is that web sites often generate parts or all of the client code dynamically. This is not always true, but very often and this is a important point that needs to change.
Traditional Native Application Development
When building native apps you usually create either completely self-sufficient, standalone application or application that acts as a client and interacts with server just to get and store data. Other important thing in the nature of native app development is that you build your client side app as a static set of resources (often in the form of native binaries).
Also big difference with native apps is that you need to somehow install your apps into your devices. When using web apps you just point your browser to right address and use that app.
New Generation of Web Apps
What we want is a properly separated code base for client and server, where client side app is a static resource (when looking from server's perspective). As an addition we want the easiness of web apps with point and use approach without the need for installation. With traditional web apps you can more or less reach this combination, but still there are some shortcomings.
When using traditional web apps, you are required you to run your client app inside a browser and this takes away the feeling of running it as an app. Of course this can be tackled with different approaches. For example Apple's Mobile Safari uses special meta-tag to declare web site being an app and GNOME's Epiphany allows user to "install" or mark web site as an web app. With both cases users are given a launcher in system menus or application selector for launching the web app in a chromeless mode where browser runs without any browser menus or other decorations. Still this is not enough, app cannot run in offline mode like native apps. So what more is needed to achieve this?
When it comes to local storage there are basically two different technologies that you need to look into: Web Storage and IndexedDB (sometimes you will run into Web SQL, but it is fading away). When you need very simple key-value storage, you can use Web Storage. If you need something more capable you should look into IndexedDB. Common to both of these is that these are NoSQL data storages and if you are not familiar with NoSQL databases, you should probably get some experience from those.
When it comes to synchronizing your data with multiple clients or between client and server, these databases will not give you much and you need to build synchronization mechanisms your self or use external component to do that. Sometimes your browser might help you a bit like when using Firefox Sync or Google Browser Sync that keep your data in sync between multiple devices. But it is good to remember that these will sync only your browser state and data with matching browsers in your other devices. If you wish to share data between different users or browsers, you need server side sync hooked into local storage to cache parts of the data locally.
Playing Together with Caching and Local Storage
One major reason for this is that, if your client side resources are changed according to request parameters, your caching will become really complicated or you might not be able to cache these at all. If you cannot cache your application properly, you cannot use these apps in offline mode. So remember that your client side resources should be static content and only data is dynamic.
When you build your client side resources as static content it takes quite a lot away from your server load since you do not need to execute that much server side logics to generate your app resources (mostly HTML), this will have really nice impact on your server performance and you might get away with more light weight infrastructure. Other thing to note is that when building your data API (for example providing RESTful API for getting data as JSON), you should timestamps on your data properly. When you do so, you can actually add these timestamps to HTTP headers and allow clients to discover, if data is changed since previous load and abort after getting headers if not and data is already cached. If you do not handle data modification timestamps properly, most of the browsers will use cached version of the data and your client will not see changes as you would expect. Especially mobile browsers and web runtimes are very aggressive when it comes to caching.
If you design your app correctly you can actually access it from your browser just by loading the file from local filesystem and it still works without any connection to the server. This will work only with very simple apps, but frameworks like PhoneGap/Cordova use this approach and allow you to bundle your web app like it is a native app and you can push this app to different app stores. Also PhoneGap/Cordova gives you some additional APIs that expose features that are expected to be part of HTML5, but not yet supported by different web runtimes.
Same Origin Policy
When building more complicated apps and trying to make your apps interact with other apps, one of the tricky parts that probably will cause you some grey hairs is same origin policy that browsers and other web runtimes follow. This policy mandates that you data and app needs to come from same origin (web address: same protocol, host and port). This topic is probably worth of its own article and I will not cover it that deeply, just enough to explain it in high level.
The main point is that when your app is served from one address and you would like to use data from another, your app cannot make request to this other address. Your browser just blocks these requests and tells you that you are trying to break same origin policy. For example if you load your app from local filesystem (just by pointing your browser to index.html in your file system), it cannot interact with your server, because origins are not matching.
Same limitations also applies to local storage, your app cannot see data that is stored from app having different origin. For example if you did store data locally when you previously load the app from the server. Then you try to load same app from different location (for example local file system), you cannot see the data that was stored earlier since origins do not match. When you have different origins, browser simply thinks these are two different apps and these will have different silos.
As I mentioned in the beginning, the main point of this article is to explain in high level what is different and what is not when it come to writing HTML5 apps. If you got my message right, you should think think that writing real HTML5 apps is more like writing native apps and less like traditional approach for writing web sites.
Web App Development Checklist
- In your data API, add HTTP headers to tell when data was changed last time so that caching mechanisms in browsers and web runtimes can recognise, if data is already in the cache. Be careful with this, there are lots of problems when it comes to caching and browsers seem to expect different headers or combination of headers.
- If you store data in client's local storage for offline usage, remember to handle synchronization issues properly. Do not underestimate complexity of this part, this may be quite challenging world.
- Follow the progress of HTML5 standard. It is not ready and it tends to change. Current release plan is to have stable specification in 2014.
Anything else? I probably left out lots of important parts, but let me know if you miss anything special or if I have said anything stupid. If not, I hope you will find this article useful.