If your UI is complicated enough to worry about most things on this list, maybe simplify your UI?
Data fetching on the web still sucks
51–60 of 98 posts
Re: Data fetching on the web still sucks
#52I'm currently experimenting with React and WebSockets and they seem to be a perfect fit. No need to write wrappers for Fetch, network errors and reconnects can be handled on high-level, handlers for each message type can be mounted and unmounted on useEffect hooks, all back-end jobs can notify the user in realtime, all session-based client-side data can be updated in realtime (in single or multiple open tabs). I'm al…
> and they seem to be a perfect fit Needs a fairly capable server though, I suppose. One that can handle lots and lots of open websocket connections.
Also your load balancer stack needs to support it, which is becoming less of a problem these days but there's still some stragglers. You could also end up with an imbalance where some servers have a lot of connections and others have few.
Re: Data fetching on the web still sucks
#53> UI frameworks (at this point, React has won)
Isn't this like someone in 2011 saying "UI frameworks (at this point, jQuery has won)"? I think things like Svelte and other up and coming UI frameworks are still being developed because we all recognize that React is not the ultimate UI Framework. Perhaps we will never get there, but surely we can do better than where we are at.
Re: Data fetching on the web still sucks
#54This post feels like a uninformed and undifferentiated rant against "things are too complex". Let's start with the first paragraph: What does the JavaScript fetch API have to do with data management? How can you compare the fetch() API with Swagger (an API documentation format) with Protobuf (a serialisation format)? That doesn't even make sense. Second paragraph: "The UI should automatically update everywhere the da…
I think the post is a bit unfortunate in its wording and this seems to have sent you off on a wrong track. From how I read it, this the post is not specifically about JS and a discussion of the specific technologies mentioned but rather concerned with the following very general situation: 1. There's a user sitting in front of a browser. 2. There's a backend server providing data and points of interaction with that da…
I think parent is completely missing the point. In my opinion the way it should be is that in the backend you export a typed function like "getTasks(filter: Filter): Tasks
And in the frontend component you should be able to use it immediately and it would be correctly typed without having to duplicate types or anything. And if function is not complete yet it will not render the component before.
This should be instead of REST and Graphql, both of which have many issues imo.
Re: Data fetching on the web still sucks
#55Nobody has solved it because there is nothing to solve. That's like saying that "we to optimize SQL for UX". No, no we don't.
Fetching data has nothing to do with managing state, rendering UI, or even UX. Each layer has different problems it needs to address.
And btw you can totally do GraphQL requests with fetch().
Re: Data fetching on the web still sucks
#56Earlier quoted context omitted.
It doesn't have a great story around error handling IMHO.
I've found Relay to be pretty solid with error handling, though I think the ability in how to handle GraphQL errors does hurt Relay here, but it does for all GraphQL clients. Re: parent, I also was surprised to see Relay dismissed on the list, it solves every problem they bring up in the list, perhaps maybe not the real-time aspects
I should have clarified that Relay flavored GraphQL from a backend perspective is lacking in this respect.
Yeah, I think relay is pretty good, but I'm not sure the broader ecosystem is really there yet. Outside of node, the backend libraries aren't really fully baked yet, and the standard seems to have some holes. But I'm somewhat optimistic.
Re: Data fetching on the web still sucks
#57This post feels like a uninformed and undifferentiated rant against "things are too complex". Let's start with the first paragraph: What does the JavaScript fetch API have to do with data management? How can you compare the fetch() API with Swagger (an API documentation format) with Protobuf (a serialisation format)? That doesn't even make sense. Second paragraph: "The UI should automatically update everywhere the da…
I might intuit that 'request batching' could be benefit http/2 but probably not what they were thinking about. And you'd have to have a lot of simultaneous http requests for it to help at all.
But I'm with you on trying to batch this with your JS should not be a browser thing or even a built in standard library JS function.
One could do it themselves - maybe graphQl kind of this idea of more complex queries + maybe just throw the requests you want to make into an array and when it hits length = 5 send them all at once. But I don't see how that would help response times at all.
Re: Data fetching on the web still sucks
#58This post feels like a uninformed and undifferentiated rant against "things are too complex". Let's start with the first paragraph: What does the JavaScript fetch API have to do with data management? How can you compare the fetch() API with Swagger (an API documentation format) with Protobuf (a serialisation format)? That doesn't even make sense. Second paragraph: "The UI should automatically update everywhere the da…
> Request batching: How would that happen "automatically"? By waiting to fire requests and then batching them?
Haxl is good prior art for automatic batching and concurrency. But it helps that Haskell makes the "when" very explicit thanks to its type system.
https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...
Re: Data fetching on the web still sucks
#59This applies to everything in the browser honestly. Why can’t I bind a variable to the DOM natively? I want the variable X to match the value of and vice versa without having to set up a bunch of listeners and hope they don’t go in a loop.
Re: Data fetching on the web still sucks
#60> UI frameworks (at this point, React has won) Isn't this like someone in 2011 saying "UI frameworks (at this point, jQuery has won)"? I think things like Svelte and other up and coming UI frameworks are still being developed because we all recognize that React is not the ultimate UI Framework. Perhaps we will never get there, but surely we can do better than where we are at.
This is highly subjective of course, but I think Vue has already surpassed React from a technical and ease-of-use standpoint.
Where React still leads handsomely is tooling (the official VS Code Vue plug-in is buggy as all hell), breadth of ecosystem, and employability.