9 ms·

RFC: Intent to Ship React 18

86 points by 0xedb 5y ago

xiphias2 5y ago
Rich Harriss, the author of Svelte talked about all the features that come to React to speed up virtual dom comparisions, but to me he's framework proved it that virtual dom is not necessary, and not the best solution for a scalable UI. At the same time there's a huge amount of React code at this point. It would be an interesting experiment to try to compile React code to really reactive code that doesn't need virtual DOM.
- badbanana 5y ago
  Not React code but SolidJS uses JSX to produce reactive code compile time in the same vein as Svelte.
  - daok 5y ago
    IMP SolidJS fixes a lot of issue React as without leave the "React-ish" way to build components.
  - josephg 5y ago
    Yeah I threw together a simple wiki on top of a CRDT using solidjs a couple weeks ago. It’s delightful - it’s basically react but compiled to be smaller and faster. (It looks and feels like react but there’s no giant runtime, and no vdom diffing). And it has a really nice API for reactive state. I haven’t built anything big with it yet but I like what I see so far!
- tehbeard 5y ago
  I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.
  - dham 5y ago
    If you think Svelte is magic, wait until you see how hooks work.
    - nightski 5y ago
      Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).
      - dmitriid 5y ago
        > Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
        Spivak 5y ago
        Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant. Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run. Like it's janky and reaches through layers but it's not up and rewriting your code.
        dmitriid 5y ago
        > hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.
- picardo 5y ago
  What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.
  - judofyr 5y ago
    I’ve worked on React applications where a single key press would cause lags over 300ms. The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal. There’s some real overhead of React’s virtual DOM.
    - brundolf 5y ago
      That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place I'm really curious what was going on in your app
      - danielvaughn 5y ago
        I've seen it a lot, personally. I've even seen instances where the input would delay by over a second. Really wild stuff. Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.
        brundolf 5y ago
        I think we're talking about two different things- I've definitely seen that much delay before, but it always came down to inefficient rendering logic and/or components that re-rendered excessively often, both of which are easy to detect in profiling and usually not too hard to solve This is the part I thought I was bizarre: > The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal
- MuffinFlavored 5y ago
  Does anybody use https://preactjs.com/ https://preactjs.com/ seriously? I thought React and React-DOM were separate? https://www.npmjs.com/package/react https://www.npmjs.com/package/react https://www.npmjs.com/package/react-dom https://www.npmjs.com/package/react-dom
  - richeyryan 5y ago
    I have used it on production projections and it's seamless. It works with third party React packages with no problems whatsoever and is much lighter. For a stock standard SPA with no need for the upcoming server rendering stuff in React, it's excellent!
- vmware513 5y ago
  Luckily, there is Ember.js, which provides the best developer and user experience for a decade now, with smooth and consistent update and improvements. Still the best choice for huge, corporate frontend projects.
paxys 5y ago
Server Components are still in alpha sadly. I think this one feature has the potential to seriously shake up how React is used for non-static apps.
revskill 5y ago
React still rocks, as it keeps "magic" to the minimal (Hook introduces a little magic for a tradeoff). Simplicity is key here.
- smt88 5y ago
  Hooks are not simple. I have yet to find a dev who doesn't make subtle mistakes with them on a regular basis. I think the concept of hooks is fine, but JS/TS is an insane language and requires an enormous amount of discipline to write.
- linkgoron 5y ago
  Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.
  - pohl 5y ago
    Not a react fan, here, but hooks are so much better than pre-hooks react. Not sure why anyone would want to go back.
    - e40 5y ago
      If you were choosing a framework today, what would you use?
      - pohl 5y ago
        I wouldn't work in the browser at all. I'm liking SwiftUI a lot.
        e40 5y ago
        Is it really cross platform?
        5y ago
gunshowmo 5y ago
The fact that it's been well over 3 years since the introduction of hooks in React and people still don't understand how to use them makes me very worried for frontend development. Really looking forward to server components.
- 0des 5y ago
  The JS ecosystem skews younger, not in age, but in years programming. Most people who maybe want to dabble, or fix a script or something, start with JS or Py, and as most of us do, they enjoy programming and venture out to pick up another language along side it. As is the custom, eventually if they chafe against the limitations of JS enough, they move on to something that improves on those, and their newer contributions go there, whether it be typescript, rust, zig, go, and so on. Looking back at the JS side where the types don't bite, there's a library for everything, and the logos are really good, what we end up with are a lot of first year, or first three year contributions to the ecosystem, so a lot of patterns and algorithms are wisdom lost and aren't present, a lot of libraries are good but not perfect, and there is really no incentive to really dive in and become an expert on a given framework like react, because any day the community might decide, "It's VUE time now" or some such other technology, and suddenly you're the guy using Gulp and Angular on a busted 2021 macbook at the hackathon and people are addressing you as "sir" There is no incentive to be "the react guy" when it comes to JS ecosystem, that 15 mins is quick.
  - jaquers 5y ago
    I am "the react guy" -- but before that I built knockout applications with requirejs & angular applications with coffeescript and gulp, and before that with a 2000 line long script.js & jquery ;) I don't really disagree with anything you said, except to point out that a lot of the current crop of web devs have never experienced what it is to build an app without any abstraction such as React, and quite understandably have no idea what problems it is doing for them. I do know that since hopping onto react with all of that ~baggage~ context, I have never wanted to program UIs with a different model. It is true that hooks introduce a layer of abstraction that is sometimes difficult to reason about, but IMO they boil down the problems we faced with class components/lifecycle/server rendering gotchas, and put them front and center - forcing you to confront and fix them rather than settling for a solution that works 99% of the time.
dstroot 5y ago
Was kind of hoping this would answer the question "when". It doesn't...
hn_ltl-ftc 5y ago
'useSyncExternalStore()' -- Gack! Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles (along with a quirky architecture and proven to be error-prone coding patterns, cough, hooks) into the _model_. And it's already corrupted (at least partially) the "controller" part of MVC through React's synthetic events. But hey, at least React doesn't have one of those nasty DSLs, like those Web application libraries/frameworks that use a simple templating syntax on top of plain HTML. Oh wait, JSX is a . . . DSL, and a pretty nasty one at that, given that it's ever-confusing as where JavaScript syntax is legal vs. where HTML is legal; and, oh yeah, the bracketing rules fight each other all day long. But hey, what do you expect when you combine the careful syntax design of JavaScript with the terseness and simplicity of, umm, XML? So now React's about to ship version 18, which provides functionality which is _roughly comparable_ to version, ummmm, _3_ of Vue.js??? Well, let's see, the React folks have _already, in just a few years_ deprecated (as best I remember): Class-based components, Mix-Ins, Higher-Order Components (HOCs) . . . what's next--let's deprecate hooks?, in favor of, oh I don't know, . . . .sheesh! Please just STOP now. Wind up the company and give the money back to the investors. (Yes, I know that React is Meta-sponsored FOSS; that last comment was just pure snark...) On a personal note, I'd like to rebut a comment made elsewhere on this page by '0des': "The JS ecosystem skews younger, not in age, but in years programming." As a counter point, I've been doing Web application development since the early 2000s. Yes, I've worked with Web app. libraries and frameworks that many Front End Developers have not used, or maybe even heard of. Backbone, sure. How about GWT? Or maybe ES4, by which I mean Adobe Flex? How about TIBCO General Interface? Have you heard of Vitamin C? Trick question--it's not a Web view/app library or even a GUI library--it's a TUI library from the late 1980s/early 1990. Which is to say, I shipped my first front-end code in 1984. And even though I also do full-stack coding, and UX stuff, most of my career has been in front-end coding, both desktop applications AND web applications. Which is to say, at least anecdotally (and possibly egotistically), that I think that I have a pretty well-informed opinions on what makes a good front-end framework. React impresses me not-at-all; except in a: look-at-me-I'm-so-clever way--now new-and-improved--with extra _functional_ goodness(TM). Conversely, I've scaled Vue.js and Flex applications with so little stress (but with tremendous productivity) that I could laser-focus on the feature set, and on delivering a top-notch user experience. I need a Web application framework (or at least a View/Rendering mgmt. library) that has these things: - Strong support for UI componentization - CSS isolation - Clean, orthogonal, basic abstractions for change handling and local state management - Tractable to scale - M, V, and logic aspects are (easy to) decouple Also very useful: - One-way data binding - Robust, but low-ceremony approach to centralized state management - Flexible, but type-safe way to marshall/un-marshall data going out/coming in I'm open to assessing other/new libraries, but the last five years of my career have almost wholly involved coding with Vue.js or React. HOWEVER, I only learned React because I thought that the job market demanded it--not because I ever thought that it was a great library! I'm open to learning other/newer libraries, if they are promising enough, AND if if looks like there is job market demand for them. But the previous version of Vue.js already gave me all five of the needs that I mentioned, above; plus one-way and pseudo two-way data binding. So all I need is Vuex5/Pinia for state management (but I'd be willing to also look at something like a Vue-specific alternative to Tanner's React Query), and there is an increasing wealth of solutions for data marshalling with or without GraphQL. So, bottom line, in my current job search I am taking a hard line: if React is required, then I'm out. And if you're already using Vue, or are at least open to modernizing your current front-end coding approeach, then I'm interested.

86 points by 0xedb 5y ago

Rich Harriss, the author of Svelte talked about all the features that come to React to speed up virtual dom comparisions, but to me he's framework proved it that virtual dom is not necessary, and not the best solution for a scalable UI. At the same time there's a huge amount of React code at this point. It would be an interesting experiment to try to compile React code to really reactive code that doesn't need virtual DOM.

badbanana 5y ago
Not React code but SolidJS uses JSX to produce reactive code compile time in the same vein as Svelte.
- daok 5y ago
  IMP SolidJS fixes a lot of issue React as without leave the "React-ish" way to build components.
- josephg 5y ago
  Yeah I threw together a simple wiki on top of a CRDT using solidjs a couple weeks ago. It’s delightful - it’s basically react but compiled to be smaller and faster. (It looks and feels like react but there’s no giant runtime, and no vdom diffing). And it has a really nice API for reactive state. I haven’t built anything big with it yet but I like what I see so far!
tehbeard 5y ago
I just don't know, svelte feels way too similar to the "magic" of knockout and angular 1.0 when looking at the output... Something I got burnt by with weird edge cases of update loops or desync. Svelte might have that all reasoned out though, in which case the harder separation of logic and view is the only stickler for me, and transpiling JSX into svelte would be interesting to see.
- dham 5y ago
  If you think Svelte is magic, wait until you see how hooks work.
  - nightski 5y ago
    Svelte changes the semantics of your code. It's great to show off to-do apps and simple examples. But I'd be very wary of buying into a framework that relied on compiler modifications to the semantics of code to make it work. I'm also not a fan of pub-sub style change notifications. It's hard to reason about what a change in state is going to cause since you don't know what's subscribed. With hooks at least I am able to have a mental model around what happens when I call a change function since it flows top down (instead of bottom up).
    - dmitriid 5y ago
      > Svelte changes the semantics of your code. So do hooks. Suddenly regular function calls can't be put in if statements or require "dependency lists" to make them work properly.
      - Spivak 5y ago
        Ehh it really doesn't change the semantics of your code, hooks are just iterables and you access them by calling next(). In an alternative world they would be a mapping that you give unique names like useState("mystate", ...) and then order and if statements would be irrelevant. Also you're just just passing a callback function to React and then giving it some pointers to data used as part of the conditional on when it should run. Like it's janky and reaches through layers but it's not up and rewriting your code.
        dmitriid 5y ago
        > hooks are just iterables and you access them by calling next() In Javascript, "just iterables" can be put in conditional statements, and they don't cause the outer function to be called again. > Also you're just just Ah yes. That "just" again Edit: > just passing a callback function to React and then giving it some pointers to data Thing is, in plain JavaScript if it was a callback function, it could be called anything and live anywhere. However, these functions have to be named with a `use` prefix and have limitations on how they can be called.
picardo 5y ago
What Rich Harris said sounds very nice and interesting, but I'd take issue with it being "not the best solution for a scalable UI." As long as the slowdown caused by the Virtual DOM remains below limits of human perception, it doesn't really matter whether something can do without Virtual DOM or not.
- judofyr 5y ago
  I’ve worked on React applications where a single key press would cause lags over 300ms. The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal. There’s some real overhead of React’s virtual DOM.
  - brundolf 5y ago
    That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place I'm really curious what was going on in your app
    - danielvaughn 5y ago
      I've seen it a lot, personally. I've even seen instances where the input would delay by over a second. Really wild stuff. Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.
      - brundolf 5y ago
        I think we're talking about two different things- I've definitely seen that much delay before, but it always came down to inefficient rendering logic and/or components that re-rendered excessively often, both of which are easy to detect in profiling and usually not too hard to solve This is the part I thought I was bizarre: > The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal
MuffinFlavored 5y ago
Does anybody use https://preactjs.com/ https://preactjs.com/ seriously? I thought React and React-DOM were separate? https://www.npmjs.com/package/react https://www.npmjs.com/package/react https://www.npmjs.com/package/react-dom https://www.npmjs.com/package/react-dom
- richeyryan 5y ago
  I have used it on production projections and it's seamless. It works with third party React packages with no problems whatsoever and is much lighter. For a stock standard SPA with no need for the upcoming server rendering stuff in React, it's excellent!
vmware513 5y ago
Luckily, there is Ember.js, which provides the best developer and user experience for a decade now, with smooth and consistent update and improvements. Still the best choice for huge, corporate frontend projects.

paxys 5y ago

Server Components are still in alpha sadly. I think this one feature has the potential to seriously shake up how React is used for non-static apps.

revskill 5y ago

React still rocks, as it keeps "magic" to the minimal (Hook introduces a little magic for a tradeoff). Simplicity is key here.

smt88 5y ago
Hooks are not simple. I have yet to find a dev who doesn't make subtle mistakes with them on a regular basis. I think the concept of hooks is fine, but JS/TS is an insane language and requires an enormous amount of discipline to write.
linkgoron 5y ago
Hooks are not simple at all, are very error prone, and definitely do not put the user in the "pit of success". JSX is terrific, but React has only gone backwards since classes IMO.
- pohl 5y ago
  Not a react fan, here, but hooks are so much better than pre-hooks react. Not sure why anyone would want to go back.
  - e40 5y ago
    If you were choosing a framework today, what would you use?
    - pohl 5y ago
      I wouldn't work in the browser at all. I'm liking SwiftUI a lot.
      - e40 5y ago
        Is it really cross platform?
        5y ago

gunshowmo 5y ago

The fact that it's been well over 3 years since the introduction of hooks in React and people still don't understand how to use them makes me very worried for frontend development. Really looking forward to server components.

0des 5y ago
The JS ecosystem skews younger, not in age, but in years programming. Most people who maybe want to dabble, or fix a script or something, start with JS or Py, and as most of us do, they enjoy programming and venture out to pick up another language along side it. As is the custom, eventually if they chafe against the limitations of JS enough, they move on to something that improves on those, and their newer contributions go there, whether it be typescript, rust, zig, go, and so on. Looking back at the JS side where the types don't bite, there's a library for everything, and the logos are really good, what we end up with are a lot of first year, or first three year contributions to the ecosystem, so a lot of patterns and algorithms are wisdom lost and aren't present, a lot of libraries are good but not perfect, and there is really no incentive to really dive in and become an expert on a given framework like react, because any day the community might decide, "It's VUE time now" or some such other technology, and suddenly you're the guy using Gulp and Angular on a busted 2021 macbook at the hackathon and people are addressing you as "sir" There is no incentive to be "the react guy" when it comes to JS ecosystem, that 15 mins is quick.
- jaquers 5y ago
  I am "the react guy" -- but before that I built knockout applications with requirejs & angular applications with coffeescript and gulp, and before that with a 2000 line long script.js & jquery ;) I don't really disagree with anything you said, except to point out that a lot of the current crop of web devs have never experienced what it is to build an app without any abstraction such as React, and quite understandably have no idea what problems it is doing for them. I do know that since hopping onto react with all of that ~baggage~ context, I have never wanted to program UIs with a different model. It is true that hooks introduce a layer of abstraction that is sometimes difficult to reason about, but IMO they boil down the problems we faced with class components/lifecycle/server rendering gotchas, and put them front and center - forcing you to confront and fix them rather than settling for a solution that works 99% of the time.

dstroot 5y ago

Was kind of hoping this would answer the question "when". It doesn't...

hn_ltl-ftc 5y ago

'useSyncExternalStore()' -- Gack! Now...that "little" it's-not-a-framework-it's-a-library whose scope is supposed to be confined to just the "view" part of MVC (by which I mean: "React") is inserting it's tentacles (along with a quirky architecture and proven to be error-prone coding patterns, cough, hooks) into the _model_. And it's already corrupted (at least partially) the "controller" part of MVC through React's synthetic events. But hey, at least React doesn't have one of those nasty DSLs, like those Web application libraries/frameworks that use a simple templating syntax on top of plain HTML. Oh wait, JSX is a . . . DSL, and a pretty nasty one at that, given that it's ever-confusing as where JavaScript syntax is legal vs. where HTML is legal; and, oh yeah, the bracketing rules fight each other all day long. But hey, what do you expect when you combine the careful syntax design of JavaScript with the terseness and simplicity of, umm, XML? So now React's about to ship version 18, which provides functionality which is _roughly comparable_ to version, ummmm, _3_ of Vue.js??? Well, let's see, the React folks have _already, in just a few years_ deprecated (as best I remember): Class-based components, Mix-Ins, Higher-Order Components (HOCs) . . . what's next--let's deprecate hooks?, in favor of, oh I don't know, . . . .sheesh! Please just STOP now. Wind up the company and give the money back to the investors. (Yes, I know that React is Meta-sponsored FOSS; that last comment was just pure snark...) On a personal note, I'd like to rebut a comment made elsewhere on this page by '0des': "The JS ecosystem skews younger, not in age, but in years programming." As a counter point, I've been doing Web application development since the early 2000s. Yes, I've worked with Web app. libraries and frameworks that many Front End Developers have not used, or maybe even heard of. Backbone, sure. How about GWT? Or maybe ES4, by which I mean Adobe Flex? How about TIBCO General Interface? Have you heard of Vitamin C? Trick question--it's not a Web view/app library or even a GUI library--it's a TUI library from the late 1980s/early 1990. Which is to say, I shipped my first front-end code in 1984. And even though I also do full-stack coding, and UX stuff, most of my career has been in front-end coding, both desktop applications AND web applications. Which is to say, at least anecdotally (and possibly egotistically), that I think that I have a pretty well-informed opinions on what makes a good front-end framework. React impresses me not-at-all; except in a: look-at-me-I'm-so-clever way--now new-and-improved--with extra _functional_ goodness(TM). Conversely, I've scaled Vue.js and Flex applications with so little stress (but with tremendous productivity) that I could laser-focus on the feature set, and on delivering a top-notch user experience. I need a Web application framework (or at least a View/Rendering mgmt. library) that has these things: - Strong support for UI componentization - CSS isolation - Clean, orthogonal, basic abstractions for change handling and local state management - Tractable to scale - M, V, and logic aspects are (easy to) decouple Also very useful: - One-way data binding - Robust, but low-ceremony approach to centralized state management - Flexible, but type-safe way to marshall/un-marshall data going out/coming in I'm open to assessing other/new libraries, but the last five years of my career have almost wholly involved coding with Vue.js or React. HOWEVER, I only learned React because I thought that the job market demanded it--not because I ever thought that it was a great library! I'm open to learning other/newer libraries, if they are promising enough, AND if if looks like there is job market demand for them. But the previous version of Vue.js already gave me all five of the needs that I mentioned, above; plus one-way and pseudo two-way data binding. So all I need is Vuex5/Pinia for state management (but I'd be willing to also look at something like a Vue-specific alternative to Tanner's React Query), and there is an increasing wealth of solutions for data marshalling with or without GraphQL. So, bottom line, in my current job search I am taking a hard line: if React is required, then I'm out. And if you're already using Vue, or are at least open to modernizing your current front-end coding approeach, then I'm interested.