5 ms·

Pushing Data, Not Pages is the New Model for Application Development

31 points by jamest 14y ago

bitwize 14y ago
That thing on the page scares me. Is that what Missingno. would really look like?
brlewis 14y ago
I agree with the "Pushing Data" part and disagree with the "Not Pages". An important "dumb client" still exists: the CDN. I think a popular model in the near future will be to push server-rendered HTML to a CDN, along with JavaScript that the ultimate client uses to get whatever has changed since that HTML was rendered.
- klint 14y ago
  Right - it's not that no pages are going to be rendered and transmitted. You've obviously got to get the HTML/CSS/JS into your browser somehow. There's also going to be a certain amount of heavy lifting that will keeping happening server side - big data analytics and all that. 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.
PeterisP 14y ago
It's the same old client-server model as it used to be done in 1990'ies. The article feels quite wrong with it's claim "The old client-server model involved doing most of the work on the server side and then piping the results down to a dumb client." - that's not client-server model; client-server development model involves smart clients which we abandoned in the last decade because of concerns about portability, installation problems and version update management. And now the cycle completes once more...
- klint 14y ago
  These new tools are fairly different from the client-server applications of the 90s (and 00s and even now). Those desktop applications did have a lot of chrome on the client side, but the "real work" was being done on the server. Normal AJAX apps are more like those 90s apps - the UI lives in the client, but they rely more heavily on the server than a CouchApp would. 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.
  - rhizome 14y ago
    You're right that they're different, but I think they probably use the same CS concepts, which is why we keep seeing the see-saw between thick and thin clients. Keep in mind that the thin-client trend that we saw in the late-90s/early 2000s was driven by Sun, who was selling a ton of big iron in those days (you weren't serious if you didn't have an E4K), not because there was some grand new technology that required them for functionality or usability.
- klint 14y ago
  I'll take another stab at explaining this: 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).
tzm 14y ago
It's not the "same old client/server model" from legacy systems. Essentially it's a publishing model that embraces mobile, cloud and in-memory data computation. ie, real-time data sync and the democratization of data analysis.
- klint 14y ago
  Actually, there is one old model that this new model does remind me of: IMAP (and Exchange as well). The e-mail client caches local data, can operate offline and interacts with one server that synchronizes data across multiple clients.
pippc 14y ago
I don't see this trend picking up beyond the scope of web applications for some time due to one simple problem: search engines. A large amount of content on the web is still meant to be openly consumed and found, and until search engines are able to run the resultant JS to generate the page, any sort of content-generating website will need to be able to render the pages as HTML. This client-heavy paradigm fits perfectly for "applications", but for now I don't think it can pervade elsewhere--unless someone's come up with a solution to this I'm unaware of.
- tlack 14y ago
  Even when Googlebot becomes Chrome, I don't know how it will make sense of the Ajax content fragments and component-based UIs. I think in the short term most people are simply going to build their sites twice: once as a JS-heavy interactive app and again as a bare bones HTML app that will index well.
tlrobinson 14y ago
"a design philosophy of sending data to apps, not rendered pages" I think we need to invent a term for this. How about "AJAX"?
- mikek 14y ago
  You can have AJAX without data. HTML can be AJAXed too.
olalonde 14y ago
I feel somewhat excited about that. It means we're getting closer and closer to Tim Berners-Lee's vision of a "semantic web": "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."

31 points by jamest 14y ago

That thing on the page scares me. Is that what Missingno. would really look like?

I agree with the "Pushing Data" part and disagree with the "Not Pages". An important "dumb client" still exists: the CDN. I think a popular model in the near future will be to push server-rendered HTML to a CDN, along with JavaScript that the ultimate client uses to get whatever has changed since that HTML was rendered.

klint 14y ago
Right - it's not that no pages are going to be rendered and transmitted. You've obviously got to get the HTML/CSS/JS into your browser somehow. There's also going to be a certain amount of heavy lifting that will keeping happening server side - big data analytics and all that. 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.

PeterisP 14y ago

It's the same old client-server model as it used to be done in 1990'ies. The article feels quite wrong with it's claim "The old client-server model involved doing most of the work on the server side and then piping the results down to a dumb client." - that's not client-server model; client-server development model involves smart clients which we abandoned in the last decade because of concerns about portability, installation problems and version update management. And now the cycle completes once more...

klint 14y ago
These new tools are fairly different from the client-server applications of the 90s (and 00s and even now). Those desktop applications did have a lot of chrome on the client side, but the "real work" was being done on the server. Normal AJAX apps are more like those 90s apps - the UI lives in the client, but they rely more heavily on the server than a CouchApp would. 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.
- rhizome 14y ago
  You're right that they're different, but I think they probably use the same CS concepts, which is why we keep seeing the see-saw between thick and thin clients. Keep in mind that the thin-client trend that we saw in the late-90s/early 2000s was driven by Sun, who was selling a ton of big iron in those days (you weren't serious if you didn't have an E4K), not because there was some grand new technology that required them for functionality or usability.
klint 14y ago
I'll take another stab at explaining this: 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).

tzm 14y ago

It's not the "same old client/server model" from legacy systems. Essentially it's a publishing model that embraces mobile, cloud and in-memory data computation. ie, real-time data sync and the democratization of data analysis.

klint 14y ago
Actually, there is one old model that this new model does remind me of: IMAP (and Exchange as well). The e-mail client caches local data, can operate offline and interacts with one server that synchronizes data across multiple clients.

pippc 14y ago

I don't see this trend picking up beyond the scope of web applications for some time due to one simple problem: search engines. A large amount of content on the web is still meant to be openly consumed and found, and until search engines are able to run the resultant JS to generate the page, any sort of content-generating website will need to be able to render the pages as HTML. This client-heavy paradigm fits perfectly for "applications", but for now I don't think it can pervade elsewhere--unless someone's come up with a solution to this I'm unaware of.

tlack 14y ago
Even when Googlebot becomes Chrome, I don't know how it will make sense of the Ajax content fragments and component-based UIs. I think in the short term most people are simply going to build their sites twice: once as a JS-heavy interactive app and again as a bare bones HTML app that will index well.

tlrobinson 14y ago

"a design philosophy of sending data to apps, not rendered pages" I think we need to invent a term for this. How about "AJAX"?

mikek 14y ago
You can have AJAX without data. HTML can be AJAXed too.

olalonde 14y ago

I feel somewhat excited about that. It means we're getting closer and closer to Tim Berners-Lee's vision of a "semantic web": "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."