|
|
|
|
|
|
by sanderjd
4497 days ago
|
|
|
You make some really good points, but I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users. I'm also not sure that rendering everything client-side is advantageous enough to warrant its current popularity (hype...), but I do see some advantages. Firstly, I think it is a better separation of concerns - the server is in charge of data discovery, persistence, consistency, and aggregation, while the client is in charge of determining how that data can be most useful in the current context. In practice, this means it is possible to have different front-ends for the same back-end. Admittedly, that is certainly not always a necessary or desired feature. The separation also makes it easier to build the front end and back end of an application separately from one another, and possibly even in whichever order you prefer. That can be a good thing, though I don't think it's really taken advantage of very often. I also think that true web applications can be made to feel much snappier and closer to native. The line between what should and shouldn't be considered an "application" is unfortunately blurry (the Blogger example is a good one). |
|
|
This is an interesting point - if you are representing numeric data like chart datapoints, a representation like json might make it cleaner and more reusable by other services or clients. Of course much data is actually formatted documents or snippets of text, in which case json is not such a good fit and html is perhaps better. In many ways html is a worse is better solution, but that is probably part of its strength - it is very easy to get started with and munge to extract or insert data.
I'm not sure a separate of concerns between server and client is necessary and helpful to all apps, though I'm sure in some cases it is useful (for example serving the same json or xml to a mobile app, a client-side app and some desktop client, or separate teams working on both), but then a server-based solution can easily output both formatted html for traditional clients (web browsers, which are now and in the future ubiquitous), and a json or xml representation for other clients - this sort of separation of concerns between data and presentation is not really exclusive to client-side solutions.