Webapps

In the early days of the Web, people struggled to make websites more dynamic. The original web technologies were centred around static presentations; they were pretty good at this.

As the trends matured, more and more technologies became available to make the sites dynamic, but also to use them to essentially wrap other programs and systems. The web interface was born; people gave these the cool name of webapps.

In those days, most serious developers continued to produce native GUIs. The web technologies seemed hokey and crude. Many were just mindless fronts that called the real stuff in the back. Light clients calling APIs.

The problem with native apps was portability. There were more operating systems back then, and it was crazy expensive to rewrite the same program for each one. The technologies for writing stuff once and getting it to run everywhere were a great idea, but the implementations were generally too limited to be useful.

What the web promised, though, was a guaranteed way to avoid portability problems. These promises, however, were quickly disrupted by the browser wars and by the emergence of mobile devices.

That led to a huge wave of ‘frameworks’ that all promised portability across all of these different platforms and form factors. Initially, they helped; webapps grew a little more sophisticated. But somewhere along the way, they all got pretty convoluted. Suddenly crafting a reasonable webapp was a whole lot more effort than just crafting native apps. That bump in complexity was rewarded with a visible drop in quality. Webapps started to become extremely buggy.

The browsers themselves grew in sophistication, but their integration was compromised by huge security failures. The web became a free-for-all for scams, driving a lot of people into silos.

They are still just a limited window into some features, but most of the ways to extend them are too fiddly to be practical.

So we’re left with most interfaces starting on browsers, then getting mobile cousins, then maybe better native versions. Oddly ironic since, except for form factor, they're all a bunch of interactions on a whack load of widgets. The foundations for graphical user interfaces haven’t changed for decades, just after the client/server split. All of these modern technologies trace a close lineage to their earlier generations.

If we were going to rethink this, it would be to go way back to the portability days. We’d still like to write one set of code that covers all three locations, pushing each right to its limits. That is, you’d grab a webapp you like, run it natively, and it would save your files locally. If you run it on a phone, it would give you the option of local or hosted.

If you can wire in optional platform capabilities and some dynamic form factor support, then you really could return to a point where writing interfaces wasn’t the bulk of the development effort. If it was near trivial to dump out 80% of the boring screens in a few days, then you could spend more time deciding which widget arrangements were best suited for which tasks, rather than expensive widget/presentation wiring and refactoring.

Webapps suck. They almost didn’t, but then fate intervened. We don’t need more siloed clumps of monetizable half-baked features; we have enough already. We need better adaptive and integrated tools that allow us to spend less time on computers, not more. The answer to this is not probabilistic personalized interface generation; more opaque, crappy code will only make things worse. It is to rework our foundations and get back to some of the great ideas of the past that we skipped over too quickly.