6 Comments

Summary:

However much CSS3 matters to Adobe and to the legions of web designers, it’s not an industry-transforming technology. For that, you have to look at the other parts of HTML5 standards that deal with data storage and persistence, specifically: HTML5 webSQL, local storage and cache manifests.

Engineering plans storage, 2001

Engineering plans storage, 2001So far, the talk about HTML5 has focused on whether and when it will “kill Flash.” Because of that, the pretty eye candy that CSS3 provides — complex color gradients, animations, 3-D transformations and more — have received most of the attention. But however much CSS3 matters to Adobe and to the legions of web designers who now have shiny new tools in their box, it’s not an industry-transforming technology.

For that, you have to look at the other parts of HTML5 standards, the ones that deal with data storage and persistence, specifically: HTML5 webSQL, local storage and cache manifests. Essentially, these technologies allow a website to tell your browser to store a local version of your web pages and your data. Once you have a local copy, you can then use the website even when you’re offline.

At first look, this seems like a minor detail. There are plenty of utilities that allow you to save web pages to read offline, and websites already save cookies on your local computer to track your state. But we think that these are different. For one, they’re going to be built into browsers quickly: most smartphone browsers will have them within the next year. Once developers begin designing web applications that can operate completely offline, there could be a whole chain of changes set in motion.

In the extreme case, the software server could simply evaporate, its place taken by a smarter database. From a world of thin clients and fat servers, we could move to a world of fat clients and fat databases.

Could this really happen? We think it could because it’s happened a few times before. From a certain angle, each of the last computing generations has had a pendulum swing from server- to client-side processing.

In the mainframe age, data and application state were stored at the server tier, and the client device was a stateless (and therefore cheap) terminal. But in the client-server era, application logic moved down from the server-side to the end-user workstation. Fat native apps running on expensive workstations stored data and app state and connected directly to server-side databases.

In the web era, we returned to the mainframe model of thin clients and fat servers. This happened for a few reasons. First, the 1990s’ browser was very difficult to use as an app platform: Layout and JavaScript engines were both inefficient and unstable in the broadest sense. Second, UI capabilities were highly limited. But perhaps most important, you couldn’t store much in a cookie, or use anything offline. As a result, the browser became a free, dumb terminal for displaying whatever UI was generated by the server application. Server software makers prospered, and the client side shrank in stature and strategic importance.

But now, HTML5 heralds the return of state and application processing to the client-side device. The fat app server that we’ve needed for the last 15 years to process business logic and build web pages could slim down drastically. It could even disappear into the database.

This is the extreme case, of course. Server software will continue to remain indispensable for complex enterprise applications that have to orchestrate large numbers of services or can’t trust the browser to process application logic securely. But for mainstream business applications, and for a large number of consumer applications, this certainly looks like the future to us.

Michael Mullany VP of products at Sencha. Prior to Sencha, he held product and executive marketing roles at influential Silicon Valley market pioneers Netscape, Loudcloud and VMware.

Photo courtesy of the Seattle Municipal Archives on flickr.

Related content from GigaOM Pro (subscription req’d):

You’re subscribed! If you like, you can update your settings

  1. “Could this really happen? We think it could because it’s happened a few times before. From a certain angle, each of the last computing generations has had a pendulum swing from server- to client-side processing.”

    OMG! An author older than 25 years who can actually remember stuff from thirty years ago!!! Oh, right, you’re a guest author. For a minute there I thought Om had hired someone older than himself. Whew! That would have been a game changer.

  2. More like this transition is from network databases to client-side databases. The bulk of computing is still happening on severs, with the final transformations and chashing (sp?) of data happening on the client side.

    Right now, HTML5 while becoming a solution, is a security nightmare waiting to happen because web browsers as they are presently constructed don’t secure local databases by anything more than obscuring them in temp folders (re: the success of spyware and malware). Before these grand visions are realized, this needs to be addressed, and in a uniform manner across of the browser engines available (Webkit, Presto, Gecko, and Trident are the major ones).

    Also, HTML5 disintegrates the traditional idea of the browser into simply a container for a specific type of content. See what Nokia and Apple have done in respect to the help documentation on their mobile devices. It is simply a specialized and compiled set of HTML docs with a specific browser wrapper. This is one part of the future that HTML apps can bring, but again, needs more than just processing data on the device.

  3. Yes, and it’s inevitabe. Users don’t want round-trips for every function an application performs. This is what made client/server popular in the early 90s – together withthe freedom RAD tools provided (like Visual Basic).
    What killed that model on the internet was the problem of deployment and managing local machines. The client/server model just wouldn’t scale to the internet. HTML came to the rescue but wound the clock back to technology more similar to telnet and VT100 teminals of the late 70s.

    HTML5, Flash and Silverlight solve a lot of those deployment problems. It makes sense to use that local CPU power to do functions that don’t need to be centralized. The problem with HTML5 and CSS3 is that it’s not the best application platform. Looking beyond HTML5 and with app stores, hopefully that will be solved. Plus with standardization around data access (OData and GData) we will see a much more federated processing model.

  4. I’m curious, which ‘fat’ database system out there can handle the number of concurrent connections necessary to support a fat-client without any server backend?

    NoSQL hype aside, I don’t know of any RDBMS that can handle such loads, considering the overhead each connection carries. Remove the traditional server layer, with its caching and pipelining of requests, and you get a fat-client with a DBMS that seizes up.

  5. AuthorsPersonalThoughts Monday, September 27, 2010

    Oyywriter don’t kill off flash yet. Let’s wait and see how html5 renders the same things flash does. It’ll be slower. Just wait,,,

  6. If we will end up with only ‘fat’ client AND ‘fat’ databases, what happens to agility? I know of some products that can do this (Microsoft SQL with integration services and of course the ‘fat’ Oracle database with lots of stored procedures). However, this will only mean that web techniques are integrated in DB products. I assume the HTLM5 resources are still distributed using HTTP and that there is some businesslogic applied to the data. In the 90’s (yes, I was already around back then) we discovered that GUI developers (analogue tot HTML5 developers) could not be trusted with security and businesslogic. Which was fair since the were and still are very good in developing flashy and efficient GUI’s. So what we’re saying here is either, the DB specialists will go without their jobs, the business people will start developing applications (BPEL + tooling) or de AppServer developers wil start designing databases?
    This could be, however this would require a major leap in tooling and System Software (COTS) capabilities.

Comments have been disabled for this post