Programming languages, application frameworks, SQL or NoSQL databases, data-binding mechanisms, templating libraries -- they're all up for grabs. Choice is good. But let's think about how my friend would have solved this problem 25 years ago for a colocated team on a LAN.
There weren't many choices then. There was dBase, there was Access, there was my personal favorite, FoxPro. You didn't have to be a proficient programmer to create a basic database app. A power user could do the job, and many did. Of course the LAN didn't span the globe; it only connected people in the same building. The apps you created ran on the desktop against a shared resource on a file server.
Thinking about my friend's situation led me to a perverse thought: As bandwidth to the cloud increases, could an ancient copy of FoxPro become useful again? Of course that's ridiculous. We want modern Web apps that talk to Web servers, not desktop apps that talk to file servers. But where are the well-known and widely used modern equivalents of dBase, FoxPro, and Access for today's Web? I don't see them.
Back in the day there were three big productivity apps: the spreadsheet, the word processor, and the database. Each of the legs of this three-legged stool was an app that power users could effectively customize. Two made the jump to the cloud. Google and Microsoft both offer cloud-based spreadsheets and word processors. Neither offers a cloud-based database. Why didn't the third leg materialize in the cloud?
Consider the file formats. Canonically they were XLS, DOC, and DBF. In the case of word processors and spreadsheets, we use the cloud as a file server, and we still share XLS and DOC files on the moral equivalent of a multiuser LAN.
But databases evolved differently in the pre-Web era. The client/server architecture appeared. Servers stored data in many proprietary formats; they communicated with clients using a few protocols; a more-or-less standard query and data manipulation language, SQL, helped unify them; an umbrella standard, ODBC (Open Database Connectivity), completed that unification. Given that ODBC was an interface not only to servers but to files -- DBF, XLS, CSV -- you could say that the early 1990s was a golden era of data interoperability.
Then came the Web, with its very different client/server architecture. To this day we have yet to reconcile the two. Tim Berners-Lee envisioned that reconciliation in his original proposal. "A generic tool could perhaps be made," he wrote, "to allow any database which uses a commercial DBMS to be displayed as a hypertext view."
We now have a standard way to do that. OData, aka Open Data Protocol, enables a common RESTful interface to Web data. It emerged from Pablo Castro's work on Project Astoria and is now an OASIS standard. But if you don't inhabit the Microsoft ecosystem, OData isn't on your radar. It's easy to consume OData from any platform, but producers are still scarce and Microsoft-centric.
In OData Client goes Open Source (2010), Miguel de Icaza wrote:
If Microsoft were to open-source their server-side implementation of oData, we could overnight allow Linux users to expose their data in a format that can be mined. Linux users would only need to run a Mono front-end to the System.Data.Services library to expose the data that currently lives in their servers and is being served by Joomla, Wordpress, Rails, Django front-ends to become available as data services.
That hasn't happened yet. Given that the core .Net runtime and frameworks went to GitHub in November, what seemed like a pipe dream in 2010 now feels inevitable. But maybe that ship has sailed. Maybe it's too late for OData to become the universal ODBC for the Web it was meant to be.
One way or another, though, we need a common way to work with Web data, one that every database can use to easily enable a basic API. On that foundation, we might re-create the kinds of tools that make building simple back-office database apps as easy as it was 25 years ago.