11 ms·

> React was meant to be a way to provide snappy page loads and UX. This is a very common misconception. React was meant to provide one-way data flow. With an a

• bell_tower 3y ago
  Unfortunately people do not find out what it was meant for, before they start writing about it
  • 88913527 3y ago
    We're at the point where many newer engineers haven't had real hands-on DOM experience but are expected to deliver applications built in React. You need to know at least one level abstraction below your current one to use the tool effectively. This all tracks with how the industry's changed, how we hire, how we train, and so on.
    • eru 3y ago
      > You need to know at least one level abstraction below your current one to use the tool effectively. I'm not sure that's true in general. For example, for some tools there's no single 'one level abstraction below'. Let's take regular expressions as a simple example. You can use them effectively, no matter whether your regular expression matcher uses NFAs or Brzozowski derivatives under the hood as the 'one level [of] abstraction below'. (Just be careful, if your regular expression matcher uses backtracking, you might get pathological behaviour. Though memoisation makes that less likely to hit by accident in practice.)
      • supriyo-biswas 3y ago
        Regular expressions are probably not a good example because you will eventually write a regex that has catastrophic backtracking behavior. I encountered one a few months ago, so it’s not at all uncommon or difficult to encounter. If you’re curious enough, you’d end up reading about how regexes work under the hood. A better example might be that of a compiler, where you (very rarely) need to look at the asm output or encounter a case where the compiler generates incorrect code and you need to debug why.
        • eru 3y ago
          > Regular expressions are probably not a good example because you will eventually write a regex that has catastrophic backtracking behavior. Nope, that will never happen to me. No regular expression has that behaviour. There are some bad implementations of regular expression matching that have these problems for some regular expressions. But you can avoid those bad implementations without understanding anything. > I encountered one a few months ago, so it’s not at all uncommon or difficult to encounter. That only happens, if you use a regular expression matcher that uses backtracking. Sane regular expression matchers take linear time on all input strings. > If you’re curious enough, you’d end up reading about how regexes work under the hood. There's no one single way regular expressions work under the hood. You had the misfortune of using a matcher that uses backtracking and is prone to catastrophic exponential runtimes. There's multiple different ways to implement regular expression matchers. But a user doesn't have to care or understand anything (they just need to avoid the buggy ones). Sure, if you read up on how regular expressions work under the hood, you can learn to avoid those bad matchers. (Or you can learn how to live with your batch implementation, if you are feeling masochistic.) But that's entirely optional: You only need to read one blog post that tells you to use grep and avoid eg Perl. You don't need to understand why backtracking is bad for regular expression matching; as long as you avoid those bad matchers.
          • supriyo-biswas 3y ago
            I’m not sure if this response was simply for the sake of replying, with the claims of writing perfect code all the time or how backtracking implementation is uncommon or insane (most languages use backtracking implementations of regexes).
  • treflop 3y ago
    People start using React as part of a larger framework or existing app and they associate all these unrelated things to React. Also, the poster says this line: > Finding a dev who actually groks the gap between useEffect and useMemo, error boundaries, hook based fetching or my (un)favourite, authentication, is difficult. But truthfully the problems those constructs solve are problems in every paradigm. If you can’t grasp the difference these things despite being a heavy user of a library, you may… want to spend some time reading the docs at some point.
  • coldtea 3y ago
    Unfortunately all the early was advocacy focused on how the virtual DOM is "faster", so the people are fully excused for not finding out "what it was meant for". The "UI as a function of state" was not just sold as "more functional/simpler", but also as a necessity to have a DOM diffing algorithm to minimize updates and be "faster".
• ethanbond 3y ago
  This was super informative, thanks for writing it up!
• symaxian 3y ago
  Yeah, I cannot count how many times I've seen it claimed that the virtual DOM is the secret to why React(or another framework) is fast, completely missing the point of the virtual DOM. The virtual DOM is not faster than performing direct mutations of the actual DOM, the virtual DOM is a tool that allows the normally slow approach of "blow away and rebuild the world" to be fast enough to put into use.
  • throwaway11460 3y ago
    Virtual DOM used to be faster than DOM. DOM operations were really slow back when React came out, and the usual componentization approach of replacing entire blocks of code with new HTML strings used to lock up the browser. React made it possible to effortlessly reuse previous state DOM nodes.
    • Osmose 3y ago
      Your second statement that the virtual DOM lets you skip unnecessary DOM mutations is true, but the first statement is inaccurate because "DOM" is not equivalent to "regenerate and replace all the DOM nodes with updated ones". Prior to React, performant apps that weren't using frameworks that regenerated the entire DOM tree would simply manually mutate the DOM nodes based on what it was doing. If your app was loading a new comment, it would find the list of comment nodes and append a new one to it, same as a virtual DOM would. The problem is that this could be error-prone in large apps—are you even sure that the comment list is still on the page? If it's not, do you need to add it to the page or is this a completely new view and you're reacting to a network request that finished after the user navigated away from the page? That's the kind of finnicky manual work that React helped simplify, but the performance was the same as an app manually mutating the DOM plus the extra virtual DOM comparisons.
      • throwaway11460 3y ago
        The usual approach used to be to simply replace entire "component" with updated HTML string returned by a function representing that component. Doing what you're saying was not feasible for large apps, that led to unmaintanable spaghetti code and never really worked correctly - imagine you need to add a feature somewhere and then you have to go into all the other components that rely on that internal structure. I am talking about CRMs and other business apps like that, not some light JS to load blog comments.
• latchkey 3y ago
  The one way data binding was also important at the time, for people coming from Angular. It was a way to clearly differentiate the two frameworks.
• songbird23 3y ago
  I dont use react professionally(vanilla) but its ideas of one way data binding and UI is a function of state have continuously been helpful in building predictable apps that doesnt grow too hairy. an app can still grow in complexity as it becomes bigger but the ideas definitely help
• coldtea 3y ago
  >This is a very common misconception Not really a misconception: it was explicitly pushed and advertised as such, most of the advocacy (especially from React fans) at the time React was introduced and started gaining traction was about the virtual DOM being "faster". >React changed things so that the state of the DOM is always derived from your own app's state, which eliminates what turned out to be a pretty tedious and error-prone amount of work in complex web apps. I dunno, I used Redux for a few years, and it was a "pretty tedious and error-prone amount of work in complex web apps" too.
  • the_gipsy 3y ago
    You now had to deal with react instead of the DOM. Mission accomplished.
  • elbear 3y ago
    Controversial opinion: Redux (and the Elm architecture behind it) only works with a typed language like TypeScript (or Elm) which takes away the error-prone part. With good type completion, some of the "pretty tedious" part goes away as well.
    • agos 3y ago
      even with completion it's a lot of busywork: define actions, reducers, etc for every state change
      • pseudocomposer 3y ago
        If you use TypeScript and Thunk, it’s no more work than writing your own state management code on plain JS/TS objects. But you get all the advantages of Redux (dev tools, introspection, replayability, easy persistence and tab sync, etc).
    • cageface 3y ago
      Yeah strong typing is essential. Redux is overkill for small or even medium apps but it's the best tool I've found for dealing with the complexity of larger apps. Having a very clear, inspectable sequence of mutations to all your data becomes very valuable.
• dudefeliciano 3y ago
  don't hooks break the whole concept of one way data binding?
  • Osmose 3y ago
    Nope. The binding is "one-way" in the sense that, when the component state (or props) change, the DOM is updated, but if the DOM changes, the component is not updated. Hooks are a pattern for declaring state, side effects, etc. but they don't materially change this relationship.