Pushing Data, Not Pages is the New Model for Application Development
devopsangle.com
devopsangle.com
That said, all these Meteor and Firebase apps could end up having quite a bit of middleware and end up not seeming all that radical, depending on how much stuff gets added on.
Originally everything was done on dumb terminal connecting to mainframes. Then we got PCs and workstations that could run client-server applications where there UI lived on the workstation but the data still lived on a server. So let's say you have an inventory app with a desktop client. When you search for an item, the application does a query and returns a list of results from the database. You then select the one you want, it does another query and downloads some more data from the database. Then you makes some changes to the item and commit them to the database. The client uploads the change to the database by performing another query. This all works pretty well over a LAN because the server.
If something goes wrong with the server, or if your network switch or network card stops working, then the app stops working. But if you have good gear and a good IT team, that's relatively rare. You can get your work done.
Then along came Web applications. These made IT's life easier because instead of deploying a desktop client to everyone's machine, they can just install the software on the server and everyone can connect to it. It still works mostly the same way your desktop client did, except now the UI elements are downloaded to your browser when you visit the site rather than being permanently stored on your desktop.
Where things get hairy is when you're trying to access these types of systems over the Internet. There's more latency, everything seems slower. Then suddenly everyone wants access from a smart phone, where their connection speed is slower and it can drop in and out. So you start using AJAX to put more UI elements on the client side, but you're still making database calls for each action you perform.
So one thing that's new in these tools is that more data is cached locally. So your inventory app would actually download a whole bunch of data all at once so that you can query it locally, without having to hit the server each time. That creates a bunch of new problem, like handling conflicts, authentication, etc.
Another thing that's new is that there's a thinner, or perhaps non-existent, layer between the client application and database server (in the desktop client-server model, you might also have been able to connect directly to the database, depending on the architecture, so that's not necessarily all that new. I don't know enough yet about how Lotus Notes databases work, but I know that they're the direct ancestor to CouchDB).
I think we need to invent a term for this. How about "AJAX"?
"I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize."
But the trend is towards doing less rendering server side and more on the client side, with just the raw data being pushed around rather than the presentation of that data.