Internet-based software: think beyond the browser

By David Walker (Google profile)

Not so long ago, I took part in a project to build a Web application for Internet-based loan-finding service eChoice. The app stored, retrieved and processed information from a central database via an Internet connection and a Web server. And its users accessed it through a Web browser.

And that description exemplifies the software of this era. When the grizzled old-timers of 2025 reminisce about turn-of-the-century software, this is the sort of software they will talk about.

So I was surprised to find that during the build, the app evolved away from the browser-Webserver combination. It evolved towards the more traditional pattern of an application running on the PC, and using the Net to communicate strategically with the server.

What does it look like now? For a start, the application that exists today runs as client-side Java. The local PC can thus slice and dice pre-loaded data instead of repeatedly calling back to the server for more information. So users can do things fast. And those users get access to the richer set of Java user interface widgets, rather than the sometimes clunky tools offered by today's HTML.

For another thing, the app has evolved to the point where it stores data locally. That lets users update data and work without an Internet conection, connecting when they need to communicate with the central server. They use the Internet, but they don't use it like a LAN.

All this evolution happened because the development team had two talented programmers, two high-level analysts who understood the business and a fussy team of users just across the hallway ready to tell them all that the thing needed to be faster, and work more easily, and support different work styles. That combination of people forced the software to evolve fast into something that really works.

And as I look at its success, I'm struck by how much it has come to resemble a traditional application, the sort you install on Windows. Sure, it accesses data over the Internet. So do plenty of Windows apps. Yes, it runs on Java. But all its users run Windows.

The browser-Web server combination confers no special magic. For some projects, native Windows code will work just as well.

The programmer, entrepreneur and writer Joel Spolsky has made the same point. Spolsky is a smart thinker who ran the Microsoft Excel macro team, and his ideas tend to spread because he writes so damn well.

Spolsky's company, Fog Creek Software, is about to release a Web content management system - a species of software which some experts declare simply must run in a browser, no matter what. But Fog Creek's content management system is a native Windows app. Spolsky doesn't like the sluggish experience that comes with all those HTTP conversations between browser and server. He wants to be able to drag a picture from the desktop into an article - not something easily doable in HTML.

Most of all, Spolsky wants people to want his product. Writes he: "My number one priority is to make an application that's easy to use so that people like it, so that they tell their friends about it, so that everybody buys it and we have to hire full time employees just to slit open the envelopes and take out the checks".

And beta versions of Fog Creek's Windows-only content management system indeed make the user's life very easy.

Web browsers let people create, discover, publish and share. A quarter-century from now, Internet speed gains and richer interface tools could well make today's browser app issues disappear. But right now, the limitations of the browser-server are real.