[HN Gopher] RFC: Intent to Ship React 18
___________________________________________________________________
RFC: Intent to Ship React 18
Author : 0xedb
Score : 74 points
Date : 2022-03-24 15:05 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| xiphias2 wrote:
| 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.
| tehbeard wrote:
| 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 wrote:
| If you think Svelte is magic, wait until you see how hooks
| work.
| tehbeard wrote:
| A fair point, and I haven't dove into react's inner
| workings to see how the sausage (I was more discussing the
| compiled code of the app), but one can reason "how" hooks
| work after observing them. - They're tied
| to the lifecycle of the component, so they must reach "up"
| into whatever just called our component function. -
| They do not like being moved about/conditionally executed,
| so hook's likely use an array for metadata storage and
| position rather than needing explicit "hook keys".
|
| Honestly they are weird, but I can reason about them with a
| "good enough" mental model to get paid.
|
| I've no clue what svelte does behind the scenes, much the
| same way as I can't reckon what WASM or assembly do. So I
| guess I just have to blindly trust the compiler?
| jitl wrote:
| You can implement a hooks like interface in an afternoon. I
| don't think I could do the same for Svelte's compiler-
| oriented approach. Using a compiler means that Svelte is
| essentially a dialect of EcmaScript, which appears to be
| mutually intelligible but isn't always. React used a
| compiler for JSX which also introduced a dialect, but JSX
| is optional and very straightforward sugar for a simple
| function call. The Svelte dialect is not so simple.
| dmitriid wrote:
| > Using a compiler means that Svelte is essentially a
| dialect of EcmaScript
|
| So are hooks. The fact that you can't put regular
| function calls (which hooks look like) in an if
| statement, or have to provide custom "dependency lists"
| to some of them, or that data returned from them suddenly
| re-renders (aka calls again) the function they are in
| tells you that this is no longer regular Javascript.
| [deleted]
| dham wrote:
| Exactly, I don't get the React is just Javascript. It's
| not. You're tied to React just as much as Svelte or
| anything else. The Facebook propaganda machine is clever
| I will say.
| nightski wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| Spivak wrote:
| And you can put hooks in if statements too, but like
| iterables it won't have the effect you probably want.
| it = ["hello", "world", "foo", "bar"]
| shouldbehello = next(it) shouldbeworld = next(it)
| if sometimes_true_sometimes_false: shouldbefoo
| = next(it) # if the conditional is false
| this will be foo, oops. shouldbebar = next(it)
|
| Hooks aren't callback functions, they're functions that
| take callback functions. apparently this is breaking
| python. The naming convention is just so the linter can
| identify hooks, they're not magic. def
| react_to_stuff(func, var): orig = var.copy()
| def monitor(): while True:
| sleep 2 if var != orig:
| orig = var.copy() func(var)
| t = Thread(target=monitor) t.start()
| stuff = "Hello" react_to_stuff(lambda x:
| print(x), stuff)
| charcircuit wrote:
| Nothing is stopping you from putting useState in an if
| statement. You just have to be careful since it's an
| "iterator." For example if you put it in an if branch you
| will want to also use it in the else branch so "next" is
| called the same number of times.
| [deleted]
| badbanana wrote:
| Not React code but SolidJS uses JSX to produce reactive code
| compile time in the same vein as Svelte.
| josephg wrote:
| 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!
| daok wrote:
| IMP SolidJS fixes a lot of issue React as without leave the
| "React-ish" way to build components.
| MuffinFlavored wrote:
| Does anybody use https://preactjs.com/ seriously?
|
| I thought React and React-DOM were separate?
|
| https://www.npmjs.com/package/react
|
| https://www.npmjs.com/package/react-dom
| picardo wrote:
| 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 wrote:
| 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.
| tshaddox wrote:
| I would be very, very surprised to see React code that can
| take 300ms in the virtual DOM unless it's deliberately
| designed to do so. To be honest, I've built a whole lot of
| stuff in React and it's not even immediately clear to me
| how I would deliberately design an app to take 300ms in the
| virtual DOM.
| brundolf wrote:
| 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 wrote:
| 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 wrote:
| 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
| picardo wrote:
| I've worked on dozens of large React codebases, and never
| once came across a performance problem that was caused by
| VDOM overhead. Performance lag was always caused by bad
| application design. In most cases, the performance lag was
| due to over-rendering caused by a badly designed component
| architecture and state management system.
| gunshowmo wrote:
| 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 wrote:
| 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 wrote:
| 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.
| 0des wrote:
| > 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.
|
| This is true. A lot of those struggles that the earlier
| people established, the patterns and best uses, those are
| lessons learned the hard way, and the impact on generation
| 2 is often much less because that wasn't a problem that
| needed to be overcome.
| chrisweekly wrote:
| Server components aren't going to fix the problem you're
| worried about. IMHO, Remix.run is the way forward for React
| towards a simpler, saner future.
| throwaway0x7E6 wrote:
| >it's been well over 3 years since the introduction of hooks in
| React and people still don't understand how to use them
|
| s/how/why/
| tshaddox wrote:
| It's also been well over 3 years of myself and many, many other
| people and teams competently building extensive web apps with
| React and hooks, so it's not super clear to me in what sense
| these people "still don't understand how to use them."
|
| There are many reasonable criticisms of hooks, like 1) some
| people have a strong personal distaste for them, 2) some
| educators say they're difficult to teach to newcomers, and 3)
| many people who use them don't have a deep understanding of how
| they work and how to handle some of the "gotchas." But none of
| them lead me to conclude that people "still don't understand
| how to use them."
| tiborsaas wrote:
| What give you the impression that people don't get hooks? In
| our company I see zero questions about how hooks work on slack.
| 90% of the time _useEffect_ is enough.
| dmitriid wrote:
| Do they understand how useEffect actually works? Or do they
| slap on dependency lists on it because eslint tells them to?
|
| People understand how to _use_ hooks, but I don 't think many
| people _understand_ them.
| tshaddox wrote:
| > Do they understand how useEffect actually works?
|
| What do you mean? If you're asking if they can and do use
| useEffect for its intended purpose regularly and don't run
| into edge cases any more often than with any other coding
| pattern, then yeah, they understand how useEffect actually
| works. If you're asking if they have a deep technical
| understanding of how hooks are implemented in the React
| library and every potential "gotcha" they might ever run
| into, then sure, probably not, but the same goes for every
| basic pattern used in any programming language.
| dstroot wrote:
| Was kind of hoping this would answer the question "when". It
| doesn't...
| hn_ltl-ftc wrote:
| '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.
| uryga wrote:
| > '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 [...]
| into the _model_.
|
| useSyncExternalStore doesn't care about what you do in your
| model. it's for connecting your view to your model in a way
| that doesn't give you inconsistent states when concurrent-
| rendering-funkiness happens.
|
| you could even say that useSyncExternalStore exists _because_
| React maintainers want people to be able to use whatever state-
| manager they want (instead of useState /useReducer/whatever) --
| uSES was necessary to enable that in 18.
| sophiebits wrote:
| React 15 came out 6 years ago. You make it sound as if there's
| a new major version every month.
| paxys wrote:
| 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 wrote:
| React still rocks, as it keeps "magic" to the minimal (Hook
| introduces a little magic for a tradeoff).
|
| Simplicity is key here.
| smt88 wrote:
| 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 wrote:
| 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 wrote:
| Not a react fan, here, but hooks are so much better than pre-
| hooks react. Not sure why anyone would want to go back.
___________________________________________________________________
(page generated 2022-03-24 23:01 UTC)