19 ms·

What's New in React 18?

146 points by nathias 5y ago

0xFACEFEED 5y ago
Anyone else feel like suspense was a major step in the wrong direction for React? I've noticed so many more cases of applications breaking in difficult-to-track-down ways because of how errors are propagated with suspense. Maybe I just don't "get it".
- sophiebits 5y ago
  Do you mean with React.lazy? Suspense hasn’t been used yet outside of that in released versions of React. Would be curious what specifically you ran into though; it shouldn’t make errors hard to debug.
- ferdowsi 5y ago
  You'd be correct, it's a really unfortunate design decision. The author of CrankJS has a full critique here. https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
- nawgz 5y ago
  Suspense is a pretty weird step into "magic" for a library that has been a pretty damn thin layer on top of JS for so long, I fully agree with that. Using it is somewhat pleasant in terms of terseness, but very unpleasant for the fact I do not have a good understanding of how the lifecycles of the async resource(s) influence the render schedule, which is really the core of React from my perspective
  - deckard1 5y ago
    > weird step into "magic" for a library that has been a pretty damn thin layer on top of JS I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state (i.e. magic). The best way I can describe it is a cousin of dynamic scoping from the bad old LISP days. Back before lexical scoping was invented. So you end up with all these caveats and gotchas. Go look up useRef with useEffect and useCallback. It's all a total clusterfuck. The lifecycle methods weren't perfect. But at least you could understand them. But I lost a lot of respect for React way back when they started fussing with the lifecycle API, a year or two before hooks. Their vDOM abstraction was starting to leak heavily and they were struggling to make sense of it. When people say they like React, I really suspect they mean they like JSX. React, itself, is a mess. Always has been.
    - ironmagma 5y ago
      They’re called “function components,” not “functional”, because they reside within a JS `function` as opposed to a class. The word you’re looking for is side effect. The `use*` family of functions operate as hooks from the component into the renderer, so the renderer can easily see what dependencies a component has. This is accomplished by producing side effects. The lifecycle methods are all well and good but there was an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function by hand when it involves whitelisting all props you want to produce a rerender, which is most of them. People would always write bugs. It’s much easier to create a list of dependencies a la second argument to useEffect.
      - dragonwriter 5y ago
        > It’s much easier to create a list of dependencies a la second argument to useEffect. Even easier to just not do that, either, as in Solid’s version of hooks.
        ironmagma 5y ago
        Honest question, is what you’re referring to this[1] or something else? I’d be interested to see how hooks could work without side effects. [1] https://github.com/ryansolid/component-register-hooks https://github.com/ryansolid/component-register-hooks
        dragonwriter 5y ago
        > Honest question, is what you’re referring to this[1] or something else? I’m talking about Solid, the web framework, which has hooks (they call them “effects”) similar to those in React, but which do not require explicit dependency lists when specifying them. https://www.solidjs.com/tutorial/introduction_effects https://www.solidjs.com/tutorial/introduction_effects
        ironmagma 5y ago
  - recursive 5y ago
    Pretty damn thin layer? The language with its own syntax and build tools? The one with JSX? React is one of the thicker layers I've seen.
    - nawgz 5y ago
      Oh no, JSX that compiles down to the exact set of `new Object` calls you would expect in a tree structure, how can I understand such complexity!? Really, you're kidding yourself if you think React isn't far simpler than Angular or Vue or any of these other frameworks. If you have some different direction in mind, fine, but I doubt it scales
      - recursive 5y ago
        Don't misunderstand. I like JSX. However, that doesn't compel me to call it thin.
        nawgz 5y ago
        I find that strange. For example, I would call Angular or Vue "thick" with their extra templating files and DSLs and two-way binding. I would call React thin because the JSX components you build are transparently just objects, they interact with types super gracefully because components are just classes with a method that returns nested objects, and your code is just invoking JS and producing JS until the React library itself performs the side effect of rendering. I understand that React has abstractions and a heavy scheduling engine and all sorts of complexity, but a React component - the core concept of React - reuses directly JS concepts in place of introducing its own in most situations. That is thin. I admit that if you are just thinking of libraries in general, of course a frontend framework is not "thin", but for a library which enables true composability and reuse, React is so thin compared to is competitors. Which seems a reasonable de facto context for a conversation about React.
        recursive 5y ago
        I don't think it's thin even in that context. For example, invoking a hook comes with a bunch of rules beyond "just javascript". You shouldn't invoke a hook conditionally. You shouldn't invoke a hook in a loop. I've run into state/props mismatches due to the diff resolving differently than I thought it should. It's possible to solve this, but it further breaks the illusion of a thin layer. Maybe it's a different way of thinking, but I don't think two-way binding is inherently thicker. To me, thickness is related to the amount of "mechanism". A handlebars-type templating system seems much thinner to me.
- dexwiz 5y ago
  React started as a nice rendering library. Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript. At the same time people wanted React to be a framework for client side rendering, not the thin layer it was. Stateless components are a good idea, but their implementation as functions and hooks leaves any JS programmer not familiar with React scratching their head. Throwing Promises for Suspense is basically Algebraic Effects. Redux and a million other libraries tried to solve data management, none of them doing it in a classical K/V store. Now every app I touch I have to find its special version of reducers and selectors. I like front end programming and Javascript overall. Components are a nice abstraction, and life cycle hooks make sense in real life contexts. But React reeks of developers who think they are too smart for their day job and want to redefine UI programming just to render a button with an event handler.
  - handrous 5y ago
    Yeah, I started going "well, time to look at the rest of the ecosystem for the Next Thing" with Hooks. Given requirements that meant, to progress, they were going to need to either: 1) Tell devs that sometimes they would simply have to use classes/objects for some components, because certain performance enhancements or state-management would only be available there, or; 2) Partially re-implement objects with really bizarre declaration syntax, in a language that already has objects—shit, its functions are objects, and maybe it's changed but I read the hooks code when it was added and it was just some FIFO property/method queues, rather than tables, tied to a damn object representing your component in React's core state-machine; They chose #2. [EDIT] yes I'm aware that one reason they prominently gave for hooks was that inheritance hierarchies could cause problems in React codebases, but that seems woefully insufficient as a motivation for writing a crippled version of objects/classes that lack the features they had problems with, rather than just telling people "maybe stop hitting yourself?" and continuing to use what the language already provided, which everyone already understood.
    - dexwiz 5y ago
      The thing that blew my mind was React gave a decent abstraction for externally set values vs internally managed values in props/state. And then the community immediately declared State as evil, and boiled the ocean to replace it. All UIs need state. Yes state is bad in most cases and makes programming harder. No abstracting it into 4 different files doesn't make it any clearer. There was an issue with composition in React. HOC didn't scale very well, and Inheritance is almost always Bad (TM). That said, I do think hooks were an esoteric choice versus a more explicit service registration/DI pattern.
- dmitryminkovsky 5y ago
  I thought so too for a while, but after using concurrent mode a bunch I came to agree that the usecases it’s built to support (rendering fallback UIs while async processes occur) actually do belong as first class citizens in the framework. It’s the kind of this you implement yourself over and over again. And often the async processes you’re waiting for are React components themselves to load and parse. I’ve come to like the implementation too. I’m glad to see it mature and I like how they’ve taken their time with it.
- eyelidlessness 5y ago
  Suspense, itself, is somewhere in the range of “uninteresting” to “neutral”, in my opinion. Its direct use case would probably have been better solved by: 1. Providing a general signal to reuse the existing DOM node (or subtree, but that’s less useful) without performing any render logic. 2. Allowing components to use built-in suspension semantics (generators, async/await). The former would have other really useful applications, like partial/selective hydration. The latter is closer to both the language and the original spirit of React, which embraced being close to the language. (Who ever thought “throw a Promise” for meaningful control flow before this?) That said, it’s pretty clear from what React team has discussed since Suspense was introduced that it’s part of a larger strategy. Specifically: React Server Components. They’re laying the groundwork for that now, in stabilizing Suspense SSR. I’m more interested in a less sophisticated solution, but it’s pretty clear RSC is both where React is heading and requires a more opinionated foundation like Suspense. > difficult-to-track-down ways because of how errors are propagated with suspense I suspect this has more to do with concurrent rendering generally, than with Suspense itself. Debugging concurrency is harder in general. React's simplistic top-down rendering model was successful in part because it was simplistic and top-down. - - - All of that may not be justified for your needs! React is positioned for a very specific set of use cases (even if it’s over-used for similar-looking ones). You may find you’re more comfortable in a more simplistic VDOM (and that’s okay!) or a library based on reactivity (if so, and if you’re coming from familiarity with React, I’d suggest giving SolidJS[1] a look; its rendering model is much closer to the DOM). I’ll also mention that I’ve spent more time with Preact than React, and have found its Suspense implementation much easier to work with and debug. 1: https://www.solidjs.com/ https://www.solidjs.com/
peanut_worm 5y ago
I haven’t used React in a while, what does it offer that WebComponents do not?
- ajkjk 5y ago
  React does a lot more than WebComponents. Primarily the reactive programming model of only updating subtrees whose props change, but also an entire parallel tree of state/context updates for propagating data that lives alongside the component hierarchy.
- reidjs 5y ago
  In my experience React, despite its complexity, was always far simpler to use than WebComponents because it has clearer documentation and established patterns. I'm sure WebComponents can do everything React can do, but they do not have anywhere near the ecosystem and developer support you get with React.
- deleted 5y ago
  [deleted]
- CapitaineToinon 5y ago
  There is this article (https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci...) by Rich Harris, creator of Svelte which explains pretty well why he personally doesn't use web components.
  - ravenstine 5y ago
    I feel like everyone has the wrong idea about web components. Perhaps it's in the name. There's no "WebComponent" class on the window object, but there is an HTMLElement you can extend and a `window.customElement` registry for tagName invocation, a thing called a shadow root, and so forth. Those are all things that I am glad exist. If I thought of them grouped together as "Web Components" and compared that to components in frontend JavaScript frameworks then yeah, I guess I'd be disappointed. Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing. Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task. The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.
deleted 5y ago
[deleted]
literallyaduck 5y ago
Any discussion of NextJS and how it would work with the new SSR technologies?
- chrischen 5y ago
  Not sure how NextJS handles async component SSR, but looks like from the docs we should just be able to use React.lazy in place of loadable-components in an SSR render pass now. The new server components seem to be a different feature not directly related to regular SSR usage. I think they added that for people who aren't using GraphQL for data-fetching, so that certain components can be rendered on the server only and set in a serialized form without sending the associated JS required to render it.
Waterluvian 5y ago
I'm pretty delighted by a lot of the concurrency stuff that's popping up. At this very moment I'm wrestling with a UI where the left side is a list of cartographic datasets, and the right side is a rich OpenLayers preview renderer. I want the right side to be "low priority" where it tries to render a preview, but is happy to abort or not get done in-time if the user selects a different dataset. At the moment, the processing acquiring and rendering the preview makes the rest of the UI a bit laggy. I suspect a good bit of my custom code can be replaced with some of this transition stuff.
- stevemk14ebr 5y ago
  You issue is likely due to a heavy computation blocking the main js thread (rendering). In this scenario the suspense api will not solve the UI lag. I've had the exact same pattern with a home build markdown editor where the right side preview should render quick, but lag behind if too heavy and give priority to left hand side. I tried the alpha and speak from my own experiences, you'll have better luck by offloading render computations to a background web worker. The preview can do a 1 time synchronous render, cache the result in it's local component react state, then all future state updates are computed async on the background thread. Main thread left unblocked
  - Waterluvian 5y ago
    It's considerably more complex than that. There's just a lot of stuff that gets compiled and rendered. No single part takes more than a few milliseconds, so I can bin it across many tasks. Picture a canvas that I'm calculating then drawing tens of thousands of elements to before displaying it. Very binnable. Very hard to get right to a point that you can't "feel" the lag when working with the rest of the app. I also explored web workers but it's currently more hassle than I want to be bothered with.
    - pier25 5y ago
      If your use case requires rendering and updating thousands of components, maybe React wasn't a good fit? You could try switching to Preact which has better performance and should be painless. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
kabes 5y ago
Not sure where I stand on this. On one hand function components and hooks give a nice way to extract logic into small reusable bits, way more than with class components. But on the other hand it becomes clear that decent performance with this approach requires all kinds of tricks and each react version adds more and more of these tricks with a steep learning curve. Shame since react started out with a very small, easy to understand API and that is what made it so popular.
- nathias 5y ago
  What are you talking about? How did using classes instead of functions improve performance?
  - handrous 5y ago
    Certain performance improvements and mitigations for common performance problems in something like React require bi-directional interaction of state and state-related events with instances of components. Classes/objects are a pretty natural fit for that, obviously. To do the same with functions, you have to... re-create parts of a class or object system, which is what they did with Hooks. That would be the "all kinds of tricks" the OP referred to. Not that going from one to the other is inherently a win, but that to match the capabilities and ergonomics that classes & objects come with out of the box for addressing state-related performance improvements & state-related features, with "functional" React, you have to resort to "all kinds of tricks", i.e. write your own version of some of the OO things you need to get the job done semi-cleanly (which is exactly what the React team did with Hooks). The result, to put it in only slightly unfair terms, is that React has enabled their community to use a really bad and half-baked OO system with bizarre syntax & behavior, all so that no-one has to use the "class" keyword sometimes. They didn't do that for funzies, but because some of the things they wanted to do, including things related to performance, required OO-like features to be workable, but for whatever reason they didn't want to rely on built-in language features for that, nor tell their community that sometimes they would have to use those built-in language features. Instead they opted for... Hooks.
  - mrloba 5y ago
vjust 5y ago
I like the way they describe SSRs , then talk about hydration - which of course has to lead into interesting videos on compressed towels , and peat pellets!
azangru 5y ago
I have been really annoyed by a recent change in React dev tools. Have you seen this? They hijack browser's console.log method, and report all logged messages as coming from react-dev-tools. Very useful for console.log debugging! Link: https://stackoverflow.com/questions/69071151/why-is-console-log-showing-react-devtools-backend-js4049-instead-of-the-file https://stackoverflow.com/questions/69071151/why-is-console-...

146 points by nathias 5y ago

Anyone else feel like suspense was a major step in the wrong direction for React? I've noticed so many more cases of applications breaking in difficult-to-track-down ways because of how errors are propagated with suspense. Maybe I just don't "get it".

sophiebits 5y ago
Do you mean with React.lazy? Suspense hasn’t been used yet outside of that in released versions of React. Would be curious what specifically you ran into though; it shouldn’t make errors hard to debug.
ferdowsi 5y ago
You'd be correct, it's a really unfortunate design decision. The author of CrankJS has a full critique here. https://crank.js.org/blog/introducing-crank https://crank.js.org/blog/introducing-crank
nawgz 5y ago
Suspense is a pretty weird step into "magic" for a library that has been a pretty damn thin layer on top of JS for so long, I fully agree with that. Using it is somewhat pleasant in terms of terseness, but very unpleasant for the fact I do not have a good understanding of how the lifecycles of the async resource(s) influence the render schedule, which is really the core of React from my perspective
- deckard1 5y ago
  > weird step into "magic" for a library that has been a pretty damn thin layer on top of JS I mean, hooks are totally this. They fundamentally break the concept of a "function" despite calling them "functional components." They use this weird notion of state (i.e. magic). The best way I can describe it is a cousin of dynamic scoping from the bad old LISP days. Back before lexical scoping was invented. So you end up with all these caveats and gotchas. Go look up useRef with useEffect and useCallback. It's all a total clusterfuck. The lifecycle methods weren't perfect. But at least you could understand them. But I lost a lot of respect for React way back when they started fussing with the lifecycle API, a year or two before hooks. Their vDOM abstraction was starting to leak heavily and they were struggling to make sense of it. When people say they like React, I really suspect they mean they like JSX. React, itself, is a mess. Always has been.
  - ironmagma 5y ago
    They’re called “function components,” not “functional”, because they reside within a JS `function` as opposed to a class. The word you’re looking for is side effect. The `use*` family of functions operate as hooks from the component into the renderer, so the renderer can easily see what dependencies a component has. This is accomplished by producing side effects. The lifecycle methods are all well and good but there was an ergonomic problem with them with shouldComponentUpdate. No one wants to implement that function by hand when it involves whitelisting all props you want to produce a rerender, which is most of them. People would always write bugs. It’s much easier to create a list of dependencies a la second argument to useEffect.
    - dragonwriter 5y ago
      > It’s much easier to create a list of dependencies a la second argument to useEffect. Even easier to just not do that, either, as in Solid’s version of hooks.
      - ironmagma 5y ago
        Honest question, is what you’re referring to this[1] or something else? I’d be interested to see how hooks could work without side effects. [1] https://github.com/ryansolid/component-register-hooks https://github.com/ryansolid/component-register-hooks
        dragonwriter 5y ago
        > Honest question, is what you’re referring to this[1] or something else? I’m talking about Solid, the web framework, which has hooks (they call them “effects”) similar to those in React, but which do not require explicit dependency lists when specifying them. https://www.solidjs.com/tutorial/introduction_effects https://www.solidjs.com/tutorial/introduction_effects
        ironmagma 5y ago
- recursive 5y ago
  Pretty damn thin layer? The language with its own syntax and build tools? The one with JSX? React is one of the thicker layers I've seen.
  - nawgz 5y ago
    Oh no, JSX that compiles down to the exact set of `new Object` calls you would expect in a tree structure, how can I understand such complexity!? Really, you're kidding yourself if you think React isn't far simpler than Angular or Vue or any of these other frameworks. If you have some different direction in mind, fine, but I doubt it scales
    - recursive 5y ago
      Don't misunderstand. I like JSX. However, that doesn't compel me to call it thin.
      - nawgz 5y ago
        I find that strange. For example, I would call Angular or Vue "thick" with their extra templating files and DSLs and two-way binding. I would call React thin because the JSX components you build are transparently just objects, they interact with types super gracefully because components are just classes with a method that returns nested objects, and your code is just invoking JS and producing JS until the React library itself performs the side effect of rendering. I understand that React has abstractions and a heavy scheduling engine and all sorts of complexity, but a React component - the core concept of React - reuses directly JS concepts in place of introducing its own in most situations. That is thin. I admit that if you are just thinking of libraries in general, of course a frontend framework is not "thin", but for a library which enables true composability and reuse, React is so thin compared to is competitors. Which seems a reasonable de facto context for a conversation about React.
        recursive 5y ago
        I don't think it's thin even in that context. For example, invoking a hook comes with a bunch of rules beyond "just javascript". You shouldn't invoke a hook conditionally. You shouldn't invoke a hook in a loop. I've run into state/props mismatches due to the diff resolving differently than I thought it should. It's possible to solve this, but it further breaks the illusion of a thin layer. Maybe it's a different way of thinking, but I don't think two-way binding is inherently thicker. To me, thickness is related to the amount of "mechanism". A handlebars-type templating system seems much thinner to me.
dexwiz 5y ago
React started as a nice rendering library. Then it was infected with all sorts of Functional Programming paradigms grafted on top of Javascript. At the same time people wanted React to be a framework for client side rendering, not the thin layer it was. Stateless components are a good idea, but their implementation as functions and hooks leaves any JS programmer not familiar with React scratching their head. Throwing Promises for Suspense is basically Algebraic Effects. Redux and a million other libraries tried to solve data management, none of them doing it in a classical K/V store. Now every app I touch I have to find its special version of reducers and selectors. I like front end programming and Javascript overall. Components are a nice abstraction, and life cycle hooks make sense in real life contexts. But React reeks of developers who think they are too smart for their day job and want to redefine UI programming just to render a button with an event handler.
- handrous 5y ago
  Yeah, I started going "well, time to look at the rest of the ecosystem for the Next Thing" with Hooks. Given requirements that meant, to progress, they were going to need to either: 1) Tell devs that sometimes they would simply have to use classes/objects for some components, because certain performance enhancements or state-management would only be available there, or; 2) Partially re-implement objects with really bizarre declaration syntax, in a language that already has objects—shit, its functions are objects, and maybe it's changed but I read the hooks code when it was added and it was just some FIFO property/method queues, rather than tables, tied to a damn object representing your component in React's core state-machine; They chose #2. [EDIT] yes I'm aware that one reason they prominently gave for hooks was that inheritance hierarchies could cause problems in React codebases, but that seems woefully insufficient as a motivation for writing a crippled version of objects/classes that lack the features they had problems with, rather than just telling people "maybe stop hitting yourself?" and continuing to use what the language already provided, which everyone already understood.
  - dexwiz 5y ago
    The thing that blew my mind was React gave a decent abstraction for externally set values vs internally managed values in props/state. And then the community immediately declared State as evil, and boiled the ocean to replace it. All UIs need state. Yes state is bad in most cases and makes programming harder. No abstracting it into 4 different files doesn't make it any clearer. There was an issue with composition in React. HOC didn't scale very well, and Inheritance is almost always Bad (TM). That said, I do think hooks were an esoteric choice versus a more explicit service registration/DI pattern.
dmitryminkovsky 5y ago
I thought so too for a while, but after using concurrent mode a bunch I came to agree that the usecases it’s built to support (rendering fallback UIs while async processes occur) actually do belong as first class citizens in the framework. It’s the kind of this you implement yourself over and over again. And often the async processes you’re waiting for are React components themselves to load and parse. I’ve come to like the implementation too. I’m glad to see it mature and I like how they’ve taken their time with it.
eyelidlessness 5y ago
Suspense, itself, is somewhere in the range of “uninteresting” to “neutral”, in my opinion. Its direct use case would probably have been better solved by: 1. Providing a general signal to reuse the existing DOM node (or subtree, but that’s less useful) without performing any render logic. 2. Allowing components to use built-in suspension semantics (generators, async/await). The former would have other really useful applications, like partial/selective hydration. The latter is closer to both the language and the original spirit of React, which embraced being close to the language. (Who ever thought “throw a Promise” for meaningful control flow before this?) That said, it’s pretty clear from what React team has discussed since Suspense was introduced that it’s part of a larger strategy. Specifically: React Server Components. They’re laying the groundwork for that now, in stabilizing Suspense SSR. I’m more interested in a less sophisticated solution, but it’s pretty clear RSC is both where React is heading and requires a more opinionated foundation like Suspense. > difficult-to-track-down ways because of how errors are propagated with suspense I suspect this has more to do with concurrent rendering generally, than with Suspense itself. Debugging concurrency is harder in general. React's simplistic top-down rendering model was successful in part because it was simplistic and top-down. - - - All of that may not be justified for your needs! React is positioned for a very specific set of use cases (even if it’s over-used for similar-looking ones). You may find you’re more comfortable in a more simplistic VDOM (and that’s okay!) or a library based on reactivity (if so, and if you’re coming from familiarity with React, I’d suggest giving SolidJS[1] a look; its rendering model is much closer to the DOM). I’ll also mention that I’ve spent more time with Preact than React, and have found its Suspense implementation much easier to work with and debug. 1: https://www.solidjs.com/ https://www.solidjs.com/

peanut_worm 5y ago

I haven’t used React in a while, what does it offer that WebComponents do not?

ajkjk 5y ago
React does a lot more than WebComponents. Primarily the reactive programming model of only updating subtrees whose props change, but also an entire parallel tree of state/context updates for propagating data that lives alongside the component hierarchy.
reidjs 5y ago
In my experience React, despite its complexity, was always far simpler to use than WebComponents because it has clearer documentation and established patterns. I'm sure WebComponents can do everything React can do, but they do not have anywhere near the ecosystem and developer support you get with React.
deleted 5y ago
[deleted]
CapitaineToinon 5y ago
There is this article (https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci...) by Rich Harris, creator of Svelte which explains pretty well why he personally doesn't use web components.
- ravenstine 5y ago
  I feel like everyone has the wrong idea about web components. Perhaps it's in the name. There's no "WebComponent" class on the window object, but there is an HTMLElement you can extend and a `window.customElement` registry for tagName invocation, a thing called a shadow root, and so forth. Those are all things that I am glad exist. If I thought of them grouped together as "Web Components" and compared that to components in frontend JavaScript frameworks then yeah, I guess I'd be disappointed. Otherwise, the people who say they "don't use" web components are being as unreasonable as it would be to say to not use the `<video>` element because it doesn't support all the things that `<canvas>` does with some 3rd party library for compositing. Custom elements are awesome for small things that don't need to appear in an SSR context (assuming you're using shadow DOMs). No, they don't support composable stylesheets, whatever those even are, but seriously, who really needs them? If what you are doing is complicated enough that the browser's native APIs are too obtuse then yeah go for something like React or Svelte. No matter what, there's going to be something that someone's JavaScript library is going to do better than the browser. I'd use uncommon browser and language features if they made sense for a task. The `<template>` and `<slot>` elements are really dopey and hard to understand. That's where something like React or Svelte comes in. Nobody would use either of those libraries if they didn't have better templating than the browser.

deleted 5y ago

[deleted]

literallyaduck 5y ago

Any discussion of NextJS and how it would work with the new SSR technologies?

chrischen 5y ago
Not sure how NextJS handles async component SSR, but looks like from the docs we should just be able to use React.lazy in place of loadable-components in an SSR render pass now. The new server components seem to be a different feature not directly related to regular SSR usage. I think they added that for people who aren't using GraphQL for data-fetching, so that certain components can be rendered on the server only and set in a serialized form without sending the associated JS required to render it.

Waterluvian 5y ago

I'm pretty delighted by a lot of the concurrency stuff that's popping up. At this very moment I'm wrestling with a UI where the left side is a list of cartographic datasets, and the right side is a rich OpenLayers preview renderer. I want the right side to be "low priority" where it tries to render a preview, but is happy to abort or not get done in-time if the user selects a different dataset. At the moment, the processing acquiring and rendering the preview makes the rest of the UI a bit laggy. I suspect a good bit of my custom code can be replaced with some of this transition stuff.

stevemk14ebr 5y ago
You issue is likely due to a heavy computation blocking the main js thread (rendering). In this scenario the suspense api will not solve the UI lag. I've had the exact same pattern with a home build markdown editor where the right side preview should render quick, but lag behind if too heavy and give priority to left hand side. I tried the alpha and speak from my own experiences, you'll have better luck by offloading render computations to a background web worker. The preview can do a 1 time synchronous render, cache the result in it's local component react state, then all future state updates are computed async on the background thread. Main thread left unblocked
- Waterluvian 5y ago
  It's considerably more complex than that. There's just a lot of stuff that gets compiled and rendered. No single part takes more than a few milliseconds, so I can bin it across many tasks. Picture a canvas that I'm calculating then drawing tens of thousands of elements to before displaying it. Very binnable. Very hard to get right to a point that you can't "feel" the lag when working with the rest of the app. I also explored web workers but it's currently more hassle than I want to be bothered with.
  - pier25 5y ago
    If your use case requires rendering and updating thousands of components, maybe React wasn't a good fit? You could try switching to Preact which has better performance and should be painless. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...

kabes 5y ago

Not sure where I stand on this. On one hand function components and hooks give a nice way to extract logic into small reusable bits, way more than with class components. But on the other hand it becomes clear that decent performance with this approach requires all kinds of tricks and each react version adds more and more of these tricks with a steep learning curve. Shame since react started out with a very small, easy to understand API and that is what made it so popular.

nathias 5y ago
What are you talking about? How did using classes instead of functions improve performance?
- handrous 5y ago
  Certain performance improvements and mitigations for common performance problems in something like React require bi-directional interaction of state and state-related events with instances of components. Classes/objects are a pretty natural fit for that, obviously. To do the same with functions, you have to... re-create parts of a class or object system, which is what they did with Hooks. That would be the "all kinds of tricks" the OP referred to. Not that going from one to the other is inherently a win, but that to match the capabilities and ergonomics that classes & objects come with out of the box for addressing state-related performance improvements & state-related features, with "functional" React, you have to resort to "all kinds of tricks", i.e. write your own version of some of the OO things you need to get the job done semi-cleanly (which is exactly what the React team did with Hooks). The result, to put it in only slightly unfair terms, is that React has enabled their community to use a really bad and half-baked OO system with bizarre syntax & behavior, all so that no-one has to use the "class" keyword sometimes. They didn't do that for funzies, but because some of the things they wanted to do, including things related to performance, required OO-like features to be workable, but for whatever reason they didn't want to rely on built-in language features for that, nor tell their community that sometimes they would have to use those built-in language features. Instead they opted for... Hooks.
- mrloba 5y ago

vjust 5y ago

I like the way they describe SSRs , then talk about hydration - which of course has to lead into interesting videos on compressed towels , and peat pellets!

azangru 5y ago

I have been really annoyed by a recent change in React dev tools. Have you seen this? They hijack browser's console.log method, and report all logged messages as coming from react-dev-tools. Very useful for console.log debugging! Link: https://stackoverflow.com/questions/69071151/why-is-console-log-showing-react-devtools-backend-js4049-instead-of-the-file https://stackoverflow.com/questions/69071151/why-is-console-...