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).
Matching this approach with HTML content is very much possible, just not too often used. You can write your HTML, Javascript, CSS and other resources as static content and use AJAX requests to populate your UI from returned data. This approach makes your web app development closely match with native app development.
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?
HTML5 introduces two important features: Application Cache and Local Storage. As you might guess from the names, Application Cache is for storing your app specific client side resources for offline use (HTML, Javascript, CSS and graphics). As for Local Storage allows you to store data for offline use. Also File API might be worth of mentioning here, it allows you to interact with file system outside your browser environment.
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
Earlier I claimed that it is old fashioned to generate your HTML at server side and you should move towards design where your HTML, Javascript and CSS are just static content and server's role is more about serving data and of course serve these static resources.
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.
What you can and cannot do? You can load Javascript file from other origin, but you cannot make AJAX (XMLHttpRequest) to pull data from another origin. There are two main approaches to go around this limitation: CORS and JSONP. CORS (Cross-Origin Resource Sharing) allows server and client to negotiate what origins are additional allowed. If CORS is not possible approach, you can use JSONP, where you basically misuse the fact that Javascript resources can be load from any origin. With JSONP you just wrap your data into a Javascript function that returns your data. Then load that resource into a script-tag and call your function to get your data. Basically you can return any kind of data with this, but as name suggest usually you are expected to return JSON blob.
Summary
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.
One thing I have to say is that moving towards HTML5 does not make you application development easier and you will be a fool if you think that development will be more simple since almost anyone can write HTML5 apps. The thing is quite opposite, writing good HTML5 apps requires much better separation of data and representation than web world is used to. On the other hand, programming with Javascript is requires you to think everything with asynchronicity in mind and also writing good Javascript code requires something that software developers and engineers are not famous for: discipline. Combined with the fact that there are no good tools, this is not a easy world. Though I have to say, it is surprisingly interesting one.
Web App Development Checklist
- Do not generate HTML, Javascript or CSS at server side, unless you have some really good reasons.
- Use your server logics only to serve static content and data. Preferably serve your data as JSON since it works together with Javascript so well.
- 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.
