Data fetching on the web still sucks

* Consistency when fetching data: define a UI that matches a particular SQL view.

* Request batching: It's probably not hard to send deltas on a large view with server-side support for sessions.

* Avoiding network waterfalls: basically the definition of a SQL view, with some session management to de-duplicate traffic when updating the view. A lot of clients support batching queries.

* UX when fetching data: this seems entirely like an oversite of some UI packages, but when all the other points line up there are very distinct points in application flow when the UI will know a query and potential update is in progress.

* Colocation: the definition of a view is necessarily local.

* File size: SQL is pretty lightweight on the schema details in results

* Type safety: SQL doesn't support dependent types, but e.g. postgres is pretty type-y

* Versioning: no explicit support in SQL but for changes to the UI a new view can be created. For changes to the data model a compatible change to the view can be committed in the same transaction as the data model change.

* Realtime updates: the glaring hole in the glory of SQL. You'll have to do some user-defined triggers server-side to support this.

* Consistency when updating data: the relational model with constraints enforces this

* Optimistic updates: if the theoretical differential view update described above exists then this is pretty trivial. Compare local and remote deltas when refreshing the view and indicate to the user the expected state that wasn't committed.

* Request queueing: this one seems to be more of a data model problem. If the data model approximates a state machine and queries are on transitions then yes, they need to be serialized. But why not do complex updates all at once with a multi-statement update transaction that commits or fails atomically?

* UX when updating data: presumably a UI tied to a single view is easier to indicate busy-ness for. If an update transaction is in flight, display a spinner. When it fails or commits display an OK or error.

* Durability when updating data: this could almost certainly be improved for most sql clients. However, idempotence is definitely covered by conditional update transactions.

* Type safety: user defined types if necessary but constraints are where a lot of the type-safety happens in SQL.

* Versioning: backward-compatibility by updating mutable views in the same transaction as data model changes. Forward-compatibility by rendering directly from the view that's returned, not expecting any particular view.

Second paragraph: "The UI should automatically update everywhere the data is used". Again, what does this have to do with any of the above? That is state management, yeah, and you can build proper state management with any HTTP library and any message serialisation format.

Request batching: How would that happen "automatically"? By waiting to fire requests and then batching them?

UX when fetching data: What does that have to do with any of the above? You still have to decide how your UI displays the fact that a piece of data is loading. What do you expect there to be in place? Best thing I could imagine is to have a global operations indicators a la Adobe Lightroom which tells you how many HTTP requests are in flight.

I could go on, but the last paragraphs maybe highlights the lack of understanding the author had: "UI Frameworks (at this point, React has won)". If React had "won" then why would we be having this discussion. React hasn't "won" because it solves one piece of the puzzle: Rendering. For every little other thing you have to incorporate another library or figure out your own solution: Routing, State Management, CRUD / HTTP API, etc. If anything, Ember.js would most closely fit the bill of incorporating most of the things the author seems to care about yet can't articulate clearly.

almost all of the mentioned issues have solutions out their but the author is jumping around the stack with no sense of true purpose. How does graphql impact your SPA updating views, it doesn’t..

Yeah, there are solutions to them, but I think what the author is saying is that you have to subscribe to something batteries-included, like Meteor, or otherwise implement the solutions yourself from bits and pieces.