6 ms·

These frameworks should be architected to support async/await scenarios natively instead of all these convoluted workarounds. Promises/async have ben around lon

These frameworks should be architected to support async/await scenarios natively instead of all these convoluted workarounds. Promises/async have ben around long enough. EDIT: JS is already dynamic. If a function returns a promise then it should be awaited and render blank or nothing in the vdom. This is obvious, except in JS where architecture prefers synchronous-only design with async being an afterthought.

arcticfox 7y ago
React's prioritization of features has led to it being one of the most successful frameworks of all time, I'm not sure how useful it is to suggest they should have started with this from the beginning. It's been overwhelmingly successful without this feature.
- manigandham 7y ago
  It's popular so it's fine? The massive number of async-related workarounds, libraries, tooling and code practices says otherwise. jQuery is even more popular btw. It's the general state of Javascript and frontend code which is finally starting to understand what multithreading and concurrency is.
  - ng12 7y ago
    JavaScript is not multithreaded.
    - manigandham 7y ago
      Javascript as a language isn't, but Javascript code can use multiple threads in various ways.
      - ng12 7y ago
        And you're implying asynchronous coding is new to JavaScript developers?
        deleted 7y ago
        [deleted]
        manigandham 7y ago
        As default architecture? Yes.
        ng12 7y ago
        I'd like to see some evidence to back that up. The event loop is one of the few things JavaScript did correctly and it's baked into everything but the most trivial of applications.
        manigandham 7y ago
        I'll refer to my quote: "The massive number of async-related workarounds, libraries, tooling and code practices says otherwise." It's surprising that JS has so much history with callbacks and events but async methods are unsupported or require workarounds by so many core frameworks and libraries which default to synchronous APIs for everything.
  - paavohtl 7y ago
    jQuery is not an UI framework. It's a library of utilities for DOM querying and manipulation.
    - manigandham 7y ago
      The point being popularity has nothing to do with architecture.
- dosy 7y ago
  The illogical adoption of React must not be questioned, even in the face of its poor performance and ugly syntax. One must never note that perhaps it is simply a cultish adoration, or faddish adherence to popular mass opinions, that leads to "popularity" mattering more than practicality. So what if React is massively bloated, stupid syntax, can't use regular HTML, can't use regular CSS, can't use async/await, have to do everything a special way...literally, SO WHAT. It IS REACT! OMG behold it's glory. It came from FB, maybe if we use it we can scale like FB! Omg the idiocy. But keep on slavishly following the next front-end dev trend. I can't tell whether front-end dev culture is a massive circle-jerk or cargo cult. And don't mention the irrational hate attempted to be heaped onto anyone who dares question the programmatic thinking of the official line of the React Appreciation Society.
  - hombre_fatal 7y ago
    Is there anything more in-bad-faith than assuming everyone who uses X is just an idiot, trend-follower, or beginner? Unlike you, the Enlightened One? Why not just ask people why they use X? Plenty of veteran developers on HN could tell you why they like React despite a sea of alternatives, but it's easier to just cast aspersions instead of understanding. It's a shame to see this on HN which is supposedly a community of craftspeople who build things. If you can only come up with insults for why another group of people do something, it's time for you to get up off your ass and ask someone in that group. And this extends beyond just engineering, it's how you understand other people in general.
    - dosy 7y ago
      That's a bit mean, don't you think? See I was addressing a group of people but you're directly saying that to me. Hmmm, well, why don't you take your own advice pal and ask me why I think so? Oh, that's right, I guess you were just trying to insult people rather than understand. Hahahaa. But anyway, I am thoroughly enjoying your attempt at self-righteousness. Keep working on that, you've nearly got it. And I'm very grateful to you for proving my point. You may be old, but are you sure I don't understand people and you do? I don't think "bad faith" means what you think it means, but I take it by the vehemence of your response that I struck a nerve. And I think you might just be projecting. See, I think you're angry because you must use React, and me reminding you other choices exist, which you nevertheless cannot access, reminds you of that embarrassing lack of freedom. So you choose to double down on defending something you don't really want anyway. But I guess you don't really understand how you feel about it, so you just project and blame somebody else. If you didn't like React, would you ever say no to an offer that insisted on it? See, I don't think you would. But I have. I wanna work with what I like. I think if you really loved it and knew why you wouldn't be so perturbed. I'm just curious, why no submissions? Why anonymous? Would you talk so big, if everyone knew your name? Or are you only a loud mouth if you've got no skin in the game, really? Anyway, have a good day thinkin about that, pal and if you wanna know more please read my answer for "debuzzybee" and my comment she linked.
aocenas 7y ago
I think the problem is there is no good cancelation functionality in promises/await. Generator functions could work, not sure if the issue was support or that generator syntax is not that familiar to JS devs.
megous 7y ago
Both promises and async/await (basivally just a syntactic sugar for promises) are pretty unpleasant to use in a more complex app. It's too low-level and hard to manage (if you care about correctness and performance). You eventually have to invent your own locking (to enforce ordering guarantees between read/update remote calls) and do resource management by hand (async task becomes something you have to keep track of, in case you need to abort/restart it, recover from network errors, etc.) There are much better abstractions for getting remote data. State machines are one such abstraction that I like to use. I'm still awaiting the day when web devs rediscover that coding an event driven FSM with pure functions is acctually the most flexible and easiest to reason about way to manage client-server communication. Meanwhile it's my secret sauce.
- kilburn 7y ago
  Aren't reducer-based stores (redux, useReducer) effectively "FSMs with pure functions"? These have been quite popular since very early in React's history. Am I missing something?
  - megous 7y ago
    Yes, but those don't help manage async fetch jobs.
- manigandham 7y ago
  State machines is what async/await and promises are. They're higher-level constructs built on the concept of iterators (with yield/generator being the lower-level), and the async syntax was designed for easy code flow without having to think about callbacks. There's no reason why these frameworks have to treat async functions as a special case. If the promise hasn't resolved then don't render that node. The fact that it was ever blocking is just a byproduct of sync-only thinking. This is extremely common in JS where libraries are designed around sync first and have workarounds to support async.
  - megous 7y ago
    That may be an implementation detail, but to a programmer, promises and thus async/await are just a resource that represents some background operation with some side effect attached to some undetermined time in the future when the promise settles, if ever. You get a reference to it and it's a resource to manage manually. You need to ensure that the side effect you attached to it at one time will not mess up anything in the future, despite not knowing in what situatuion in the future it will be resolving. User might have done many other operations with tha app in the meantime, etc. You may also want to carry around an AbortController, in case you may need to cancel the operation behind the promise (like a fetch). So promises are just references to some resources. Async functions actually make the management of async jobs harder, since you're basically encoding a sequence of jobs into the structure of the functions you define and you don't even see the promises behind those, and you'll not have control over their execution from the outside, unless you explicitly code for it at every point. You don't get to say: ok, whatever's going on now with all my data fetching async functions that may be currently running, I want to pause them in whatever state they may be now. Or cancel them right now, or restart them from where I paused them. With explicitely coded FSM, you can do any of this, easily.
danabramov 7y ago
The article has a section that addresses exactly this point: https://reactjs.org/docs/concurrent-mode-suspense.html#race-conditions-with-componentdidupdate https://reactjs.org/docs/concurrent-mode-suspense.html#race-... Hope this is helpful.
- manigandham 7y ago
  The issue is that the lifecycle methods themselves aren't async right? Async is viral so it would have to be throughout the library, which was my point about it being bolted on instead of the starting point. Wouldn't making the lifecycle methods async not fix this?
  - danabramov 7y ago
    I don't know what "making the lifecycle methods async" means. What are the concrete semantics you are proposing?
    - manigandham 7y ago
      I guess I would have to dig in further into the runtime but is there a reason why methods like `componentDidMount` can't be async themselves? If the entire runtime was async then wouldn't that naturally allow any other user/component level async calls to naturally work as expected?
      - danabramov 7y ago
        What would it mean to "make them async"? You're kind of hand waving the gnarly details from which everything else follows. In some way, Suspense is "making them async" btw. Or, rather, making render async. So maybe we're talking about the same thing.
        manigandham 7y ago
        I'm unsure how to explain so I'll use an example: when C# released async/await, a common complaint was that async functions could only be called if the parent/calling function is also made async, which meant any of its parent functions also had to become async, and so on. It spreads virally until the entire entrypoint for the program had to be async too. If the React runtime was completely async (as in returning promises for every function) from the `ReactDom.Render()` to the lifecycle methods to render(), then user code can transparently support any `await fetchSomeData()` calls. Basically change every method from: f(x) => T; into: async f(x) => Promise<T>; I believe the major change would be the runtime checking if the render() promise was resolved or not, and skipping the component if it wasn't. Am I completely off base here?

arcticfox 7y ago

React's prioritization of features has led to it being one of the most successful frameworks of all time, I'm not sure how useful it is to suggest they should have started with this from the beginning. It's been overwhelmingly successful without this feature.

manigandham 7y ago
It's popular so it's fine? The massive number of async-related workarounds, libraries, tooling and code practices says otherwise. jQuery is even more popular btw. It's the general state of Javascript and frontend code which is finally starting to understand what multithreading and concurrency is.
- ng12 7y ago
  JavaScript is not multithreaded.
  - manigandham 7y ago
    Javascript as a language isn't, but Javascript code can use multiple threads in various ways.
    - ng12 7y ago
      And you're implying asynchronous coding is new to JavaScript developers?
      - deleted 7y ago
        [deleted]
      - manigandham 7y ago
        As default architecture? Yes.
        ng12 7y ago
        I'd like to see some evidence to back that up. The event loop is one of the few things JavaScript did correctly and it's baked into everything but the most trivial of applications.
        manigandham 7y ago
        I'll refer to my quote: "The massive number of async-related workarounds, libraries, tooling and code practices says otherwise." It's surprising that JS has so much history with callbacks and events but async methods are unsupported or require workarounds by so many core frameworks and libraries which default to synchronous APIs for everything.
- paavohtl 7y ago
  jQuery is not an UI framework. It's a library of utilities for DOM querying and manipulation.
  - manigandham 7y ago
    The point being popularity has nothing to do with architecture.
dosy 7y ago
The illogical adoption of React must not be questioned, even in the face of its poor performance and ugly syntax. One must never note that perhaps it is simply a cultish adoration, or faddish adherence to popular mass opinions, that leads to "popularity" mattering more than practicality. So what if React is massively bloated, stupid syntax, can't use regular HTML, can't use regular CSS, can't use async/await, have to do everything a special way...literally, SO WHAT. It IS REACT! OMG behold it's glory. It came from FB, maybe if we use it we can scale like FB! Omg the idiocy. But keep on slavishly following the next front-end dev trend. I can't tell whether front-end dev culture is a massive circle-jerk or cargo cult. And don't mention the irrational hate attempted to be heaped onto anyone who dares question the programmatic thinking of the official line of the React Appreciation Society.
- hombre_fatal 7y ago
  Is there anything more in-bad-faith than assuming everyone who uses X is just an idiot, trend-follower, or beginner? Unlike you, the Enlightened One? Why not just ask people why they use X? Plenty of veteran developers on HN could tell you why they like React despite a sea of alternatives, but it's easier to just cast aspersions instead of understanding. It's a shame to see this on HN which is supposedly a community of craftspeople who build things. If you can only come up with insults for why another group of people do something, it's time for you to get up off your ass and ask someone in that group. And this extends beyond just engineering, it's how you understand other people in general.
  - dosy 7y ago
    That's a bit mean, don't you think? See I was addressing a group of people but you're directly saying that to me. Hmmm, well, why don't you take your own advice pal and ask me why I think so? Oh, that's right, I guess you were just trying to insult people rather than understand. Hahahaa. But anyway, I am thoroughly enjoying your attempt at self-righteousness. Keep working on that, you've nearly got it. And I'm very grateful to you for proving my point. You may be old, but are you sure I don't understand people and you do? I don't think "bad faith" means what you think it means, but I take it by the vehemence of your response that I struck a nerve. And I think you might just be projecting. See, I think you're angry because you must use React, and me reminding you other choices exist, which you nevertheless cannot access, reminds you of that embarrassing lack of freedom. So you choose to double down on defending something you don't really want anyway. But I guess you don't really understand how you feel about it, so you just project and blame somebody else. If you didn't like React, would you ever say no to an offer that insisted on it? See, I don't think you would. But I have. I wanna work with what I like. I think if you really loved it and knew why you wouldn't be so perturbed. I'm just curious, why no submissions? Why anonymous? Would you talk so big, if everyone knew your name? Or are you only a loud mouth if you've got no skin in the game, really? Anyway, have a good day thinkin about that, pal and if you wanna know more please read my answer for "debuzzybee" and my comment she linked.

aocenas 7y ago

I think the problem is there is no good cancelation functionality in promises/await. Generator functions could work, not sure if the issue was support or that generator syntax is not that familiar to JS devs.

megous 7y ago

Both promises and async/await (basivally just a syntactic sugar for promises) are pretty unpleasant to use in a more complex app. It's too low-level and hard to manage (if you care about correctness and performance). You eventually have to invent your own locking (to enforce ordering guarantees between read/update remote calls) and do resource management by hand (async task becomes something you have to keep track of, in case you need to abort/restart it, recover from network errors, etc.) There are much better abstractions for getting remote data. State machines are one such abstraction that I like to use. I'm still awaiting the day when web devs rediscover that coding an event driven FSM with pure functions is acctually the most flexible and easiest to reason about way to manage client-server communication. Meanwhile it's my secret sauce.

kilburn 7y ago
Aren't reducer-based stores (redux, useReducer) effectively "FSMs with pure functions"? These have been quite popular since very early in React's history. Am I missing something?
- megous 7y ago
  Yes, but those don't help manage async fetch jobs.
manigandham 7y ago
State machines is what async/await and promises are. They're higher-level constructs built on the concept of iterators (with yield/generator being the lower-level), and the async syntax was designed for easy code flow without having to think about callbacks. There's no reason why these frameworks have to treat async functions as a special case. If the promise hasn't resolved then don't render that node. The fact that it was ever blocking is just a byproduct of sync-only thinking. This is extremely common in JS where libraries are designed around sync first and have workarounds to support async.
- megous 7y ago
  That may be an implementation detail, but to a programmer, promises and thus async/await are just a resource that represents some background operation with some side effect attached to some undetermined time in the future when the promise settles, if ever. You get a reference to it and it's a resource to manage manually. You need to ensure that the side effect you attached to it at one time will not mess up anything in the future, despite not knowing in what situatuion in the future it will be resolving. User might have done many other operations with tha app in the meantime, etc. You may also want to carry around an AbortController, in case you may need to cancel the operation behind the promise (like a fetch). So promises are just references to some resources. Async functions actually make the management of async jobs harder, since you're basically encoding a sequence of jobs into the structure of the functions you define and you don't even see the promises behind those, and you'll not have control over their execution from the outside, unless you explicitly code for it at every point. You don't get to say: ok, whatever's going on now with all my data fetching async functions that may be currently running, I want to pause them in whatever state they may be now. Or cancel them right now, or restart them from where I paused them. With explicitely coded FSM, you can do any of this, easily.

danabramov 7y ago

The article has a section that addresses exactly this point: https://reactjs.org/docs/concurrent-mode-suspense.html#race-conditions-with-componentdidupdate https://reactjs.org/docs/concurrent-mode-suspense.html#race-... Hope this is helpful.

manigandham 7y ago
The issue is that the lifecycle methods themselves aren't async right? Async is viral so it would have to be throughout the library, which was my point about it being bolted on instead of the starting point. Wouldn't making the lifecycle methods async not fix this?
- danabramov 7y ago
  I don't know what "making the lifecycle methods async" means. What are the concrete semantics you are proposing?
  - manigandham 7y ago
    I guess I would have to dig in further into the runtime but is there a reason why methods like `componentDidMount` can't be async themselves? If the entire runtime was async then wouldn't that naturally allow any other user/component level async calls to naturally work as expected?
    - danabramov 7y ago
      What would it mean to "make them async"? You're kind of hand waving the gnarly details from which everything else follows. In some way, Suspense is "making them async" btw. Or, rather, making render async. So maybe we're talking about the same thing.
      - manigandham 7y ago
        I'm unsure how to explain so I'll use an example: when C# released async/await, a common complaint was that async functions could only be called if the parent/calling function is also made async, which meant any of its parent functions also had to become async, and so on. It spreads virally until the entire entrypoint for the program had to be async too. If the React runtime was completely async (as in returning promises for every function) from the `ReactDom.Render()` to the lifecycle methods to render(), then user code can transparently support any `await fetchSomeData()` calls. Basically change every method from: f(x) => T; into: async f(x) => Promise<T>; I believe the major change would be the runtime checking if the render() promise was resolved or not, and skipping the component if it wasn't. Am I completely off base here?