The future of the web is mobile. And by mobile I don’t mean mobile phones. I mean browsing through devices that people carry around with them. All these devices, irrespective of form factor, have a common problem: they are prone to lose connectivity to the internet.

If you’re on the move and keep losing your 3G signal, or just happen to live in an area with a poor reception, or in a house with brick walls which slow wifi, or suffer from terrible contention rates in your Starbucks or conference venue, you’ll know that cable-less connectivity is fallible. So you’re in the middle of a transaction, just trying to get to the next step when… enter tunnel / lose packet / connection error and you have to start over.

There is a solution to this problem however. As Michael Kowalski tells us, the future of the web is JavaScript. Or perhaps not JavaScript in its current form, but client-side scripting nonetheless. Why? Consider the options.

If you want interaction that will run reliably on a device with poor connectivity, you can’t keep expecting the browser to go back to a server. So you might make your functionality available as a downloadable app. But it had better be a killer app the user wants to rely on, because otherwise they won’t want it taking up real estate on their phone. And it’ll have to run across operating systems if you want to reach a broad market, not just Steve Jobs’ latest toy.

You could use a rich internet application such as Flash or Silverlight. But the client platform has to support these and the user has to install them, although they’re more likely to do so for a generic RIA than for a specific tool. The big issue with these applications however is that the content is embedded in the interface, which makes them both heavy to download and difficult to make accessible to other applications, such as screen readers and content aggregators. So you’d probably have to create two versions of the content: one embedded in the RIA, the other standalone. That’s not great.

JavaScript has the advantage that it can be used to enrich content, but not contain the content itself; for example, to provide better interactivity on maps. There are also libraries of JavaScript functions that can be re-used and downloaded to the client device with the user barely noticing. Take jquery: Google hosts a copy, so if you use these functions on your site, you don’t even need to host the file. Reference Google’s copy and you’ll save bandwidth and, if enough websites follow the same path, there’ll probably be a cached copy on the user’s machine even before they get to your site, which will significantly improve response times.

Google is of course moving beyond jquery to complex client-side scripting which its own browser / operating system will be capable of handling, but some other browsers may struggle with. Chrome is a replacement for off-line scripting using Gears. It should not only enable mini applications such as Wave to run faster in a browser, but will enable online transactions to continue to function better when connections are poor. Opera has been developing similar functionality for its browser too.

So if you want to provide audiences with a better experience irrespective of platform and location, a lightweight client-side tool that separates content and function and runs in a browser seems like a future-proof idea. And for the moment at least, that means JavaScript.