The event as a whole was excellent – some great sessions and a strong focus on using HTML5 for mobile apps. Facebook’s new graph API, for example, encourages developers to think about how to semantically describe users’ contextualized activities (how many sedentary web users do you see in this video?). All part of an exciting mobile future for the web’s next decade.

Team Sencha was probably rather too ambitious. But after several frantic hours, we managed something that more or less worked.

Our app was to be BaconOff, a two player game to match actors from your Facebook-liked movies against each other based on their Bacon Number, Top-Trumps-style. The server-side, node.js, hosted and deployed easily to Heroku, and which handles the Facebook authentication, delivers a Sencha Touch app, containing an access token, to the browser. (No doubts at all this can be more elegant and secure).

The first thing the app does is pull a list of your favorite movies from Facebook. Once loaded, each movie record calls imdbapi.com, a wrapper around IMDB’s database, and fetches four actors from each of your favorite movies.

Those actors are then created as a further type of model, each of which has a bacon-number-fetching method. We hoped to use YQL to get the values from Oracle of Bacon, but it was barred by a robots.txt condition. Slightly cheekily, we used our node backend to proxy a request to that server anyway, and then handle the common condition of there being more than one entry for each actor’s name.

In the meantime, and no thanks to me, we had a sweet UI and CSS3-animated loading screen – all Sass goodness from Mr Kaneda of course.

We’d hoped to avoid having state stored anywhere on the server or in the client, using the social graph alone. Eventually we figured it was unavoidable, and quickly had to write a game state storage layer on the server side. It uses a contemporary storage platform known as… the file system. Ahem.

From here on, with time running out, and with a flying visit required to my son’s (excellent!) school play on the other side of El Camino, code started sprawling as we dashed for something demonstrable.

APIs for starting, listing, and playing games quickly followed, and views on the client side emerged to allow competitor and actor selection, as well as the game’s home screen.

We added the Facebook JavaScript library relatively late in the day to allow competitor selection and request; (in retrospect we should have based the whole app around this library from the start – what were we thinking?). And then tried, and failed, to make the frictionless sharing of the game progress post to the timeline: I just couldn’t find the relevant permissions settings in the last 30 seconds before we went on stage. This was a shame, because we’d had the nouns and verbs configured ages before!

At somewhere approaching 1am, we finally got to demo the app, and for those two minutes it more or less worked. There was only one hack required to make the walkthrough work: I’d been working on the assumption that players would be keyed by name, while Dave (and, it turns out, Facebook) that they would be keyed by ID. A small hardcoded line covered that up – albeit at the expense of making every game ever appear to be against Dave himself. With that in mind, I’ll decline to link to a live running version. Screenshots only

So yes, in retrospect, far too ambitious. Hacking time was supposedly limited to 6 hours, and we’d needed a few more than that. I rather wish now that we’d just done a Social Compass app and stuck some avatars on top of a simple webkitCompassHeading event handler or something. We weren’t expecting to win anything (there’s no doubt the well-prepared entries were far superior ) – and let’s just say that this was an expectation firmly met.

But it was a lot of fun being on the other side of the stage for once. And it’s interesting to see how far you can get on something completely new in a short time period if you put your mind to it. I guess that’s the whole point; code quality be damned…

But does an established distinction exist between the two genres of experience? Not as far as I know. Is it to do with creation versus consumption? Linkability? User experience? Or the architecture underlying the way they are built?

Personally I think there is a way to clearly delineate the two types of experience, but I’m also sure it’s not the only way to do so, and that the distinctions are very likely to vary with individual’s perspective. I’m unabashedly trawling for debate.

<tldr>

There’s one notable result of the disruption that mobile is wreaking upon the way we think about the web. The blogosphere, the conference circuit and various online communities – not to mention boardrooms up and down the country – are abuzz with hypotheses regarding the “One True Way” to do something, the “Dawn of” this, or the “Death of” that.

No doubt I’m a part of this. It’s quite fun. (Although let’s be honest, none of us really has a clue about how mobile’s going to play out eventually.)

In the real world, such binary proclamations are less useful than we like to think. Building mobile and web experiences for real users, real business – and with real constraints of many kinds – is not at all easy. Being buffeted around by voguish black-and-white philosophies (or even the outmoded ones) is of reduced benefit when you’re really trying to navigate the shades of gray in between.

One of the shadiest boundaries to have to consider when using web technologies is that netherworld that lies between ‘web application’ and ‘web site’. As far as I can tell, there aren’t established definitions that help us decide what is one and what is another – let alone a decision tree that developers and designers can follow to decide what sort of experience they should deliver to their users in different circumstances.

On one hand, the differentiation between these two things seems rather academic. If a user can access what I want them to access, and can do what I want them to be able to do, then who cares how we label that experience? It’s the web right? (Stop reading now.)

But again, this belies the subtlety of the real world, and especially in mobile. It’s 2011: iPhone-plus-four. Users want apps. Marketers want apps. Boardrooms want apps. This is, we’ve been trained to believe, the way in which we enhance our phones’ capabilities and access information in elegant, consistent ways. We can assert as much as we want that users should only be using their devices’ web browsers, but apps sell, and will continue to.

Of course, many of these apps are written with native technologies, and distributed via non-web-based stores. This article is not about them: they are likely to become evolutionary dead-ends. But if the web is to succeed as a distribution medium – and as a stack of technology – it will have to rise to match the expectation that’s been set. It will have to provide what is needed to create and deliver app-like experiences, just as well as it can classical site- and document-based content.

The good news is that smarter people than me have long seen this coming. Although much of HTML5 (the markup specification) is about improving the semantic qualities of web documents, HTML5 (the suite of related APIs and technologies) is unashamedly focussed on enabling web applications of increasing complexity. And with browser vendors now competing on such metrics as JavaScript performance and API completeness (rather than how well they support the <aside> tag or somesuch), it seems we should expect to see ever more advanced web apps in the future.

Nevertheless, in frequent discussions about the mobile web, its best practices, and its tools, you’ll hear many arguments qualified with clauses like “oh, but things are different if you’re building an app” or “this is a better technique for traditional sites”. I know, because I do too.

And so, as we enter conference season again, I thought it might be interesting to see if there’s any consensus about what these two things even are, and how we can differentiate between them. What is a mobile web app? And when is it not a mobile web site?

For me, there are a few possible vectors that we can consider.

Creation versus Consumption

Imagine a large structured collection of interlinked documents, where the user is essentially limited to a read-only interaction (give or take the odd comment form or search box). There’s no doubt that such a thing should be classified as a site. Blogs, news sites, academic papers – these are clearly the heartland of the classical web. Online stores too? Probably.

But what about micro-blogging services? Photo-sharing? Online email clients, document editors, IDEs even? Games? It seems debatable as to whether one should classify twitter.com as a site or an app (especially on a mobile device), but I am most certainly using an application when I’m logged into GMail, Google Docs, or playing Angry Birds – let alone working in some web-based data admin interface.

Interestingly, this second category of experiences all seem to be read-write (or at least, highly interactional). So can we classify sites as being read-only and apps as being read-write? That certainly seems simple enough: sites are to consumption as apps are to creation.

Does this feel right? One problem here is that there are some beautiful and enjoyable app-like experiences – Flipboard comes to mind – which are clearly oriented towards consumption. (But then again, maybe the logic is backwards here… perhaps Flipboard is what the web site of the future should look like, though Gawker’s infamous app-like blog felt clunky). And how would you classify Facebook? Entirely user-generated content, but it still looks and feels quite like a site.

Linkability

If you are launching an experience from a desktop or homescreen icon, it is easy to feel that you are in a sandboxed and closed environment whose boundaries are explicit and inescapable. If you start your experience by entering a URL into a browser, conversely, you’re more likely to feel that you are at the start of journey – one where every link clicked can immediately take you to another page or another site or another domain, across the web’s endless interlinked landscape with no boundaries.

So does this serve as a way to distinguish between site and app? Most native apps certainly do have impermeable boundaries: outbound and especially inbound. Even the iPhone Twitter app opens up links in a modal, embedded web view rather than spawning a new Safari window (much to my frustration, at least).

But web apps? Need these be silos? No, of course not. They’re still running in a browser, and (unless in hybrid environment) hanging off a URL like any web site does. There’s no reason for a web app not to contain links that lead you off to other parts of the web, either in new browser tabs or the present one. While reliable deep-linking back into web apps seems to be less commonplace, this is more a function of implementations and browser’s fragmented History APIs than some fundamental flaw in the web’s architecture. (I never shared purists’ distaste of hash-bangs, for example. These are a symptom of developers trying to make this inbound linkability and bookmarkability work for single-page web apps: fixing the web, not breaking it.)

So, like others, I’d definitely hold up linkability as a huge advantage of web apps over native apps – but not as a reliable way to distinguish between web apps and web sites.

User Experience

Another way we might classify apps and sites is by assessing the user interface and experience presented. What are the visual cues that an app’s an app, and a site’s a site?

The use of fixed toolbars is certainly an obvious one: at the top, containing a title and maybe a back button; at the bottom a series of large tab-navigating buttons within easy thumb-reach. This is a UI/UX paradigm that, pioneered by iOS, emerged entirely from the native application world, and which, before 2007, had absolutely no precedent in the classical or mobile web worlds.

Ditto disclosure lists. Ditto sliding transitions between master and detail records. Ditto action sheets, spinners, and momentum-based scrolling. Ditto even the disablement of pinch & zoom on document-like content (controversial to some, and yet understandable if you argue that viewport zooming was merely the browser’s way of dealing with legacy, not-made-for-mobile web content in the first place).

Many developers work hard to bring these platform behaviors in their web apps. And many web frameworks work hard to make it easy for them to do so. (My employer is one of those, of course.) Many rightly blanche at the thought of slavishly mimicking a particular operating system – nothing looks dafter than iOS pinstripes in an Android browser – but the point is that many of these generalized UX characteristics are highly suitable for one-handed, touch-based interactions. No-one will claim that legacy desktop web sites (often replete with tiny mouse-centric sidebar menus and table layouts) can ever match a dedicated app-like user experience. Responsive web sites can indeed improve this greatly, with navigation often flowing to the top or bottom of documents for certain screen sizes. But still, these sites are rarely mistaken for apps.

Because the visual appearance is the “I somehow just know this is an app” argument, and one that users might particularly relate to, I do give the UI/UX distinction a lot of credence. But still, it’s a very fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list looks like hyperlinks instead of tappable disclosures? What if I style plain scrolling instead of momentum? This is a question that the likes of jQuery Mobile have pondered too, in an attempt to follow a site-like, progressive enhancement philosophy. Nevertheless plenty of developers are undoubtedly going to describe the results as apps.

Architecture

So this leaves us looking for a more technical distinction. Is there an architectural, boxes-and-arrows argument that might clarify the difference?

The web we’ve known and loved for almost 20 years – undoubtedly a web of sites! – is unashamedly thin-client in design. Web servers do all the heavy lifting, hosting the storage, business logic, and the construction of the user interface that the user sees. Indeed it is surprising that we’ve had to suffer so much browser inconsistency over the years considering that all they’ve had to do is turn a stream of < and > into pixels.

But the rise of the use of AJAX was a clue that this architecture wasn’t always particularly elegant. A user clicks a link to another page on your site? That might mean a whole set of HTTP connections (again), a blocked server thread (again), a clutch of database connections (again), the execution of a bunch of business logic (again), the generation of a whole new slab of markup (again), and its dispatch back across the wire (again). And that’s all before expecting the browser to re-render the entire user interface (again).

I love URLs, hyperlinks and SEO as much as the next man, but that’s some price to pay to simply display a new record of content.

On the other hand, consider an architecture in which the browser is given far more autonomy and responsibility. Think “AJAX++”, perhaps, where not only fragments of the DOM are elegantly updated, but where the entire application can reside and execute in the browser.

The big breakthrough here, of course, has been HTML5′s storage APIs, which allow JavaScript in the browser’s environment to persist reasonable amounts of keyed data throughout or between sessions. This finally brings honest statefulness to our previously stateless browser clients.

On top of this, mature JavaScript runtimes and frameworks happily allow the creation of robust business logic to be applied to this data. DOM manipulation, made reliable and fast by contemporary browsers (and commoditized by libraries for others) means that you can programmatically construct and manipulate entire user interfaces in the browser – in the extreme case, bootstrapping them up from a <body/>-like document whose main purpose is merely to include a <head> of the linked resources required to execute.

This is the world of the thick web client – or ‘Rich Internet Application’ in slightly out-moded nomenclature. A world in which patterns like MVC can be used again to describing client-side behavior, as well as a server-side technique. With this approach, once a client-side application has loaded its resources and is up and running, it can function more or less independently of the server that originally provided those resources, and creates and maintains a DOM that looks very different to that originally sent in the HTML’s markup.

(One might wish to argue that GMail is really just a site comprising a set of documents. Conceptually, perhaps. But comparing the app’s view-source with an inspected DOM tree will present a dramatically different perspective.)

With perhaps the exception of simple games, these applications nearly always need to bind back to some sort of web-based data API. As required, though, they can then easily cache that offline in their own data stores, greatly increasing the responsiveness and user-experience of the application, and making the prospect of continued offline operation a reality. This is a bold new step for the web. Not the web as constantly humming HTTP-pipes, but undoubtedly the web as stack of standardized, open technologies, working in interesting and evolutionary new ways.

I don’t want to give the impression that I feel this type of architecture should be used for all web experiences, nor even that it’s easier to build. Creating apps this way can be a daunting experience for many. Using imperative APIs may seem like a step too exotic next to the familiarity of declarative markup-based documents generated from a server. Your mileage will most certainly vary, and definitely some sorts of experience are better suited by one approach, others by the other. No binary proclamations implied.

</tldr>

But the point is that perhaps this is the watershed that we are looking for: a relatively clear definition between web site and web application.

The former we can define as an experience constructed on a thick server, delivered, with declarative markup, to thin browser clients, which then render what they’re told. Sprinkle on some progressive enhancement to maximize the user-experience and increase the chances of delivering a suitably degraded experience to legacy browsers.

The latter, on the other hand, is an experience constructed on a thick browser client, from imperative instructions dispatched, probably only once, from a thin server (or, in the case of a hybrid app, even no server at all). The philosophy of progressive enhancement survives – perhaps better characterized as ‘feature detection’ in this programmatic environment – although such apps often assume a certain higher baseline of browser capability. Local storage is utilized, MVC-like patterns are followed, concerns of data, logic and presentation are completely separated, and markup, if present at all, might be used merely for templates to be applied to that data.

So…

…yes, I’m a developer. I think in boxes and arrows. But as a relatively unambiguous classification criteria, this final, architectural distinction works best for me. Assuming you agree that such classification matters at all (in particular to those developing such experiences), how does this suit as a working hypothesis?

Discuss, etc.

(Hopefully I’m not the only one who can barely see #1e1e1e on #141414)

It did sound out-of-character from a champion of jQuery projects, and perhaps I was tempted to acknowledge the comment because it seemed such an extreme position from him. Sorry Scott!

But onto the comment itself. Why did I take a shine to it? It certainly takes a provocative stance.

“We are long past the point where URLs have any utility” is strong language. I of course enjoy the benefits of links and URLs myself every day, and I’m sure the commenter does too: bookmarks, links, emailed or tweeted, the ability to return through a browser’s history, open new browser tabs with target content and so on. All very useful. All very cool.

But does this mean that the URL is so sacred we can’t discuss its role and relevance in the real world? Think about whether it’s actually doing its job? Wonder whether it’s productive to shield it from the creative ways in which the web is evolving? And, as this commenter did, consider whether search engines are in fact coping with these changes effectively?

(Heretical to most people… but the sort of thing I like to think about – probably for that reason, actually. And what else are blogs for, anyway?)

So, yes, yes; URLs are used as a key for locating documents and resources across the web. That is all well and good. But I’m thinking; what happens when the web hosts things other than documents and resources? Like applications? Like games? Like physical objects? What happens when we need to serve humans based on other signals, such as their location, the time of day, their context, their intent?

It might just be possible, as the commenter asserts, that a single string-based identifier is not, in fact, sufficient to describe the infinite things that a 21st century, multi-dimensional web can do, offer, and represent.

I’m not completely sure. But I am convinced (and excited) that the web is evolving in these sorts of ways. Client-side applications, for example, seem to be a perfectly valid and compelling architectural way to use web technologies. And yet what role does the URL play there? Obviously as an entry point to the app as a whole, but then what? Does Tim Berners Lee’s plea require me to use a URL to describe every possible state, every view and every data point within it?

Documentistas would have it so. I can’t possibly build anything for the web without every piece of it being addressable like a document. Users must be able to deep-link into any docu state of my application. These URLs must return content to robots too – because where would we be without web crawlers? – and of course it all needs to degrade nicely for legacy browsers and screen readers. In fact, I may as well just fake the whole thing with server-side markup and progressive enhancement anyway. Many do.

But if I’m an applicationista, I create true client-side web applications, probably programmatically. I use little, if any, content-bearing markup, and I provide a suite of complex functionality to users, and pull in content from server- or cloud-based APIs in my own particular way. I acknowledge that my application needs to be accessible somehow, but in the corresponding state machine, the concept of a linkable document can quickly become tenuous, if not entirely inappropriate. Yes, I could conceivably use URLs to describe the finite states of a game of tic-tac-toe. But is there a http://angrybirds.com/level4 ? Or a http://angrybirds.com/level4/just-before-the-red-bird-hits-the-big-block ? Not that I know of.

If this web of applications is our new operating system, I see URLs as our command line switches. They can open apps, and sometimes drop you into well-understood states within that app. But by no means is the developer obliged to let any user reproduce any arbitrary state within it. A desktop developer can choose to let users launch a classic native application with certain pre-defined states – start this tool with a particular file open, for example – but does so in a very controlled and discoverable way. No native OS I know mandates that an application’s command line switches must be capable of describing all of its possible states. So why should the web?

In reality, certain web apps will benefit from deep-linkability, but many do not at all. And just because a large part of the web (the documenty bit) holds URLs self-evident and axiomatic might not mean that a different, growing part of the web (the applicationy bit) must do so too. Nick Morgan, admittedly opining on a subtly different topic, states:

The problem is that because everyone building stuff online is using the same technologies, there can be a tendency to think that there is one true way of using those technologies, independent of what they’re being used for.

And this is the crux. We might all be using web technologies (HTML, JavaScript, CSS and the like), but in radically different architectural configurations, and best practices for some may not be good rules for others. What this touches on might be the primary root cause of the hashbang debate (if not also others): the web is being used in challenging and unexpected ways and we’re finding it hard to re-examine practices and principles that were intended for a different age.

Yes, hashbangs are ugly. A hack. Sometimes they’ll need to be replaced with judicious use of the HTML5 History API. But other times they’ll need to be removed altogether: “it depends“.

But I believe that their usage – and the debate that has raged over that usage – tells us more about the culture of the web and those who create things for it than it does about syntactic purity or semantic elegance. It has shown us that we still find it hard not to think about the web in terms of documents, and that a web of applications can seem strange and opaque. And maybe that we are in a tighter symbiosis with search engine crawlers than we’d like to admit. Is that really what is meant when we’re told we risk breaking the web?

(It might be no co-incidence that our greatest cognitive dissonance occurs when we see something that probably should have remained document-based turned into an application, such as Gawker’s blogs. I notice that the vehemence of this debate never erupted over the non-linkability to arbitrary internal state of my GMail inbox, or to my high score on Entanglement for example. But I’m trying not to miss the wood of the web’s ambition for the trees of one particular implementation.)

Probably drawing ire, or confusion, from most at this point, I guess I leave it there. Please file under ‘verbose trolling’, and yes, for a developer, I’m veering dangerously close to amateur anthropology.

But let me finish with the commenter’s radical assertion that search engines ‘have long given up on indexing the web’ – crazy, surely: they still seem to do a great job with documents.

But applications? I’m not so sure. He might be on to something here. We’ve clearly got a long way to go in terms of describing and indexing application state, purpose and functionality on the web – without resorting to human curation. I’ve heard of these things called app stores, for example…

(At Sencha, for example, we spend a lot of time thinking about what this really means, and how it changes the skills, tools and frameworks we’ll all need to be effective web practitioners)

But here, I’d like to consider three particular changes that are happening, and one particularly overlooked impact they might have.

The first is the rise of powerful application architectures on the client side. Sencha has added Model-View-Controller support in both Ext JS 4 and Sencha Touch, for example, and this makes it possible to implement entire data schemas, rich business logic, and well-structured user interfaces – entirely on the client side. (Other frameworks are following a similar path: SproutCore, JavaScriptMVC and so on)

Secondly, the way in which HTML5 provides support for local and offline storage makes the autonomy of these apps a real possibility. Viewing, filtering and manipulating data can still be performed in the browser, even when completely disconnected from the server (or the entire network, in the case of a mobile device that loses coverage).

Finally, there are the possibilities of being able to use Javascript on the server-side of the web. The rise of interest in node.js, for example, is largely prompted by the opportunity to be able to use the same programming language throughout the entire web stack.

But such changes mean that this stack is changing shape.

Historically, the entire logic of delivering web-based services to browsers was built on the server-side. Databases, security layers, business logic, user interface creation – all of this was within the realm of the web server, and the browser merely took the resulting HTML and dumbly rendered it for the user.

Of course, this is incredibly inefficient: the entire stack is executed (and a whole page of HTML generated) for almost every single user interaction. To mitigate this, web developers turned to AJAX & AHAH to start placing more of the user interface logic in the client’s runtime environment, and to reduce the size of the payloads involved. The stack started to span both the server and client sides of the picture.

But with client-side MVC and support for local storage techniques, we can take this stack evolution a whole step further. With Sencha Touch, for example, an application constructs its entire user interface from scratch, and can synthesize the entire business logic, validation ruleset, and storage schema that would have traditionally been encapsulated on the server side.

Now, islands of independent data on each and every user’s device might make for a useful service, but it is far more likely that most applications will continue to operate in conjunction with a server – which, with the appropriate layer of security to protect access to it, will provide a central storage repository.

Our stack has now been neatly split in two.

(Note that, in the same way that we’ve long learnt to run both client-side and server-side validation of data submitted from HTML forms, it will probably remain wise to mirror business logic on both sides of the network to prevent inconsistency. While the rise of Javascript on the server theoretically makes it possible to do this with one set of common code, in reality, most server stacks will remain non-JS based for some time.)

All well and good. But in one very particular respect, an architecture like this is deeply ambitious. We have added a significant new programming challenge into the mix: and that is one of data synchronization.

When the browser is merely displaying read-only HTML or AHAH, the definitive copy of the business data is one place only: the server. But in this new architecture, we have the same logical data in two places – and, assuming we’re allowing users to interact with their copy of it, quite possibly off-line, we have to deal with the matter of keeping the two (or N) data sets consistent.

At a protocol level, this is simple enough. We can easily use JSON to transmit data bidirectionally over an HTTP wire, and Ext JS and Sencha Touch’s model store classes, for example, take care of all the plumbing for us. But when we should do so, what the payload should be – and how we reconcile any conflicts between client and server – can quickly become interesting design questions.

Consider a web-based corporate price list application, build using a client-side MVC pattern, and providing up-to-date information about a company’s products to its mobile salesforce. On its first instantiation on a mobile device, say, such an application might easily pull the entire list of product records from the server over JSON and store them locally for fast, possibly off-line, access.

So far, so easy. But of course the records might frequently change on the server: the company creates new products, discontinues old ones, and often changes their prices. How should the ‘create’, ‘delete’ and ‘update’ operations be applied to the mobile device’s version of the data? Should it regularly refresh the whole data set again? Should it request all changes since the last sync and then incrementally apply those changes to its local copy? If certain data is not updated for a certain length of time, should the client application mark it as stale?

These are already thoughtful decisions for the application developer to have to make.

But now imagine that the company’s product managers are given more powerful rights within the same application, and they can actually edit the product descriptions on their mobile devices. When connected, these changes can be immediately sent directly back to the server. How can we ensure that other users’ apps can have that change broadcast to them?

What about when the product manager is off-line, perhaps editing the portfolio on a plane? Should the application prohibit updates to the local data? Preferably not, but if changes can be made, how should the application poll to see when it is reconnected, and send those changes back in the most efficient way?

Taking it to extreme, what happens when two product managers edit the same pieces of data? What happens when each have added a new product to which their client applications have assigned the same supposedly unique ID? The system needs to reconcile those potentially conflicting changes – and very quickly this becomes a non-trivial task.

In the broader computing world, these challenges are common and have been frequently, and successfully, addressed. Many proven solutions exist for synchronization in the realms of distributed file systems, versioned source control, disk, database and site mirroring and so on – and even to manage our MP3 collections. But what is new is that this will soon becoming a challenge that web developers will need to tackle, and it is a challenge that might be unfamiliar and daunting to many.

In the general case, of course, there is no single approach that will answer all these questions. Effective synchronization across a ‘split stack’ architecture will depend very much upon the sort of data that is being manipulated and what the application is setting out to achieve.

Frameworks will certainly provide us with all the tools we need to implement the choices we make. But considering these synchronization-related scenarios and use-cases will be an increasingly important part of bringing compelling applications to users in increasingly diverse contexts. Reconciliation will lie at the heart of how we bring complex applications to life – not just an after-thought.

The web is no longer one of documents or of simple uni-directional data: it is fast becoming a web of synchronization. And I fear it might not be as easy as we think. As developers, we all need to go into this new world with our eyes wide open and be prepared for new challenges around the corner.

The APIs are pretty easy to use, and seem to follow the W3C (draft) standards.

I thought I would have a go to, and so I wrote a small Sencha Touch app that mimics one of those small sliding puzzles we all had as kids – but where the tiles are moved not with touch gestures, but by sliding the pieces under gravity.

From a Sencha Touch point of view, I’ve tried to use a best-practice application structure, and both the grid and the tiles are Ext.Panels (which makes them easy to treat in an object-oriented way and, in the case of the tiles, instantiate arbitrarily).

I have set up Ext.EventManager listeners for devicemotion and deviceorientation events, and fortunately, the callback can access the underlying browser event to get the motion-based properties I need.

The tiles themselves are placed on the grid using CSS transforms, rather than top/left positioning, along the lines of:

Ext.Element.cssTransform(this.getEl(), {translate: [x, y]});

This makes coding the sliding movement unbelievably easy: I simply have to change the transformation to where I want the tile to move to, and then

-webkit-transition:-webkit-transform .8s ease-in;

does the gentle slide. Wow. Transitions and transforms have been a spectacular epiphany for me in the last few months.

One catch with web-based tilt control: tip the device more than 45 degrees, and you might find yourself switching between portrait and landscape mode. I don’t know of a way to disable this in Mobile Safari.

The issue with this is that the co-ordinate system of the device’s physical orientation does not rotate, but the web page does. So in my case, I check the window’s current rotation and subtract the appropriate multiple of 90 degrees so that the elements still slide in the direction expected for the device’s physical position.

To test it out, get an iPhone or iPod Touch with iOS4.2 installed. Put the device level on a horizontal surface, go to http://tinyurl.com/ioslide – then tilt the device about 15 degrees in various directions to make the tiles slide.

Also feel free to look at (and be tempted to improve!) the code. Small, simple, and good fun: let me know what you think.

Like a few others today, I thought I should get familiar with it, and gave it a whirl this morning. My artistic genes don’t even pass their unit tests… so if I can make something work (admittedly with some help from Preston Blair), then anyone can.

If you have a WebKit-based browser like Chrome, Safari or their mobile brethren, you should be able to see the results of my efforts in an <iframe> below, or on the standalone page:

It’s somewhat scary to know that I’m basically drawing line-art with bordered <div> elements, but certainly it’s fluid and reliable enough on all the appropriate browsers I’ve tried.

I have no idea what it looks like on non-compatible browsers. For now, I daren’t think.

But the same page works like clockwork on suitably (that is, ‘highly’) capable mobile browsers. This screenshot is from the iPhone4 emulator:

Help yourself to my .anim file if you want to use this skeleton for your own animations.

Some say that using CSS3 for animation is going to be a standards-based way to replace Flash, and it may well become so at some point. Others say that it means we’re set for another decade of bad splash screens and corny animations. That may also be true – but you don’t ban paintbrushes just because there are bad painters.

Anyway, for now, I had a lot of fun. I’m excited to have seen a glimpse of what CSS3 Animations are capable of; even if they’re certainly not something I would ever have wanted to craft by hand: view source to see what I mean.

The current vogue seems to be to do as much of it as possible on the client-side: media queries, progressive enhancement, adding CSS body classes, and so on.

These are all cool, and hit a resonance with those who deal entirely with the front-end of a web site, and who prefer CSS (and a little Javascript) to Python, Ruby, PHP and the like.

In my opinion, this approach won’t always cut it. I’ve already pointed out that the users of radically different devices might want downright different things. Sometimes the differences between browsers are just too great to be able to deal with once the page has reached the client. And dealing with structural changes to a site’s information architecture based on browser capabilities gets messy, fast.

(Imagine if my site had a conditional a ‘photo upload’ feature that I wanted to place in the site’s menu for mobile devices that supported it. Do I have to feature test <input type=’file’> on every page, simply so I can add or remove nodes from the menu’s DOM? Ugh.)

So anyway, sometimes it’s far better to have had the server emit the best content in the first place – or at least as close as possible.

With this in mind, I’ve a new project called modernizr-server.

Modernizr itself is a great way to find out about your user’s browser capabilities. However, you can only access its API on the browser itself, which means you can’t easily benefit from knowing about browser capabilities in your server logic.

To address this, the modernizr-server library is a way to bring Modernizr browser data to your server scripting environment. For example, in PHP:

<?php

    include('modernizr-server.php');

    print 'The server knows:';
    foreach($modernizr as $feature=>$value) {
        print "<br/> $feature: "; print_r($value);
    }

?>

The server knows:
canvas: 1
canvastext: 1
geolocation: 1
crosswindowmessaging: 1
websqldatabase: 1
indexeddb: 0
hashchange: 1
...

Exactly the same feature detection is available through this (PHP) API on the server as is available through the (Javascript) API on the client.

Currently, there is only a PHP implementation of the server-side API, but other languages would be easy enough. Stay tuned to the project for more (and let me know what might be a priority, or fork!).

For instructions on how to use, and information about how it works, you’re encouraged to consult the readme. Also this is a young project, so please use in high-traffic production environments with due caution.

Your feedback is welcome! Hope it’s helpful.

Currently, monomi analyzes incoming HTTP requests to detect which type of browser they come from. Default values are ‘desktop’, ‘tablet’, ‘touch’, and ‘mobile’ (meaning non-touch), and the type is put into the request.monomi.browserType property.

The order of preference for the detection, as well as the algorithms used, can all be optionally overridden when the middleware is instantiated.

It’s early days for the project… I have plans to allow the middleware to adapt the outgoing content to be appropriate for the detected device – although this needs to be sensitive to the asynchronous philosophy of node.js

Try it, fork it, experiment, have fun.

Something I love about programming is that there are so many languages to choose from – why restrict yourself to learning or becoming an expert at one when the same problems are also being solved in other, sometimes better, ways? Each language or platform has strengths and weaknesses of course. But I believe that understanding the differences – and more often, the similarities – makes one a better programmer.

So, generous polyglot that I am, I took the challenge, and plunged in.
(Sign up for the free PercentMobile service to get the libraries described in this post.)

Python & Django

I love Python – its readability, its libraries, and its overall philosophies. In a web server environment, Python can be used in a fairly raw way, behind a generic Web Service Gateway Interface (WSGI), but there are also a number of powerful web application frameworks using the language – most notably Django. PercentMobile want to provide painless Django support, but also to make sure that other Python server environments were not precluded.

percentmobile.py is the single file that provides everything you need.

If you are running code in a WSGI environment, you will have a handle to the WSGI environment. This is normally called environ by convention, and is passed in to your application via your top-level WSGI callable. To make the PercentMobile tracking code work, you need only make one call to the percentmobile.tracker_cookie_insert function. It returns two values: the cookie that you’ll need to set in the HTTP response headers, and the HTML that you should insert into your page.

Say, for example, you had a very simple WSGI app. This responds to requests with an HTTP 200 status code, a single header and some simple HTML:

def my_app(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type','text/html')]
    start_response(status, response_headers)
    return ["Hello world"]

To add PercentMobile tracking to this code, you need to firstly import the tracker library of course, and then call the tracker_cookie_insert function:

import percentmobile
cookie, insert = percentmobile.tracker_cookie_insert(environ, '1234555')

(Of course you should replace the final string with your own site ID!)

The cookie return value is actually a dictionary of the different parts needed to construct its string serialization. This will allow you to splice together multiple cookies, or alter the expiry time, path scope and so on. To convert the dictionary to a string, and to get the Set-Cookie header sent back in the request headers, the following code will suffice:

cookie = "%s=%s; expires=%s; path=%s" % (
    cookie['name'],
    cookie['value'],
    cookie['expires'],
    cookie['path']
)
response_headers = [('Content-type','text/html'), ('Set-Cookie', cookie)]

Finally, you need to make sure the HTML fragment, in the insert variable, gets placed in the HTML response:

return ["<html><body>Hello world %s</body></html>" % insert]

And that’s a wrap. The whole, PercentMobile-tracked WSGI application looks like this:

def my_app(environ, start_response):
    cookie, insert = percentmobile.tracker_cookie_insert(environ, '1234555')
    cookie = "%s=%s; expires=%s; path=%s" % (
        cookie['name'],
        cookie['value'],
        cookie['expires'],
        cookie['path']
    )
    status = '200 OK'
    response_headers = [('Content-type','text/html'), ('Set-Cookie', cookie)]
    start_response(status, response_headers)
    return ["<html><body>Hello world %s</body></html>" % insert]

Pretty easy, huh? Well, not as easy as tracking an app if you’re using the amazing Django framework! Contained in the same percentmobile.py file is a class that can be used as Django middleware. It uses the same underlying function as the WSGI implementation, but also takes care of the headers and insertion for you.

Assuming you’ve placed the library file in your Python or Django path, you simply need to add two lines of code in the settings file. Firstly add the percentmobile.PercentMobileDjangoMiddleware class to your list of middleware:

MIDDLEWARE_CLASSES = (
    ...
    'percentmobile.PercentMobileDjangoMiddleware'
)

And secondly, add your PercentMobile site ID to the settings file too:

PERCENTMOBILE_SITE_ID = '1234555'

Um… that’s it. The middleware will intercept the request, figure out the cookie that will need to be sent in the response, create the insertion code, and place it just before </body> in the response. You’re golden. I love Django.

ASP.NET: C# & VB.NET

Switching over to another world altogether, let’s take a quick look at the ASP.NET implementation of the tracking code. One of the great things about .NET is that you can choose between all sorts of different languages to write your applications and pages in. I decided to write the tracking library in C#, but you can use it declaratively in your page code, or programmatically from C#, VB.NET, or any other supported language.

The library is implemented as a User Control – that is, as a .ascx file. You need to download and add PercentMobile.ascx to your web application project.

To embed the tracking logic into a page (or probably preferably, a master page), you simply register the user control as residing in that file:

<%@ Register TagPrefix="pm" TagName="Tracker" Src="~/PercentMobile.ascx" %>

And then embed the control straight into the .aspx file contents, wherever you want it to be:

<pm:Tracker runat="server" SiteId="1234555" />

So a simple, tracked .aspx file might look something like this:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Register TagPrefix="pm" TagName="Tracker" Src="~/PercentMobile.ascx" %>
<!DOCTYPE html>
<html>
    <head><title>Hello World</title></head>
    <body>
        <form id="form1" runat="server">
            <div>Hello World</div>
            <pm:Tracker runat="server" SiteId="1234555" />
        </form>
    </body>
</html>

To be honest, this is so simple that I would expect most people to use the control declaratively. But if, for some reason, the control needs to be inserted programmatically, that’s pretty easy too. You need to use the Reference directive, instead of Register, at the top of the file, but otherwise it’s not much harder. Here, we’re using VB.NET to programmatically achieve exactly the same result as above:

<%@ Page Language="VB" AutoEventWireup="true" %><%@ Reference Control="~/PercentMobile.ascx" %>

<script runat="server">
    Private tracker As PercentMobile.Tracker
    Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)
        tracker = CType(LoadControl("~/PercentMobile.ascx"), PercentMobile.Tracker)
        tracker.siteId = "1234555"
        form1.Controls.Add(tracker)
    End Sub
</script>
<!DOCTYPE html>
<html>
    <head><title>Hello World</title></head>
    <body>
        <form id="form1" runat="server">
            <div>Hello World</div>
        </form>
    </body>
</html>

(It should be fairly straightforward to see how to do this in other .NET languages – PercentMobile includes some examples in their install instructions.)

Java

Onwards. Let’s take a look at the tracking code for Java. There are numerous ways in which Java can be used for web or application server environments. To keep things simple, I decided that supporting JSP was more or less the most familiar and reusable approach.

JSP doesn’t enjoy the rich page event model that I was able to use in ASP.NET to intercept headers, write cookies, and insert HTML, all with one include. <jsp:include> is OK for adding the HTML snippets, but wouldn’t let me access the HTTP headers. <jsp:forward> does, but would only work if you weren’t planning to emit any HTML of your own after the tracking code – something of a radical assumption.

So I settled for an approach where an include directive creates an instance of an inner PercentMobile class defined within the JSP class. To cut a long story short, this means you merely add a reference to the library file at the top of the JSP file:

<%@ include file="percentmobile.jsp" %>

And then call the track method on that instance, somewhere within the page:

<%percentMobile.track("1234555");%>

The included JSP file takes care of instantiating the percentMobile object and giving it references to the request and response stream. This means it can read and write cookies, and later emit HTML. Your tracked Hello World in Java then? It’s as simple as this:

<%@ include file="percentmobile.jsp" %>
 <html>
  <body>
    Hello World
    <%percentMobile.track("1234555");%>
  </body>
</html>

node.js

OK, OK. Python, ASP.NET, Java. No big deal, right? That’s all so 2003 or so, right?

Well, there’s an alternative future for web server technologies. It’s one that’s blazingly fast, lightweight, event-driven, and… where you write your server logic in Javascript.

node.js is one of the most exciting things I’ve seen for a long time, and I know I’m not alone. Fresh, fashionable, and somewhat unproven, admittedly, it’s had a lot of gushing coverage. But since it turns the web server model (almost literally) inside out, I do believe there’s something important going on.

Would it be possible to write a web app with node.js and still have it tracked by PercentMobile? My challenge.

I decided to rely on Connect, a middleware framework for node.js, which, if you are writing web applications, provides a whole host of other helpful web logic. Using Connect to create a simple node.js app is extremely easy:

var Connect = require('connect');
Connect.createServer(
  function (req, res, next) {
    res.simpleBody(200,
      "<html><body>Hello World" +
      "</body></html>",
      {
        "Content-Type": "text/html"
      }
    );
  }
).listen(88);

To add PercentMobile tracking to this application firstly requires you to pull in the PercentMobile module:

var PercentMobile = require('./percentmobile');

(Where the percentmobile.js file has been placed in your node.js environment or in the common modules location.)

The module needs to be initialized as a piece of Connect middleware in the createServer function:

PercentMobile.init('1234555')

There are then two module functions, cookie and html, which both take a reference to the response object, and which return the cookie string and HTML to insert, respectively. These can be used in Connect’s simpleBody function, for example, meaning that our tracked application is as simple as this:

var Connect = require('connect');
var PercentMobile = require('./percentmobile');
Connect.createServer(
  PercentMobile.init('1234555'),
  function (req, res, next) {
    res.simpleBody(200,
      "<html><body>Hello World" +
        PercentMobile.html(res) +
      "</body></html>",
      {
        "Content-Type": "text/html",
        "Set-Cookie": PercentMobile.cookie(res)
      }
    );
  }
).listen(88);

That’s a wrap

So that’s it. A whistle-stop tour of the new languages and frameworks supported by PercentMobile. I’d love to hear your feedback on how easy (or hard!) these new APIs are to use.

And, oh… who will be the first to build a mobile web app on node.js?

I’m focussing on native client apps that are free to download. These wouldn’t have suffered commercially had they been written this way in the first place. Obviously, I’ll also focus on feasible genres of apps. No 3D games or background apps, for example. To start with, informational media apps (such as newspapers and broadcasters) will be in the spotlight.

But otherwise, I may not need to pull too many punches. Offline access? Through the wonders of HTML5, that should be OK. Native device API access? Well, BONDI and proprietary libraries permitting, I’ll have a go – and there’s always PhoneGap too.

Each post on the site will be a walkthrough (or part of a walkhrough) of the process. As I get my hands dirty, from the protocol-sniffing to the pixel-jiggling, you can follow the steps I took.

Stay tuned and wish me luck!