7 ms·

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 fet

by heipei 6y ago

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 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.

batoure 6y ago
What this person said! ^ 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..
- chrisco255 6y ago
  Of course it does, because GraphQL allows you to roll up queries for separate entities and get the data back for those in a single HTTP request. And that capability is something Relay and Apollo take advantage of. In this way a component can reference only the data it needs and the query rollup and caching happens automatically.
lxe 6y ago
I actually think the problems outlined are pretty valid. 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.
- derefr 6y ago
  "You have to subscribe to something batteries-included, like Meteor, or otherwise implement the solutions yourself from bits and pieces." ...yes; that is, in fact, the conceptual dichotomy in solutions to essentially-complex problems. Either someone else solves them for you, or you have to solve them yourself. I mean, yes, there is a part of the solution-space in-between these two extremes — a point where there's a batteries-included thing that someone else built but then gives away for free, perhaps as an open-source project you just have to run on your own infra. So it's mostly solved for you, and then you just do a little bit to "get the solution running" for your use-case. That point in solution-space is conspicuously absent for web data sync. But, in domains with essential complexity, that middle-ground part of the solution-space is usually conspicuously absent. Because it takes continuous dedicated effort (i.e. labor; capital expenditure) to solve the complex problem in a cleanly-abstracted way. And it's very rare that anyone's going to go to the effort, unless they expect a return on their labor investment (by e.g. keeping the solution proprietary, and building a SaaS business around it.)
pferdone 6y ago
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. :(
- bcherny 6y ago
  Sorry if it was unclear, but my argument is that while many libraries solve pieces of the problem, no one library (or standard) solves all, or even most, of these.
- mewpmewp2 6y ago
  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.
bcherny 6y ago
Author here. Data fetching, caching, consistency, and UX are all closely related. If you treat them as separate problems, you're punting the problem onto product engineers, who won't solve it well. (See the last paragraph of the post, which suggests this same idea.) > That is state management, yeah, and you can build proper state management with any HTTP library and any message serialisation format. You're right that to do this manually it's just state management. But to automatically update the UI, it means your client data layer (eg. Apollo) needs to know & track the identity of fields; the data layer also needs to be able to subscribe to fetches anywhere in your app, not local fetches; it also means your protocol needs to support this identity (via agreed-upon ID fields); etc. These problems are all closely related. > Request batching: How would that happen "automatically"? By waiting to fire requests and then batching them? eg. Relay does this by statically combining requests throughout a React tree into a single request at the top of the tree. You could also do it dynamically, as you suggest. The tradeoff is often performance. > UX when fetching data Having engineers manually define loading states doesn't scale. React is approaching this problem with Suspense, and you could imagine standard loading states when fetches are in flight.
- austincheney 6y ago
  State management, for anybody half competent, is stupid easy and not tied to the UI. State management is a data storage/retrieval problem only. Once the UI has the state information it needs you can populate it for the user however you want in many different ways. State management is also proclaimed as something it isn’t because web UI is full of incompetent expert beginners who can’t write two lines of original code and are helplessly mortified if their colossal framework is taken away. Here is simple web UI state management: * have a centrally available object in the UI code that stores state data. * store that data upon change. That storage can be localStorage for maximum simplicity. It can also be a locally written file if you have a local running service or an http server. The further away from the local computer that storage location becomes the slower it is regardless of access mechanism. * state changes can occur from user interaction or system updates to remote data. Most important are user interactions because that data is locally available. Keep up with remote system changes as best you can, but unless you own that data as well it’s a window into some distant concern. * when state changes update your central state object save the changed state object. Most of the time UI developers are only concerned with state updates and not saving state because they don’t know what they are doing and hope the framework does everything (or it must obviously be unnecessary). * once the state object is updated, and optionally saved, update the UI. For most UI developers updating the UI is the ultimate and only struggle. This is such a junior level basic required skill for UI developers. Knowing that you can root out the incompetent people during hiring. But but but what about 2 way data binding... Treat it as an event. Update the central state store. Process the change. Still simple and no framework is needed.
Garlef 6y ago
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 data. I think the central point of the post now is that we don't have a satisfying technical solution for this situation. Let's take a look at one of the points you mentioned. Maybe you might find there's actually some valid points in the post and give it a more favourable reread. > UX when fetching data: What does that have to do with any of the above? Here, the author of the post writes: "It’s a big burden for engineers to have to manually add loading spinners and error states, and engineers often forget." I think it's more or less clear how you could implement this using only plain vanilla js. Cumbersome but doable: A very manual, imperative process. Now let's envision a technology from a possible future: const twitterFeed = createMagicDataSource("https://twitter.com/...") const feedComponent = magicRendererComponent(twitterFeed, state => /* HTML like declarative description of the visuals */) Imagine this was everything you had write in your code to get the following: * state gets automatically loaded when the first instance of the component is created * updates are automatically visualized in the client based on the internals of the declaration in the renderer * you don't have to specify if the updates are done by polling, websockets or whatever: the two magic methods figure this out by themselves. * you don't have to specify how the data is fetched in the first place. giving the a URI to the `createMagicDataSource` function is enough. * additional instances of the component don't fetch the data again * updates are efficient: the sync method only exchanges exactly the data required, only the minimal visual updates are performed * marking feeds as "seen" by the user is also done by magic and syncs across devices (same for other non-ephemeral ui state). Now: And I'm sure you'd agree that we are not there yet technologically. But I hope you agree that this would be really nice.
- machiaweliczny 6y ago
  Apollo client and Elixir LiveView are solving most of these.
  - 6y ago
dillondoyle 6y ago
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.
whateveracct 6y ago
> 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-a-library-for-haskell/ https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...
yrio 6y ago
How does Ember.js compare to Angular? Both seems to aim to be a complete solution / batteries included. (I'm not familiar with Ember.js)
- karmelapple 6y ago
  We chose Ember over Angular years ago, and we’re happy with the experience. Always hope more people will try it out - I hope you do!

by heipei 6y ago

batoure 6y ago

What this person said! ^ 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..

chrisco255 6y ago
Of course it does, because GraphQL allows you to roll up queries for separate entities and get the data back for those in a single HTTP request. And that capability is something Relay and Apollo take advantage of. In this way a component can reference only the data it needs and the query rollup and caching happens automatically.

lxe 6y ago

I actually think the problems outlined are pretty valid. 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.

derefr 6y ago
"You have to subscribe to something batteries-included, like Meteor, or otherwise implement the solutions yourself from bits and pieces." ...yes; that is, in fact, the conceptual dichotomy in solutions to essentially-complex problems. Either someone else solves them for you, or you have to solve them yourself. I mean, yes, there is a part of the solution-space in-between these two extremes — a point where there's a batteries-included thing that someone else built but then gives away for free, perhaps as an open-source project you just have to run on your own infra. So it's mostly solved for you, and then you just do a little bit to "get the solution running" for your use-case. That point in solution-space is conspicuously absent for web data sync. But, in domains with essential complexity, that middle-ground part of the solution-space is usually conspicuously absent. Because it takes continuous dedicated effort (i.e. labor; capital expenditure) to solve the complex problem in a cleanly-abstracted way. And it's very rare that anyone's going to go to the effort, unless they expect a return on their labor investment (by e.g. keeping the solution proprietary, and building a SaaS business around it.)

pferdone 6y ago

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. :(

bcherny 6y ago
Sorry if it was unclear, but my argument is that while many libraries solve pieces of the problem, no one library (or standard) solves all, or even most, of these.
mewpmewp2 6y ago
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.

bcherny 6y ago

Author here. Data fetching, caching, consistency, and UX are all closely related. If you treat them as separate problems, you're punting the problem onto product engineers, who won't solve it well. (See the last paragraph of the post, which suggests this same idea.) > That is state management, yeah, and you can build proper state management with any HTTP library and any message serialisation format. You're right that to do this manually it's just state management. But to automatically update the UI, it means your client data layer (eg. Apollo) needs to know & track the identity of fields; the data layer also needs to be able to subscribe to fetches anywhere in your app, not local fetches; it also means your protocol needs to support this identity (via agreed-upon ID fields); etc. These problems are all closely related. > Request batching: How would that happen "automatically"? By waiting to fire requests and then batching them? eg. Relay does this by statically combining requests throughout a React tree into a single request at the top of the tree. You could also do it dynamically, as you suggest. The tradeoff is often performance. > UX when fetching data Having engineers manually define loading states doesn't scale. React is approaching this problem with Suspense, and you could imagine standard loading states when fetches are in flight.

austincheney 6y ago
State management, for anybody half competent, is stupid easy and not tied to the UI. State management is a data storage/retrieval problem only. Once the UI has the state information it needs you can populate it for the user however you want in many different ways. State management is also proclaimed as something it isn’t because web UI is full of incompetent expert beginners who can’t write two lines of original code and are helplessly mortified if their colossal framework is taken away. Here is simple web UI state management: * have a centrally available object in the UI code that stores state data. * store that data upon change. That storage can be localStorage for maximum simplicity. It can also be a locally written file if you have a local running service or an http server. The further away from the local computer that storage location becomes the slower it is regardless of access mechanism. * state changes can occur from user interaction or system updates to remote data. Most important are user interactions because that data is locally available. Keep up with remote system changes as best you can, but unless you own that data as well it’s a window into some distant concern. * when state changes update your central state object save the changed state object. Most of the time UI developers are only concerned with state updates and not saving state because they don’t know what they are doing and hope the framework does everything (or it must obviously be unnecessary). * once the state object is updated, and optionally saved, update the UI. For most UI developers updating the UI is the ultimate and only struggle. This is such a junior level basic required skill for UI developers. Knowing that you can root out the incompetent people during hiring. But but but what about 2 way data binding... Treat it as an event. Update the central state store. Process the change. Still simple and no framework is needed.

Garlef 6y ago

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 data. I think the central point of the post now is that we don't have a satisfying technical solution for this situation. Let's take a look at one of the points you mentioned. Maybe you might find there's actually some valid points in the post and give it a more favourable reread. > UX when fetching data: What does that have to do with any of the above? Here, the author of the post writes: "It’s a big burden for engineers to have to manually add loading spinners and error states, and engineers often forget." I think it's more or less clear how you could implement this using only plain vanilla js. Cumbersome but doable: A very manual, imperative process. Now let's envision a technology from a possible future: const twitterFeed = createMagicDataSource("https://twitter.com/...") const feedComponent = magicRendererComponent(twitterFeed, state => /* HTML like declarative description of the visuals */) Imagine this was everything you had write in your code to get the following: * state gets automatically loaded when the first instance of the component is created * updates are automatically visualized in the client based on the internals of the declaration in the renderer * you don't have to specify if the updates are done by polling, websockets or whatever: the two magic methods figure this out by themselves. * you don't have to specify how the data is fetched in the first place. giving the a URI to the `createMagicDataSource` function is enough. * additional instances of the component don't fetch the data again * updates are efficient: the sync method only exchanges exactly the data required, only the minimal visual updates are performed * marking feeds as "seen" by the user is also done by magic and syncs across devices (same for other non-ephemeral ui state). Now: And I'm sure you'd agree that we are not there yet technologically. But I hope you agree that this would be really nice.

machiaweliczny 6y ago
Apollo client and Elixir LiveView are solving most of these.
- 6y ago

dillondoyle 6y ago

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.

whateveracct 6y ago

> 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-a-library-for-haskell/ https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...

yrio 6y ago

How does Ember.js compare to Angular? Both seems to aim to be a complete solution / batteries included. (I'm not familiar with Ember.js)

karmelapple 6y ago
We chose Ember over Angular years ago, and we’re happy with the experience. Always hope more people will try it out - I hope you do!