With the advent of new browsers such as Safari 4 we’re now also starting to see HTML 5. HTML 5 brings a number of things to the plate, one of the biggest things being client side databases. In addition to this, excellent JavaScript libraries such as jQuery are really making headway, making client side DOM manipulation a jingle.
JavaScript engines too are getting huge speed boosts with the latest browsers. In fact, all the latest browsers from IE to Safari are all pimping their own “awesome” and super fast JavaScript engines. There is alot of focus here, rightly so as web development quickly moves towards Rich Internet Applications (RIA).
Client-side databases
Of course, this isn’t new. Google Gears has been offering a browser plugin for server side databases for quite some time now. The trouble is, it’s a plugin. It’s not native, and requires action from the end user to install.
The great thing about it though, is that you can effectively offload a bunch of data over to the client, and get your application to query it from there, instead of your server. It also means that offline web application usage is even more of a reality as in theory, the app no longer needs to query a web server for it’s data.
Architecture and Functionality
So what does this all mean? Why should we be thinking different? Simply, this changes everything.
Think about it. You’ve got a bunch of servers, your database servers are the crux of it all, and they struggle under heavy usage due to the number of queries going on. What we should be proposing is offloading some of the database work onto the client.
What you have to remember is, a large proportion of your users are probably using a PC that is extremely powerful. Upto now, web technologies haven’t really been pushing client machines (other than the unruley flash). So why not utilise some of that power yourself, offload some of the processing of data from your servers and onto the client.
Of course, this isn’t as simple as it sounds. We have a few issues.
- Bandwidth. We would assume that a user had the broadband capabilty to download large chunks of data quickly.
- PC Performance. We would have to assume that all users have a fairly decent processor.
- Browser Compatibility. None of this is mandated yet. HTML 5 is nowhere in IE8, so until it’s common place in browsers, it’s a difficult project to get underway.
That said, think of the future. Think of client side databases holding a subset of data that can be queried and manipulated in split seconds by awesome JavaScript engines within browsers. Database servers can be freed up for more important duties, even the application layer to a degree. Anyone with a major server architecture can clearly see some great wins here, if only everyone could catch up.
Similar Articles:
Authenticating Twitter API calls with PHP & jQuery
Recovery.gov uses jQuery on Drupal
6 jQuery Chart Plugins For Your App
10 Questions for Jörn Zaefferer
10 Excellent ToolTip Plugins with jQuery









“…Database servers can be freed up for more important duties, even the application layer to a degree. … ” Will not that lead to ultimaltely blurring the difference between application and presentation layers ?? So ultimately we are returning to the 2-layer apps of foxpro days only this time the distribution of the heavy client side is through browser , there i guess will be some obvous concerns about security as well , other than overloading of browser engines that are notoriously easy to get wrong