Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Data fetching on the web still sucks

performancejs.com

Post reply on HN
Print view View original

41–50 of 98 posts

Re: Data fetching on the web still sucks

#41

Post by machiaweliczny »

Garlef wrote: post #37
heipei wrote: post #24

This 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…

Apollo client and Elixir LiveView are solving most of these.

Re: Data fetching on the web still sucks

#42

Post by whalesalad »

This post is hard to digest - it is a rant on 10 different things. All are valid hurdles but I don't see how we can just tie it all up in a bag and call it "data fetching".

Architectures are what help solve these sorts of problems - not tools or libraries. Placing the blame on tools means the real issue has not been identified.

Re: Data fetching on the web still sucks

#43

Post by Garlef »

machiaweliczny wrote: post #41
Garlef wrote: post #37

Earlier quoted context omitted.

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…

Apollo client and Elixir LiveView are solving most of these.

Yes. But do they automagically create and maintain database indexes for the most common requests made by your webclients?

Re: Data fetching on the web still sucks

#44

Post by ricketycricket »

Garlef wrote: post #43
machiaweliczny wrote: post #41

Earlier quoted context omitted.

Apollo client and Elixir LiveView are solving most of these.

Yes. But do they automagically create and maintain database indexes for the most common requests made by your webclients?

LiveView doesn’t allow arbitrary queries (or any queries really), so this is a non-issue.

Re: Data fetching on the web still sucks

#45

Post by enspandi »

whalesalad wrote: post #40
Nextgrid wrote: post #27

Earlier quoted context omitted.

I'm saddened to see that almost a decade after Ember's release, the front-end world still insists rolling their own (terrible) reimplementation of it. I would've expected that a decade later we would've settled on an Ember-like framework for the front-end and moved beyond constructing URLs and parsing JSON responses manually but apparently not.

The rest of the world moved on from Ember because Ember is a pain in the ass to use.

It has improved a lot though - checkout ember octane

Re: Data fetching on the web still sucks

#47

Post by dhritzkiv »

patates wrote: post #4

What are examples of data-fetching libs/standards outside the web, that check all (or a relevant subset) of those criteria?

I too am curious. All of the platform-specific frameworks which do networking+datastore, that I've used, check even fewer boxes. Especially when it comes to reactive UI and optimistic responses.

Re: Data fetching on the web still sucks

#50

Post by mewpmewp2 »

pferdone wrote: post #32
heipei wrote: post #24

This 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…

Half of the stuff he mentioned are covered by apollo-graphql and libs in that eco-system: query batching, notifications (via subscriptions), automatic state updates via cache, typesafety with typescript and grapqhl-codegen. It doesn‘t seem like he even looked at the libraries he listed. :(

Yeah, exactly, half of the stuff. You should be able to have all of this available by default. And it should have first class support without having to do complex setup. Also writing gql queries has always felt hacky and uncomfortable to me, without IDEs having the best support for it, and type safety? But maybe I haven't had the perfect setup.

Also graphql forces you to a certain way to resolve your data which may not always be the best fit.

Post reply on HN