Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It isn't synchronous, it only looks so. It actually uses FP Promises under the hood[1]. We're doing a bit of a trick there (it throws a special value the first time, and then React retries when it's resolved). Then the result gets cached, and the repeated render succeeds synchronously.

I don't mean to offend, but this level of magic behavior sounds terrifying to me. React's original slogan was "it's just JavaScript". That made it easier to understand without special knowledge, easier to pair with whichever libraries you wanted to use, and easier to apply tooling to without special integration. But it seems to be getting further and further away from that goal with each passing year, turning into an opinionated, all-in-one framework like Angular.

Maybe this is just the cost of gaining and maintaining popularity. I won't say it's intrinsically a bad thing, but I personally don't feel good about it.



> I don't mean to offend, but this level of magic behavior sounds terrifying to me. React's original slogan was "it's just JavaScript". That made it easier to understand without special knowledge, easier to pair with whichever libraries you wanted to use, and easier to apply tooling to without special integration. But it seems to be getting further and further away from that goal with each passing year, turning into an opinionated, all-in-one framework like Angular.

I don’t know if this is that kind of magic (I certainly feel like hooks are, though they still don’t make React feel as much like a framework as Angular). When I saw Promise references in JSX, it looked a little confusing at first, but I thought about how it would probably be trivial to write a createElement wrapper that does the same thing on the client, just wrapping in a Suspense or similar until all of the promises resolve. I’m sure it’s more complicated than that, but it does still seem like “it’s just JavaScript”. Promises are widely used in JS already, after all.


See for me hooks - while a bit obtuse and weird - are not this kind of magic because they come down to just function calls. You can use almost nothing but your existing knowledge of JavaScript and reverse-engineer what's going on. That isn't the case with a lot of this other stuff


I’ve written a lot of comments on this the last few days, so please forgive my brevity. But the “magic” of hooks is that they’re not functions (though they look like it), and their use transforms components into not functions, again even though they look like it. Where a functional component is props in -> data structure out, a hooks component is a closure over state and its return value is something like a constructor or factory resembling the data structure you define. The component is no longer referentially transparent, even though it has all of the telltale signs that it should be.

All of that makes not only that component hard to reason about, but makes every function component suspect. And there goes the simplicity of “it’s just JavaScript”.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: