Mobile JSON is to HTML what HTML was to Telnet.

Today, I met with York University CIO Bob Gagne and Director of Information Systems Peter Rowley to talk about my York iPhone app. I ended up talking not just about what I did and what’s in the app, but some of the challenges of mobile web development. I’m now convinced that we will have to slowly migrate bit by bit to a semantic, JSON-powered web, which will be as different from today’s web as HTML was to Telnet.

Here’s the evolution of pages on sites like yorku.ca:

1. Start with HTML 4 or worse. Tables everywhere, and font tags.
2. Convert that to XHTML and add basic CSS.
3. Use techniques to speed up web sites (e.g. this or that like CSS slicing)
4. Add extra CSS and HTML5 for browsers that support it, while preserving original functionality
5. Add some jQuery to the HTML to reduce the number of clicks people make
6. Move the HTML generation into JavaScript, so the page body HTML changes via jQuery to speed things up further.
7. Server-side, though likely not in the same server/language as the website host, de-couple the content from the HTML, either by parsing the HTML automatically or using existing database sources to create JSON to get via jQuery and generate the HTML.
8. Given the JSON objects, refine the business logic and authentication to serving JSON objects RESTfully instead of pages and forms.
9. Using an MVC JavaScript framework like jQuery-Claypool, as a JSON-based alternative to HTML requests from #6. Claypool has the advantage of building on the jQuery you already know.
10. Replace the old system still serving HTML to non-JS clients with a new server-side rendering farm powered by jQuery-Claypool on the server, or some other form of JSON-consumer.

But the question you’re asking yourselves is “Why ever would we perform step #7?”

The answer? iPhone apps, netbooks and autocomplete.

• iPhone because it’s an example of a great platform for viewing data that doesn’t necessarily use any form of HTML.
• netbooks because they’re mobile web browsers with relatively tiny screens, and we still have to develop for them as well as for giant 27″ iMacs. The only way we can realistically provide good experiences on both platforms is by using JavaScript (or CSS in advanced browsers) to control the styling, which means again that the data is more important than the HTML or styling employed.
• autocomplete because it’s an example of how we now expect websites to be more dynamic, just as we now expect our inbox to refresh without our clicking the button in the browser window. We don’t want the whole page to turn white when we just want new data to appear.

So why JSON? It’s now supported natively in IE 8, Firefox 3.1/3.5, and maybe Safari 4.03/Webkit. Beyond the web browser, JSON parsing has been written for an incredible number of platforms and languages. Here’s an excerpt from json.org to help explain why:

JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

JSON is built on two structures:

• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

These are universal data structures. Virtually all modern programming languages support them in one form or another. It makes sense that a data format that is interchangable with programming languages also be based on these structures.

It’s incredibly simple compared to XML, and more compact too. What languages are supported? (Number of implementations listed on json.org in brackets): ASP (3), ActionScript (4), C (7), C++ (6), C# (9), ColdFusion (3), D (1), Delphi (3), E (1), Eiffel (1), Fantom (1), Flex (1), Go (1), Haskell (3), haXe (1), Java (18), JavaScript (4), Lasso (1), Lisp (6, 5 variants), LotusScript (2), Lua (2), Objective-C (2, plus one I know of called TouchJSON), Objective CAML (1), OpenLaszlo (1), Perl (100s? check CPAN), PHP (8), Pike (2), PL/SQL (2), PowerShell (1), Prolog (2), Python (3), R (1), REALbasic (1), Rebol (1), Ruby (2), Squeak (1), Tcl (1), Visual Basic (2), Visual FoxPro (2)

Yes, that list includes both old languages near dead and newest of the new, like Google’s Go that launched last month. If you need more flexibility for data storage than JSON offers, take a glance at YAML. JSON is a subset of YAML — which means a JSON doc is a YAML doc, but a YAML doc isn’t necessarily a JSON doc. (JSON is simpler than YAML, for things like recursion and so on, as I understand it. Easier to parse, at least.) This means any YAML parser can also parse JSON, which increases its compatibility even further, if there weren’t enough libraries to read it.

This kind of interoperability is why I now say that Mobile JSON will push the web forward, from Web 1.0 to 2.0 to 3.0. It will be gradual, and not everything will be up and running in a public fashion, but when combined with an easy-to-understand RESTful API layer and an Open Data license, that’s the real Web 3.0 semantic push, and key for students and geeks to build and innovate beyond company boundaries. It’s also where the really exciting stuff happens, when web apps seem to write themselves as easily as Twitter clients.