Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC: Intent to Ship React 18

github.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: RFC: Intent to Ship React 18

#31

Post by dmitriid »

Spivak wrote: post #30
dmitriid wrote: post #28

Earlier quoted context omitted.

> 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.

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…

> 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.

Re: RFC: Intent to Ship React 18

#32

Post by hn_ltl-ftc »

'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.

Re: RFC: Intent to Ship React 18

#33

Post by throwaway0x7E6 »

gunshowmo wrote: post #16

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.

>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/

Re: RFC: Intent to Ship React 18

#34

Post by charcircuit »

dmitriid wrote: post #31
Spivak wrote: post #30

Earlier quoted context omitted.

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…

> 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 anyt…

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.

Re: RFC: Intent to Ship React 18

#35

Post by Spivak »

dmitriid wrote: post #31
Spivak wrote: post #30

Earlier quoted context omitted.

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…

> 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 anyt…

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)

Re: RFC: Intent to Ship React 18

#36

Post by brundolf »

danielvaughn wrote: post #21
brundolf wrote: post #11

Earlier quoted context omitted.

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…

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.

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

Re: RFC: Intent to Ship React 18

#37

Post by tshaddox »

judofyr wrote: post #9
picardo wrote: post #7

Earlier quoted context omitted.

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.

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.

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.

Re: RFC: Intent to Ship React 18

#38

Post by [deleted] »

dmitriid wrote: post #28
nightski wrote: post #13

Earlier quoted context omitted.

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…

> 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.

[deleted]

Re: RFC: Intent to Ship React 18

#39

Post by tshaddox »

gunshowmo wrote: post #16

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.

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."

Re: RFC: Intent to Ship React 18

#40

Post by tshaddox »

dmitriid wrote: post #27
tiborsaas wrote: post #23

Earlier quoted context omitted.

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.

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.

> 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.

Post reply on HN