Introducing react.dev

https://react.dev/blog/2023/03/16/introducing-react-dev

by clessg • 3 years ago

748 460 3 years ago

I've been using I think the beta version of this recently, it's definitely an improvement and makes the react api seem a lot more coherent than the old version.

I'm glad they fixed the janky scrolling though that has been cracking me up for a while. It's an example of a common complaint/pitfall with react and even the official docs were plagued by it. As a heavy react user and light react hater I love to see that shit lol.

danabramov19• 3 years ago

Please don't hesitate to report things like janky scrolling to the issue tracker (https://github.com/reactjs/reactjs.org/issues). We were changing things a lot and I'm sure a bunch of regressions could've crept in, so all reports are super helpful.

matsemann2• 3 years ago

The page you linked here https://news.ycombinator.com/item?id=35187407

Is basically useless when scrolling. All I see is a gray background, and when I stop the content disappears. Makes it hard to quickly skim to the correct section.

explodingcamera• 3 years ago

Looks really nice! Also, super happy that the interactive examples are not super sluggish code sandbox iframes, they're actually usable! A more typescript-first approach would have been nice, or at least typescript/JavaScript toggles, but the React team seems to be aware that that's an area they need to work on.

johnny_canuck• 3 years ago

That is something I really dislike about the react-query docs, the examples are code sandboxes. Glad to see they didn't go that path here. I find they add a lot of friction when I am looking for a quick reference.

danabramov19• 3 years ago

Yeah we'd like to add TS throughout but it will require some technical and some content work. We didn't want to block the release on that.

johtso2• 3 years ago

The sexiest example I've seen is in the XState docs.. not sure what they're using to get the types into the tooltips.. https://stately.ai/docs/xstate/running-machines/react#usemac...

benrutter• 3 years ago

Looks like some good resources and a neat redesign. The domain move makes me realise how odd it was that before they had 'org', which is normally used by charities/non-profits. I'm guessing Typescript is the force behind dropping 'js' from out of the domain too.

sophiebits4• 3 years ago

As the person who most often pushed for .org, I can say it was because I wanted to emphasize the community nature. React isn’t a commercial offering. (I had to talk the team out of react.com as the main brand for this launch; although that URL works, I think react.dev is more reflective than .com of what we’re trying to do.)

waboremo2• 3 years ago

Finally! Although looks like Google still has to update so newcomers are likely still going to head to the legacy docs and not realize it (and the legacy page still links to beta.reactjs.org vs react.dev).

A tremendous improvement though, and it must have been a lot of work coordinating, especially the easier to digest images sprinkled throughout.

At last we can officially move past the era of class components.

danabramov19• 3 years ago

We'll make the legacy site binner a bit more prominent and clear -- thanks for feedback. I planned to but got distracted with other things during deployment.

waboremo2• 3 years ago

Perfectly understandable, it's a huge change and these smaller things fly under the radar easily. Congrats to you and the team for pulling off the major transition smoothly!

airstrike• 3 years ago

Believe it or not, React will soon be ten years old. In JavaScript years, it’s like a whole century!

Hilarious! As someone who was once a "full-stack" web dev in the age of jQuery, CSS resets and local fonts only, this definitely rings true.

And having just started learning React (through Next.js), this is a timely and welcome refresh! Thank you!

epolanski15• 3 years ago

React's first implementation (on top of Ocaml) is from 2011 I believe.

explaininjs3• 3 years ago

Are class components really on the down & out? I tried going all in on hooks with a complicated app using lots of web workers and generally heavy computation and complex logic (a game). It turned in to a bit of a mess until I went for a refactor into classes and everything became much more clear.

Having a dedicated place to process changes in props and setup/teardown logic is just generally nicer than weird dependency arrays and returning destructors from effects.

phphphphp• 3 years ago

Most React codebases benefit from the simplicity of functional components, because they fit into the model most people have of websites + web apps. If you’re doing anything complex, you’re in a very small group.

Klonoar• 3 years ago

I would argue the inverse: if your project relatively simple enough that hooks don't feel messy, then it probably doesn't need to be a React app to begin with.

Class components are just (IMO) cleaner, and I find myself saddened at the level of disarray most codebases with hooks are nowadays. Enough has been written elsewhere about how hooks require one to keep more in their head; class components have an agreed up layout/structure/etc that is important in large codebases.

epolanski15• 3 years ago

I hate the word functional components, they aren't functional and it's a deprecated wording in react since the introduction of hooks.

rkeene2• 3 years ago

I find class-based components work better for some things, mainly that need to manage complicated lifecycles that hooks do a pretty bad job of.

bayesian_horse5• 3 years ago

I recommend useReducer, if you can't use Redux. Yes, it works with non-serializable objects (evenrefs if you must).

shmde• 3 years ago

From the docs:

We recommend defining components as functions instead of classes.

Not dead but they are not recommended anymore.

bottlepalm• 3 years ago

I think generally you should start with functional components, try to keep things simple, and use class components as the exception and not the rule. My own app is mostly functional components, but I did fall back on a class component in a case where I needed the lifted state of a function reference to remain current across renders.

danabramov19• 3 years ago

One pattern you might like to try in this kind of code is writing your heavy imperative logic in classes (not React class components! just normal classes), and then using Hooks very lightly to "connect" and "disconnect" things.

See here for some examples of how you can approach writing the same code in a few different ways -- maybe one of these styles will fit you better: https://react.dev/learn/reusing-logic-with-custom-hooks#ther...

explaininjs3• 3 years ago

Oh wow didn't expect to hear form you! Yes that's what I'm in the middle of right now actually to enable online multiplayer: everything regarding the game is in a (class-based) state machine in pure JS that can run frontend or backend and be interacted with via a websocket client (this actually helps with a11y too, navigating a board game via aria-labels was a pain in the butt), and the UI (still WIP) will be far thinner. Perhaps I'll give hooks a try again for that.

baron816• 3 years ago

I created this library that would allow you to put all your state logic into classes: https://github.com/baron816/use-structure

leeoniya• 3 years ago

i've seen advice on the webs for useReducer instead of a lot of useState's...which feels a lot closer to the class-component this.setState().

is there a good reason not to uniformly rely on useReducer everywhere in a codebase?

chatmasta5• 3 years ago

One example of this pattern is Searchkit [0] which performs most of its logic inside a singleton Searchkit class which is instantiated and passed as a prop to the root React component. A bonus is that it's easier to implement bindings for Angular, Svelte, etc. since they can rely mostly on the class and just need to call the appropriate methods exposed on its interface. For example, it looks like Searchkit now suggests using InstantSearch (react-instantsearch-dom) [1] from Algolia, i.e. an entirely different maintainer, and it creates the bindings with a `Client(new SearchKit(...))` adapter [2] around the class (see the code on the home page at [0]).

There are downsides to this - you do need to think a lot more about code architecture before implementing the code, and you can get into a really messy/unmaintainable situation if you aren't careful. And you'll need to consider what state your "singleton" is tied to - is it really one per page, one per component, etc? And depending on the answer, the implications may be that this pattern isn't a great idea. But for certain use cases, it can work well.

The core premise of this pattern is separating business and UI logic, which is not exactly a new idea.

[0] https://www.searchkit.co/

[1] https://github.com/algolia/instantsearch

[2] https://github.com/searchkit/searchkit/blob/main/packages/se...

kimar• 3 years ago

I'm going through this process right now and would love to find examples of a larger open-source codebases doing this, in case anybody has references.

jameshart• 3 years ago

Yes!!

React apps should, in general, contain much less react-specific code than they tend to.

Waterluvian• 3 years ago

Class components, if you want to use typescript, are a nightmare in my experience. So much boilerplate.

rxhernandez• 3 years ago

Are class components really on the down & out?

In the popular sense, they've been on the down and out for years now.

It turned in to a bit of a mess until I went for a refactor into classes and everything became much more clear.

in my experience, once the logic starts to become complex, you need to develop custom hooks so that a given component stays readable.

The hooks paradigm is a lot harder once you get past the basics, but I wouldn't go back for reasons I could articulate if there's any interest.

the_other• 3 years ago

I joined my current company around the time hooks reached peak hype, and whilst the team I joined were refactoring away from class components. My previous gig had used classes. My current codebase is complex (a video player) but pushed all the core logic out to Rx and custom code, rather than going deep with hooks and react ecosystem. So I’m still way more familiar with classes despite ostensibly working in a hook-y codebase.

I hate hooks. The syntax feels nice to type, but the issues outweigh the benefits for me. It’s way too difficult to understand the rendering lifecycle, the state updating, the ordering and I also find the reuse abstraction hard to follow (although I accept that might be a concentration/attention issue on my part). Conversely, it’s also way too easy to break the purity of the hook callbacks, so hooks can use state from contexts you wouldn’t expect (more an issue with custom hooks if you don’t also supply linter tooling to go with them).

Why do you prefer them?

exclusiv• 3 years ago

I like them too but they tend to promote shittier code. The codebases I inherit that use classes = clean, easy to follow. Ones all in with functions and React hooks = trash.

Obviously using hooks doesn't mean it has to be shitty, I think it just brought a lot more wannabe React devs that have no experience with architecture or maintainability.

montroser• 3 years ago

I have had a similar experience, and feel the same way.

I tried to give it a real shot with hooks, but the marginal benefit they bring seems to be far outweighed by the added complexity. Add to that the mixing of paradigms with some functional components, some class-based, etc and it becomes a mess pretty quickly.

yamtaddle5• 3 years ago

Are class components really on the down & out

The hook system is the parts of an OO system that React needed to be able to keep developing features & optimizations for function-based components, rather than telling their users & devs that they'd simply have to use classes for some things. It exists so they could side-line class components, rather than having to become outright reliant on them for some features. So, pretty much, yes.

Stevvo• 3 years ago

Until next year when it's decided hooks have gone out of fashion and need be replaced with something else, yes.

silverwind• 3 years ago

Are class components really on the down & out

Class components are still the only supported way to create an error boundary. Other than that, they are pretty much dead, yes.

johtso2• 3 years ago

Pull all your business logic out in to XState machines. Keep your React components as just dumb renderers.

gherkinnn2• 3 years ago

Yes, yes they are. Next to every 3rd party library is written to only work with hooks. Every tutorial is written using hooks. The new docs (finally) but them front and centre.

koito173• 3 years ago

One thing I find strange about the new documentation is how React.createElement is considered a "legacy API". Doesn't JSX transpile into calls to that function anyway?

This worries me a bit because some React wrappers for ClojureScript expose macros that essentially compile to React.createElement() calls, which are now labelled as a legacy API.

It also looks like Class Components are officially deprecated, given that the documentation explicitly states they are not recommended for use in new code.

danabramov19• 3 years ago

JSX has not been compiling to createElement() for a while. (If you have the modern transform enabled.)

We're not removing createElement but I'd recommend to change your wrappers to the same compile output that the new JSX transform (introduced in 2020) uses: https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n.... The new JSX compile target will allow us to do a bunch of optimizations in the future that createElement() can't.

I'll make a note of adding this to the docs.

mtone2• 3 years ago

I notice that ReactDOM.render is also deprecated.

In our embedded/plugin component scenario where we are given a <div> to load in, it appears we should replace our current pattern ReactDOM.render(React.createElement(... with createRoot(_jsx(....

danabramov19• 3 years ago

ReactDOM.render has been deprecated since React 18. If you're running React 18 with ReactDOM.render, you should already see an error urging you to switch because essentially ReactDOM.render works in React 17 mode.

Yeah you want

const root = createRoot(domNode) root.render(<Stuff />)

(or the JSX transform output equivalent)

ezekg• 3 years ago

Is there an explanation somewhere on react.dev covering how Hooks actually work under the hood? They're the most magical part of React, and everybody I know (including me) had a hard time actually grasping how they work and why, for example, you can't use a hook inside an if branch.

Edit: there are a lot of good--and varied--explanations here. Which is why I think the docs should cover it in-depth. It's confusing.

simonw• 3 years ago

My high level understanding of how they work is that they remember the sequence in which they were called - so if you call the same hook three times, those three calls are held in a list - and future actions that should retrieve them get access to the correct data.

If you were to call them in an "if" branch it would mess up that queue mechanism.

spion15• 3 years ago

1. They work by setting a global variable to the value of the current component then calling the render function. Whenever you call a hook you're effectivelly dispatching it to the component in question, OOP style.

2. React counts the number of executions of (certain) hooks. This count is how it knows which state to get from the store as a return value from `useState`. useState is effectively `getStateAndSetter()` but it doesn't pass a key name of any kind, so the implicitly passed key is `hookCount++`. This is why you can't call hooks conditionally, or state would get all messed up - if a condition turns false and one hook doesn't run that render, all getStateAndSetter calls that run after it will be off by one.

paganel• 3 years ago

I know almost nothing about React, let alone React hooks, but all this looks a little hack-etty, doesn't it?

Also, I'm curious if there is any similarity between these React hooks and the infamous Drupal hooks.

Matheus28• 3 years ago

Here's how I'm pretty sure they work (although I haven't actually looked at the internals). Since your `<Tagname props>children</Tagname>` gets turned into `React.createElement(Tagname, props, children)`, this means your `Tagname` function isn't called directly. So before it calls that function, it sets up a "context" that the hooks will use during that function call (with a global variable pointing to that context so the hooks can find it). We could use an array with one element for each hook invocation. So each useState would use a different slot in that array, etc. This is also why the order and number of hooks must always be the same for a given function, since their identifier is their index in that array.

Additionally, this context would also have the context of children elements, so things can actually be persisted across function calls and React can know what needs to be mounted & unmounted.

Also note that because Tagname isn't called directly, it's also how React is able to do its diff and only actually call what is needed.

This is also why if you're generating a dynamic number of elements (ie outputting an array of elements), you should provide a `key` prop, so it can link up the elements to their corresponding past states each time the function runs.

danabramov19• 3 years ago

I find this to be a very nice high-level explanation: https://medium.com/@ryardley/react-hooks-not-magic-just-arra...

In reality we use a linked list rather than an array. If you wanna dive into the code, I can give some pointers. For example, useState is implemented like this during first render (https://github.com/facebook/react/blob/87c803d1dad7e5fe88634...) and like this during next renders (https://github.com/facebook/react/blob/87c803d1dad7e5fe88634...).

However, _conceptually_ I'd recommend to think of Hook return values similar to "extra inputs" to your function, kind of like extra arguments. There are different ways to formalize it in different languages. We picked plain function calls for simplicity and low overhead, although you could imagine `yield` with generators or something like that.

imbnwa• 3 years ago

In reality we use a linked list rather than an array

Why a LinkedList rather than an array?

acemarke2• 3 years ago

The simplest version is:

- React has a module-scoped variable in the hooks implementation file that tracks which component is currently rendering

- The internal "Fiber" data structure that describes a component instance has a linked list of hook contents (saved values and callbacks)

- As each hook gets called, React tracks the current hook entry, looks up the current hook data, and returns it

So, the number of hooks used needs to be the same each time the component renders so that the linked list entries match up consistently.

There's a great talk by @swyx here that builds a miniature hooks implementation in about 30 minutes:

https://www.swyx.io/hooks

a_humean• 3 years ago

Basically the way of thinking about is that there is a runtime that knows what component is rendering, and your hooks are communicating with that global runtime. This is why hook order and consistency matters - there is basically something globally that identifies a hook by its index order of execution and the identity of the component instance that is currently rendering.

So there is a data structure that store says `[useMemo, useState, useEffeect]` - and when you component re-renders, is unmounting, or has effects to trigger it uses the index order to lookup the bit of state that needed to persist.

This is a pretty good high level explainer of how react works that touches on some of that: https://overreacted.io/react-as-a-ui-runtime/

yamtaddle5• 3 years ago

I read the code when they added them. It may have changed, but here it is:

1) A hook adds a function or variable to one of several lists attached to the component object, when it's instantiated (yes, even your "functional" components are objects, and I don't just mean in the JS-functions-are-actually-objects sense—at least, they were when I read it)

2) Subsequent calls either call those functions, or accesses/modifies the value, in a FIFO manner, reading them out of those lists. This is why you can't mess with hook ordering in e.g. loops.

It's basically just methods and properties on an object, but with FIFO access based on declaration order, instead of using a lookup table of some sort.

[EDIT] A poster correctly pointed out (then deleted their post) that I wrote "loops" where I meant "conditionals". Technically sorta-true (though not quite, as phrased) if the loop isn't the same length every time, but yeah, I meant conditionals. Point is, the reason order matters is that the whole thing's just a bunch of FIFO queues, more or less.

orange83• 3 years ago

and why, for example, you can't use a hook inside an if branch

Within the component functions's body, you may have many calls to the same hook, lets take useState() as an example.

Each useState() returns a different state variable, that is kept track of in a cache outside the component function.

On the first render, the state variables are created. On subsequent re-renders, the state variables are read from the cache.

The cache is a simple array. It keeps track of, and identifies each individual state variable from it's index in the cache array.

The first call to useState() gets slot 0 in the array, the second call gets slot 1 and so on and so forth..

For the tracking to work consistently, all calls to useState() within the function's body must also happen consistently.

In the same order, every time. Having a useState call within a conditional "if" branch breaks that consistency.

nedt• 3 years ago

Everytime I try to understand how something in react works I actually look into how it's implemented in preact. Hooks is around 500 LOC. https://github.com/preactjs/preact/blob/master/hooks/src/ind... React does basically the same, just in a more complex way (because fiber and native etc). But just giving you a mind model the preact implementation is enough.

benatkin3• 3 years ago

Tell me, if React is so great, why isn't Draft.js blowing ProseMirror out of the water? And why aren't difficult parts of VSCode written with it?

I think a good example of where React sits is Deno. The devs who are working on Deno don't seem to have much interest in React, but they are pushing a React framework, Fresh, to make it popular with regular devs. They see the popularity of React and not those who are frustrated with it. One thing is how much typical React code relies on a build step and a bunch of Provider objects. CSS Variables can help make components customizable without having to do CSS in JS.

I think Web Components, maybe with Lit or Svelte, are making more sense for beginning devs. With those you don't have to worry that you might need to work on non-react code sometime.

chatmasta5• 3 years ago

I think Web Components, maybe with Lit or Svelte, are making more sense for beginning dev

Beginner devs want to get a job, so they should probably spend their time learning the framework that dominates the ecosystem. Lit and Svelte are cool, but I don't think they're a great target for a first time web developer. Svelte maybe. But definitely not Lit - it's a relatively new library and a moving target without a lot of adoption, meaning there is a sparse ecosystem to fall back on, and you'll need to fill in a lot of gaps yourself (both in terms of libraries for common functionality, and docs/stackoverflow answers for telling you how to do things). Experienced devs can read the source and official docs to figure it out, but newbies need more hand holding.

benatkin3• 3 years ago

Beginner devs want to get a job

Yeah, that's the point I'm making about Deno.

If Deno's own devs avoid anything similar to React hooks except when they're trying to appeal to the beginning devs, perhaps it would be smart for beginning devs to try to do as the senior devs do, not as they say?

The ecosystem of Lit is the web, which has a lot of great stuff like MDN. It lets you simply use what you learn there. No redirection, like React's onChange translating into the input event.

tracker13• 3 years ago

Draft.js is now archived, and not being maintained. That can be for a number of reasons. When React first came out, it was several years before it really started to pick up steam. I think the Angular shift from v1 to v2 helped out React a lot, along with create-react-app scripts.

Deno is its' own beast, that I really appreciate. And Fresh isn't really a displacement of React, it's their spin on something like Next.js, and in some ways a lot nicer even. Still using JSX.

Web Components are pretty neat, and I see a lot of things moving towards that direction... I also find Lit, Svelte and others interesting. All of that said, popularity doesn't always mean best, or align with it. Timing, interest and "good enough" account for a lot. I happen to like the React way of doing things with function based components. I know a lot of the transition logic is PFM'd away, but it's fine for most.

I've also been following Rust, Yew and Tauri... doesn't mean I'm ready to completely jump ship. React has definite advantages when working on larger projects, the ecosystem and popularity are only parts of that. I think React + Redux + MUI are a really great combination for building applications against. In the end, it really depends on what you are making, what you are familiar with and what "feels right." I absolutely hate(d) angular 1 and 2+ with a passion... I just don't like the feel of it. React + Redux is much closer to how I would build simulation logic for training/learning well before React existed. And MUI is frankly a great component library.

I still keep an eye on what's out there and what's up and coming.

pupppet• 3 years ago

Another feather in Tailwind's cap.

danabramov19• 3 years ago

Haha :)

For what it's worth, the site has been developed by different people over time, so the choice to use Tailwind was made by someone else early on. The team working on the site now doesn't feel strongly about it either way — it's sometimes annoying but overall using it feels really nice! And I'd probably say the same about other CSS solutions too.

I think we'll keep it for now. Where it really shines IMO is fast prototyping. But yeah, it's cool.

Edit: Ok ok tbh I do like it.

benatkin3• 3 years ago

Doesn't appear to be using Docusaurus. Interesting.

starkparker2• 3 years ago

Of course they don't. Docusaurus still doesn't support MDX v2, so they'd be stuck on React 17.

slorber2• 3 years ago

Docusaurus maintainer here. Wrote a Twitter thread explaining why Docusaurus is not a good fit in this case. https://twitter.com/sebastienlorber/status/14527225683902218...

Old but still relevant.

sibeliuss3• 3 years ago

I was praying for some kind of page dedicated to React Server Components. But alas.

mattcarrollcode• 3 years ago

What would you like to see from a React Server Component page?

rrishi2• 3 years ago

Whatever needs to be there for a new react dev to learn about them

sibeliuss3• 3 years ago

How a team who isn't Next.js or Shopify can implement in their own frameworks, without needing to dig into Next.js sourcecode. The example app released around the announcement is quite old and bare-bones, and I'm sure there have been learnings and other guidelines since then. In short, it would be great to have a little more than a spec and an undocumented webpack plugin to work from.

rrishi2• 3 years ago

danabramov19• 3 years ago

Not yet, but as the blog post notes, it's going to be a bigger focus now that the first integrations are in progress. For now, we've added a tiny bit about them here: https://react.dev/learn/start-a-new-react-project#which-feat...

sibeliuss3• 3 years ago

That's exciting news. As mentioned below, it'd be great to have some implementation steps for companies and projects who aren't at the Next.js framework technical level. There must be some middle-ground!

romanhn• 3 years ago

Kudos to React maintainers for their focus on documentation. A year ago I decided to learn React and the official docs were instrumental in getting me up and running. For context, last time I'd done any serious coding was when I still had to care about IE6 compatibility, so all the modern SPA paradigms had to be picked up from scratch. I spent the afternoon reading the docs and was able to jump right into coding a basic proof-of-concept app that same day. The clarity of writing, the progression of topics, it all hang together very well. Looking forward to the latest iteration here!

jve3• 3 years ago

Its like 2 weeks since I had to grasp react, fluentui, react hook forms, webpack and a little more when I started using modules and even more when I used typescript.

React clicked really fast, documentation new and old, articles helped get on track really fast.

Wiring that all together and taming CRA (Create-react-app) with react-app-rewired to add stuff to webpack, like adding libraries to behave like modules that are NOT modules, packing all with scripts into single html, understanding where are boundaries between fluentui and react (both new to me), setting up monorepo because I separate reusable components from app itself and libs, applying css which I am bad at and stuff like that took more time... complexity just explodes, but less "mental effort" overall achieved by having streamlined build, reusable stuff etc.

Otherwise I feel that building app with react takes a lot of "mental effort" away, because you develop a component in isolation which feels simple and when you use that component you don't think about implementation details - it is nicely abstracted away and things just work.

Ah, yes, and I'm lucky I got the signal that functional components are way to go and the only place I had to use a small class component when I want to have a component variant for existing class based component from FluentUi where generic types are important and used within `onRenderItem` and various methods:

class LookupBaseInternal extends BasePicker<ILookupResultProps, ILookupPropsInternal> {}

jve3• 3 years ago

Oh, here is another 1 I caught:

There is currently no way to write an error boundary as a function component. However, you don’t have to write the error boundary class yourself. For example, you can use react-error-boundary instead.

https://react.dev/reference/react/Component#catching-renderi...

IceDane• 3 years ago

Just FYI - I would not use CRA. Even the react maintainers basically recommend you don't use it, since it's not really up to date with best principles, and they might eventually change it so that it becomes a wizard that lets you choose between other more modern choices like nextjs or vite.

You probably want to look at vite for a more direct alternative to CRA. No need for things like -rewired, and it's probably 10x faster than CRA.

Aduket• 3 years ago

Wow, your writing skill is awful. Building a sentence with 50 words?!?! And not using even a single comma?!?! Your brain must be working differently

iamsanteri5• 3 years ago

After using Vue for a long time, React felt like an unforgiving piece of cr*p. As time went on and Vue was getting its Composition API while kind of moving in the overall direction of React, I decided to try class-based components and didn’t like them that much (this was a couple of years ago). Recently, I went through these new docs and read and applied the stuff I learned, and I can say it was a surprisingly nice experience. I just needed to get friendly with a composition-ish, functional-ish and JSX-ish way of thinking. Alone the thought of HTML-in-JS instead of JS-in-HTML made me crazy back then (it still kinda does). But when you get the hang of building actual user interfaces instead of just websites, it makes a lot of sense. If you’re comfortable with javascript while daring to take the less-opinionated route as opposed to an all-out framework, you'll simply feel the power!

Anyhow… To this day, I still think it’s an unforgiving, crazy beast of a library for a weekend hobbyist developer like me. But I kinda like it now and in big part it’s thanks to hooks, functional components and these new docs. Good job team, and congratulations on finally getting this live!

danabramov19• 3 years ago

Thank you! Glad to hear it made things click :)

eoic• 3 years ago

Interesting, I had an opposite experience. I started out using React when using class based components was a way to go then stopped for quite some time. Years ago I had to use React for something and decided to use the new approach with hooks and it was such a painful experience - it was harder to learn and use, also I introduced many ridiculous rendering bugs. I still feel that component based approach was somewhat easier and more straightforward to get into even if more verbose.

iamsanteri5• 3 years ago

Yes, it can be tricky, and sometimes I too catch myself asking, "why is it designed like it is" with regards to hooks, I won't lie. But, there is something there that makes it attractive to me where it was off-putting before. Alone as a complement to more extensive state management libraries, or other tools intended for larger scale apps, it serves as a nice middle-ground solution. You can build your own bits of logic in quite an accessible way now too. In other words, for me personally I feel that there is something distinct and interesting going on here.

Finally, if you combine it with the fact that it seems to hold on as the industry standard for jobs, and being useful for native mobile development via React Native, it all comes together nicely in my mind. With its huge ecosystem and closeness to plain vanilla JS, I guess it just makes me simply a bit of a better developer and gives me a new perspective on things. That's that.

epolanski15• 3 years ago

As someone who worked with both, vue 3 is miles ahead imho. Scoped css, well working two-ways data binding (now being mimicked again with signals after mobx demise) and reactivity, easier to get performance out of the box without the hook madness.

iamsanteri5• 3 years ago

In many ways I do agree with you, but by now all these front-end frameworks and libraries, including their server-side rendered counterparts (like Nuxt, Next, etc.) just keep borrowing things from each other.

Regarding performance, I remember having blocking sluggishness with v-model that shouldn’t have been there back in Vue 2 days.

Also, for example, in Vue 3, my favorite component library Buefy (based on Bulma) is no longer available, and I don't think any of the other ones have (arguably) come so close and extensive to what I want.

Vue 2's transition to Vue 3 (if you want to use the new CLI tools and the Composition API) had to, by definition, fragment the ecosystem in unpleasant ways no matter how carefully and sensibly it was managed by the core teams in charge.

You can see that Vue went down slightly in recent developer surveys, and I suspect this to be among the main reasons. As if Evan himself would be suddenly more focused on his build tool Vite as opposed to Vue itself (of course it's just an illusion).

But I still love Vue because of their amazing docs, and the fact that they let me enter the world of web-development in a relatively accessible manner (this may not have been possible with React, for me personally). Lack of something like scoped styles alone baffles me in React to this day, but it makes kinda sense in the ecosystem it's operating in...

MoSattler2• 3 years ago

I never really got why people LOVE two-way binding to the point that they add things like mobx to projects. IMHO the one way data flow makes things so much easier to reason about.

parhamn• 3 years ago

Mobx demise?

aarpmcgee• 3 years ago

mobx demise? Did something happen to mobx?

IshKebab2• 3 years ago

I haven't used Vue 3 but I have used Vue 2 and React extensively. React is much better for anything but tiny projects.

It has much better Typescript support, and also it doesn't have Vue's spaghetti reactivity system, both of which vastly increase the chances of bugs.

I guess you could say they're more similar if you simply don't care about bugs at all.

lfuller• 3 years ago

What happened to Mobx? It was my understanding that it’s still going strong.

bpicolo• 3 years ago

I also like what it inspired in Vue. At first I thought "oh no they're taking what React did and throwing it into Vue". But it actually ended up to be a very true-to-Vue variant with just some idiom similarities. The new Vue 3 ecosystem with Pinia blends together nicely

solumunus2• 3 years ago

Svelte > Vue > React

iamsanteri5• 3 years ago

Is it possible to add Svelte gradually for simple and small parts of a website without a compile step? It surely seems amazing and all the rave these days!

Then again, the whole front-end ecosystem is moving at a pace I cannot quite follow. Instead, I've been going into the direction of traditional monoliths and working through the docs of Django and RoR.

There you have a plain "good-old" templating language with sprinkles of htmx and alpine where you need it. This along a bunch of back-end devs that seem to not want to even touch the javascript stuff with a stick. It almost feels refreshing though, particularly if you want to build rapid MVPs while retaining maximum control of your entire stack and IP. When teams grow and you need to support extensive and/or thicker clients, I believe this is where bigger front-end libraries like you mention truly shine. I'm still counting on us coming a full circle and there being a re-emergence of traditional monoliths in the future though. But then again, with supabases, pocketbases, strapis and other "simpler" backends of this world, who knows what'll be happening even in the nearest future...

kayson2• 3 years ago

Why did react (effectively) get rid of class components? Conceptually, a component seems better represented by an object/class than a procedure/function. And aren't classes just really functions under the hood anyways?

pyrolistical• 3 years ago

The quick answer is Hooks killed class

epolanski15• 3 years ago

We removed boilerplate for higher complexity. We made the 90% cases simpler but overly complicated critical paths.

So many useMemo, useEffect, useCallback madness was trivial with basic class component lifecycle.

yamtaddle5• 3 years ago

Why did react (effectively) get rid of class components?

Supporting some features for hooks and classes, both, probably would have meant having two implementations in some cases, that might not quite match up as equivalent. More API surface area, more code to test, more combinations and paths to worry about.

And aren't classes just really functions under the hood anyways?

Other way around, actually: "functional" components end up represented by an object.

robertoandred6• 3 years ago

Other way around, actually: "functional" components end up represented by an object.

No, they're functions.

danabramov19• 3 years ago

Conceptually, a component seems better represented by an object/class than a procedure/function.

In other paradigms, it is! Our paradigm is exploring the functional take. I agree it's a bit unorthodox but we are very intentional about modeling it that way. It really has a bunch of powerful properties one might not expect.

And aren't classes just really functions under the hood anyways?

The key difference is that in React, UI is a pure projection of current data (props/state). You're always supposed to "return" the UI. Sure a class is a function, but that function is invoked once. Its methods can be called many times, but having a pure render() method (like in class-based React) is really a class cosplaying as a function. Functions are more honest to what React is trying to be.

Relevant part from Seb's Hooks RFC comment (https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...):

Classes may seem like the ideal thing to hold state since that's what they're designed for. However, React is more written like a declarative function that keeps getting executed over and over to simulate it being reactive. Those two things have an impedence mismatch and that keeps leaking when we think of these as classes.
Another issue is that classes in JS merge both methods and values on the same namespace. This makes it very hard to make optimizations because sometimes methods behave like static methods and sometimes behave like values that contain functions. The Hooks pattern encourages the use of more statically resolvable calls for helper functions.
In classes, each method has its own scope. It causes issues like us having to reinvent default props so that we can create a single shared resolved object across those. You also encourage sharing data between those methods using mutable fields on the class since the only shared thing is this. This is also problematic for concurrency.
Another issue is just that the conceptual mental model for React is just functions calling other functions recursively. There is a lot of value to express it in those terms to help build the correct mental model.

For a concrete example of where classes as a model fails us, consider useTransition (https://react.dev/reference/react/useTransition). It lets you start rendering "in background" with a different state value. But if you get interrupted, the renders have the current value. This highlights that in React, the same piece of state can conceptually be thought of having more than a single value (kind of like being in parallel worlds). Classes don't model that well.

notpachet2• 3 years ago

Our paradigm is exploring the functional take.

The operative word there is 'exploring'. In practice, hooks are still basically OOP, albeit masquerading as FP. You just shuffled the state into a shadowy realm adjacent to the component where it's harder for developers to see. I know a lot of JS developers are allergic to writing the 'class' keyword (even though JS doesn't really have classes in the first place), and I guess hooks help them sleep easier at night by allowing them to believe that they're writing their code in a functional way. But they usually aren't. And I think that misdirection is the source of a lot of the confusion out there regarding hooks.

"The greatest trick the OOP devil ever pulled was convincing the world that state didn't exist"

kayson2• 3 years ago

It really has a bunch of powerful properties one might not expect.

Can you elaborate on this?

a class is a function, but that function is invoked once. Its methods can be called many times, but having a pure render() method (like in class-based React) is really a class cosplaying as a function. Functions are more honest to what React is trying to be

useState() is a function cosplaying as a class ;) and that's really my biggest hangup. It seems like react components are not quite functions nor are they classes but rather somewhere in between... And because of JS quirks and perhaps the internal architecture/mental model, functions end up being a better choice.

in React, the same piece of state can conceptually be thought of having more than a single value (kind of like being in parallel worlds). Classes don't model that well

Maybe I'm missing something but this seems like a false dichotomy because the equivalent in the class-based model would be the render function, not the class itself. And in that sense, your set of render functions can also have multiple values given a state. Though just writing this out does make functions feel a bit simpler.

Admittedly, you've mostly convinced me! And after reading through the new documentation, going function-only feels a lot cleaner than it did when I learned react using the old docs.

dbbk• 3 years ago

I'm really not sure why they're so insistent on phasing them out. Have I written one recently? No. But I sure do appreciate that they exist for cases where you want fine grained control over what's happening.

wetpaws2• 3 years ago

The original reasoning was, I kid you not "cause classes are too difficult concept to understand".

nayroclade3• 3 years ago

Unbelievable that they’ve gone ahead launching this, going all in on hooks, while the fundamental problem with them, which was raised in 2018 is still unsolved: https://github.com/facebook/react/issues/14099

And they just handwave it away in the docs with an imaginary future API. Embarrassing.

aidos6• 3 years ago

I’ve not read through the thread but I wonder how much of it is effective replaced by the upcoming useEvent hook

https://github.com/reactjs/rfcs/blob/useevent/text/0000-usee...

nayroclade3• 3 years ago

It might have, but that RFC has been withdrawn.

spencerchubb• 3 years ago

I think you're a few years too late to criticize for going all in on hooks. Sure, there may be deep rooted problems, but there's a lot of inertia.

whakim• 3 years ago

This is certainly an issue/annoyance (along with other things I don't care for about React), but calling it a "fundamental problem" and "embarrassing" ignores the vast, vast majority of React users who manage just fine.

hummus_bae• 3 years ago

This may come across as naive, but could you expand on the significance of this issue for people who don't use React every day? I see that lots of people think this way about Hooks, so I'm honestly just curious about what React users think is such a big deal

abxytg2• 3 years ago

its not naive. this isn't a problem you're likely to run into or have to work around. It is a thing that pedantic people bring up to justify the trouble they have keeping up with the pace of change in front end dev.

abxytg2• 3 years ago

Can you elaborate on what this issue prevents you from doing? I write production react code that is used in medical devices every single day and I have never had this problem stop me from developing a particular screen or piece of functionality, and I use pretty much every niche edge web API that there is.

Hooks has made me 3-4x more productive. If a technicality is stopping you from enjoying it, that is such a shame.

martpie• 3 years ago

How is that an actual _fundamental_ problem?

The world has embraced hooks, for better or worse. The fact is React still works well, and the React team has always been clear that performance is (somewhat) an implementation details. For example, they often advertise to use inlined functions and to use `useCallback` only if you're facing performance issues.

So `useCallback` invalidation is definitely not "fundamental" (imho)

wetpaws2• 3 years ago

JS world has a long running tradition of embracing things that in retrospect they should've not.

ajkjk2• 3 years ago

What are you talking about? Hooks are fine and are out there working fine for everybody. They have some rough edges but it's not, like, some catastrophe.

chatmasta5• 3 years ago

And yet, entire startups have been created and acquired during that time, many using React and many using hooks. It appears this "fundamental problem" is far from a show-stopper. Ultimately, that's why people like React: it gets the job done. The API is small and extremely stable. The last major breaking change was hooks, and that wasn't really even a breaking change - just a new paradigm that you should move to eventually (class components do still technically work!)

Honestly, by the time class components are fully deprecated, you'll probably be able to ask ChatGPT to rewrite your codebase to use hooks instead...

epolanski15• 3 years ago

The api is anything but small.

ojkelly4• 3 years ago

Unbelievable that they’ve gone ahead launching this

I hope the irony of criticising a team for launching something early, on HN _of all places_ isn’t lost on you.

going all in on hooks

They went all in on hooks in 2018 when they rewrote the internals with React Fiber.

Hooks are how react works, class components are more of an abstraction—not less.

while the fundamental problem with them, which was raised in 2018 is still unsolved

If it was a showstopper it would have been fixed by now.

klysm6• 3 years ago

It's odd that sooo many things are still successfully built on top of react.

davidatbu2• 3 years ago

I've had to write my own `useCallbackOne()` hook that is guaranteed to not be recomputed if it's dependencies don't change.

    export function useMemoOne<T>(valueProducer: () => T, deps: unknown[]) {
      const [initialValue] = useState(valueProducer);
      const memoizedValue = useRef(initialValue);
      const memoizedDeps = useRef(deps);
      if (
        deps.length != memoizedDeps.current!.length ||
        _.zip(deps, memoizedDeps.current!).some(
          ([dep, memoizedDep]) => dep != memoizedDep
        )
      ) {
        memoizedValue.current = valueProducer();
        memoizedDeps.current = deps;
      }
      return memoizedValue.current;
    }

    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    export function useCallbackOne<T extends (...args: any[]) => unknown>(
      fn: T,
      deps: unknown[]
    ) {
      return useMemoOne(() => fn, deps);
    }

FWIW, for this and other reasons, I've recently been looking into "actually reactive" frameworks (like Solid/Svelte), and I think I vastly prefer their paradigm to react's.

Specifically, I used sycamore-rs to build a Rust/WASM UI, and it's great (once you get the hang of dealing with lifetimes in sycamore).

bmikaili• 3 years ago

if you like sycamore check out dioxus.

gardenhedge2• 3 years ago

React is awesome. When will there be something like it for CSS? I feel like CSS is still a mess.

blowski• 3 years ago

What would such a library do?

epolanski15• 3 years ago

I miss elm-ui

https://github.com/mdgriffith/elm-ui

madeofpalk• 3 years ago

Vanilla Extract is probably worth looking into. I feel like it's the best option out there for "CSS but better".

christophilus3• 3 years ago

tailwindcss.com

It’s been a game changer for me. I can’t see myself ever going back.

gardenhedge2• 3 years ago

I tried before and didn't love it. Based on how it has been adopted I will have to try again.

tracker13• 3 years ago

Styled Components is relatively popular and is used in the MUI (material-ui) library for react. There's also a number of JSS libraries as well.

foxbee• 3 years ago

Credit to the React team. The docs prior to this were poor - I believe the team admitted this.

From the style of writing, to the style of site, I can tell a lot of effort was put into this. Will check out react this weekend - it's been a couple of years (we've been using svelte)

anthonypz• 3 years ago

I recently went through the entire beta React docs (took me about 3 weeks) and was blown away by the quality of the tutorials. The live code playgrounds and challenges are amazing. With the recent debate about reactivity and which framework implements it best (solid vs. react vs. vue vs. svelte), I felt that what mattered most to me as a junior dev is the quality of the documentation. I gained a strong enough understanding of the complicated concepts (dependency arrays and the useEffect hook) because the docs were so good. There is always room for improvement in JS land and other frameworks are constantly innovating, but the thing I always fallback to is: how good is the documentation?

Side note: I recently took an assessment test on React through Triplebyte and was given an expert level badge (for what it's worth). I think that speaks volumes about the new React docs because that is where I gained most of my React related knowledge.

vbezhenar• 3 years ago

IMO React is missing hooks to work with promises. I made that hook myself but I think that promises along with AbortSignals (to interrupt promise if React decided to cancel it) are basic JS API and React should just support them out of the box. I saw too much code which deals with async functions in useEffect in a buggy way. Things like ReactQuery are nice but they should not be required.

Here's my implementation, for the record: https://pastebin.com/rjj0FDDd

subleq• 3 years ago

react-query basically converts promises to hooks

danabramov19• 3 years ago

We agree. https://github.com/reactjs/rfcs/pull/229

selfmodruntime7• 3 years ago

You probably won‘t answer, but what do you think of the (imo uncalled for) wishful thinking that react should‘ve stayed in the direction of Class components?

idkwhoiam• 3 years ago

Here's my implementation, for the record: https://pastebin.com/rjj0FDDd

This implementation doesn't account for the fact that the promise may settle after the component has been unmounted.

fireant• 3 years ago

Missing standard downstream promise cancellation is arguably one of the bigger problems in the whole javascript ecosystem. In C# almost every async function has a CancellationToken parameter, same in Go with Context.

Even after years of writing fullstack javascript this is my first time seeing AbortSignals, probably because nobody uses them. Some libraries, like Axios, handroll their own cancellation mechanisms, but that does not really cut it.

andrewmcwatters13• 3 years ago

Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation.

I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me.

I'm happy that other people seem to enjoy them without restraint, but obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality.

I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years.

I think having seen front-end software come and go so many times, I'd rather write some simple utility functions wrapping `Document.createElement()` and use native event handling.

Too much fluff in front-end.

I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

motoxpro2• 3 years ago

Picked up react in the last 5-6 years and looking at old class component examples confuse me to no end. I guess it’s just what you learned first.

andrewmcwatters13• 3 years ago

:) True. My first web development experiences were on AOL Hometown and reading people's 1337 scripts from dynamicdrive.com. DHTML! Updating PHP scripts over FTP! Shared hosting.

Oh right, you meant React wise... yeah...

Aeolun6• 3 years ago

I worked with class components first. Built a whole app in them. Now we’ve migrated to functional and I look back at the class based ones wondering how I ever dealt with that.

I didn’t want to adopt functional, but let everyone make their own decisions on what to use, and now I’m very happy I did.

nmjohn• 3 years ago

I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

Asking for an API interface to be stable for decades __across all future versions of the library__ doesn't sound realistic to me. Nothing is forcing you to update to the future new version of react - which has not been released, and is likely years away - that removes support for class components.

hartator3• 3 years ago

Basic HTML tags are more than 20 years old now.

hartator3• 3 years ago

Yes, I have trouble getting what was wrong with the first stables of React.

It seems they are getting bored.

r3trohack3r7• 3 years ago

This is exactly what I'm doing with my personal "framework" I use for client contracts. It's just Web Components with a handy class based wrapper. I call it Template, since it's based off <template> tags.

It's a joy to work in, feels "frameworky" but it's just web standards with <100 lines of convenience JS wrapped around it. There is no magic beyond what the browser provides - I like it that way.

https://github.com/retrohacker/template/

It's "open source" as a reference. Just using it for myself. There aren't many docs beyond notes to myself. But the actual framework is a 90LoC JavaScript file that is an easy read.

You're welcome to kick the tires. If you like it I'd entertain PRs and stuff but it's such a small library forking is probably entirely reasonable to make your own flavor too.

The general idea is you extend the Template base class and call "super" with the id of the <template> that will get bound to the ShadowDOM when the class is mounted. Then you call instance.mount and pass a dom node to mount it into the DOM. For child nodes, you use `this.fragment.querySelector` to select them from the <template> you mounted. It supports garbage collection by tracking children, so when you "unmount" it recursively unmounts all child instances as well. Finally it has an event emitter implementation, so changes/actions/events bubble up the DOM while state can push down through the DOM. Keeps things clean.

I recently added state methods since I was duplicating state management everywhere. Now the base template class has a `setState` that will emit a single `change` event for all changes in the current "tick" of the browser eval loop.

Cheers and happy hacking!

andrewmcwatters13• 3 years ago

Cheers, kudos to you for writing long lasting software.

Edit: Hey another Arizona hacker! Right on!

bnert• 3 years ago

This is cool! Small and no magic.

koch• 3 years ago

I like how for your brief documentation you start with a single index.html file. Too many web/framework docs start with a command that gives you a directory full of who knows what, which tends to negatively affect beginners more than anyone

jdthedisciple• 3 years ago

Great project, exactly what I've been looking for - a truly minimal JS "Framework*!

triyambakam• 3 years ago

This is awesome! I was actually looking for this very kind of thing the past couple of days. I was searching HN and Github for "vanilla js" and various "framework" queries but not finding anything. Thanks!

DrVanNostrand• 3 years ago

Simple, but folks moved on from Backbone-like UI libraries for good reasons.

bakugo• 3 years ago

seems like a design choice intended to infantilize engineers and shelter them from reality.

The entire front-end framework landscape is like this. It's all designed to appeal to the kind of "engineer" that just wants to copy paste code and have it work like magic without ever thinking about what's actually going on.

nailer• 3 years ago

This is exactly the “just use react” stereotype. Download a random react component from NPM and 90% chance they just added wrapper divs until they could get the CSS to (kind of) work.

andrewmcwatters13• 3 years ago

It's just front-end engineering in general, you don't get this with people who work in other subfields of software engineering. I get it, though. It's OK until you need to learn and grow beyond it, which I think anyone doing this long enough will.

It sucks that people learn this the hard way, though, and the only way to grow beyond this for people new to the field is to eventually get burned and learn there are other ways to do all of this.

There are whole generations who don't know what session cookies are! And... that's just OK.

tut-urut-utut• 3 years ago

What’s wrong with that?

Let’s better spend time on important things instead of wasting time trying to make UI behave properly across a plethora of browsers, OSes and platforms.

epolanski15• 3 years ago

And yet the sanest option for this, web components, keeps struggling.

strokirk• 3 years ago

That sounds just like me and my backend coding too! What are you doing to justify being to high and mighty?

robertoandred6• 3 years ago

It’s hilarious how frontend engineering is both for dumbdumb fake engineers while also being too complex for vaunted backend engineers to understand.

conradkay2• 3 years ago

Sounds reasonable and like good code and design, perhaps we "engineers" think hard enough already. I just started reading A Philosophy of Software Design and it talks about "deep" modules (they give the example of UNIX's open creat close lseek and read vs java's I/O interfaces).

epolanski15• 3 years ago

I'm slowly trying to get most of my projects and client ones to leverage more and more web components, I'm sick of reimplementing the same things over and over.

timcobb• 3 years ago

Not seeing where it says that classes aren't going to be supported anymore

mwcampbell• 3 years ago

seems like a design choice intended to infantilize engineers and shelter them from reality

I think it's more charitable to assume that the designers are designing this for themselves and are just being aware of their own fallibility and limited mental capacity (we're only human after all), not seeking to infantilize or shelter some lesser class of programmers.

explaininjs3• 3 years ago

Eh... having worked with a Facebook developer tools team, they quite literally do dismiss the vast majority of the engineers at the company as "those guys who wouldn't be able to understand the stuff us devtools people do".

davnn• 3 years ago

Your will be surprised how nicely a functional approach with hooks can improve your frontend architecture. Side effects are the source of all evil, it‘s quite useful to take special care.

andrewmcwatters13• 3 years ago

I think the thing is that you're focused on this specific implementation detail of React. I just don't care. Not that you're not right, either! It's just a matter of competing interests.

I'm running two businesses with a third on the way. I have bigger problems than people reinventing stuff with no benefits compared to what we were doing 20 years ago.

I'm writing software every day, so I'm still involved in front-line work, but I'm interested in being the level of productive most people aren't.

So the bigger questions on my mind are things like, "What knowledge can I build up that doesn't become obsolete?" "What social effects drive adoption that endanger those goals?"

Those are questions that have, at least immediately, very little to do with implementation details, and are questions that help me navigate whether to ignore new technologies all together, or when I identify something new when I decide to adopt it.

A part of that is looking for cues from maintainers that say, "Hey, we care that you're shipping, and we're not going to endanger your labor spent learning our intellectual property."

azangru3• 3 years ago

I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial

This is a great idea. Nothing controversial about it.

stuff20230314• 3 years ago

Decoupling your personal future from Silicon Valley devs' pursuit of promotions is always a great idea.

andrewmcwatters13• 3 years ago

You end up having to answer to people in interview processes that have fewer years of experience than you, and have written sometimes orders of magnitude less code than you, and wonder why you make "weird" decisions not knowing that those decisions have been made with a collection of exceptional experiences.

Lots of engineers out there today who don't have a simple answer for, "So what happens when one of your dependencies no longer exists on the Internet for one reason or another?"

nfRfqX5n• 3 years ago

React has been out for a decade. Why can’t your system could stay on this version forever?

andrewmcwatters13• 3 years ago

I won't immediately update, since future feature development will take priority, but eventually I will want to update since the current industrial risk is that surrounding dependencies may have bugs that are a risk to customers.

It's a low likelihood, but I'd rather stay up to date when I can.

ojkelly4• 3 years ago

Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation.

The writing has been on the wall for 4 years that hooks are the future. You _can still_ use class components. Function component with hooks is the simplest API you can get to React itself—classes are more of an abstraction.

I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me.

We all adopted hooks because it makes things easier to reason about. If you’re still having trouble understanding them, I’d urge you to dig deeper into how they and React works.

I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years.

I can’t think of a better way to develop an appreciation of UI frameworks that to go without.

I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

Barely any software runs untouched for decades (documents don’t count). So it’s not that the sentiment isn’t appreciated, I think most of us would agree—it’s that it’s an impractical expectation.

andrewmcwatters13• 3 years ago

When you maintain your own software for periods of time that outlast front-end engineering trends or IC's entire career tracks, your opinions might change.

Plenty of software runs untouched for decades. A lot of it powers your interactions with people on HN right now, from drivers, to font rasterization and backing layer UI composition. There are bugs in codebases that have taken 20 years for people to even notice. It happens.

When people don't have to worry about trivial details, they can focus greater efforts.

pdntspa2• 3 years ago

I've got a multi-gigabyte folder of portable windows programs and utilities, where parts have been untouched for 15+ years. For the most part, everything still runs.

Winamp? Check.

Spacemonger? Check.

FLAC encoder? MP3 encoder? Notepad++? Savihost? TheGodfather? Flash Player? MS XML Notepad? ConEmu? Some really old build of CockroachDB? CPU-Z? Doom Builder 2? HexChat? Hell, even mIRC? Check check check check check checkity check.

None of those have been updated in years, many untouched (but not unused) since the day I installed them. This is why the web is so effing stupid. (And a hat tip towards Microsoft for keeping promises, unlike web developers)

And in many cases they STILL work better than the crappy little my-first-webapps that everyone uses instead nowadays.

Software is and should be eternal. It's these damn platforms that nobody wants to hold still with.

FactoryReboot2• 3 years ago

I strongly disagree. It was way easier to reason about things pre hooks.

Varqu• 3 years ago

As a programming newbie, I would love to see a hard fork of React without Hooks (and their magic)

web3-is-a-scam2• 3 years ago

check out Preact and Inferno

xdennis• 3 years ago

obscuring magical details and making side effects seem like more of a big deal than they really are in programming seems like a design choice intended to infantilize engineers and shelter them from reality.

You seem to be taking it too personal. There's no need to call others infants for preferring hooks.

groestl• 3 years ago

`Document.createElement()` and use native event handling.

I'm not a frontend dev by all means, but I must say, I've worked on such projects (100LOC create utils & event handling) and it was a joy. I always wanted to recommend it to people when they complain about the state of js frameworks, but I felt I've no authority to do so, because my experience is limited (only internal projects).

Aeolun6• 3 years ago

But have you built whole applications in them? React is one of the few frameworks where I almost never feel like they didn’t consider consider all use cases.

codeptualize13• 3 years ago

And then we have another framework! This is why we have so many :D

brundolf2• 3 years ago

I don't think it's productive to throw out enotionally-charged words like "fanatical" and "infantalize" in these conversations.

There are many valid complaints to make about React hooks, but I'm not really seeing those here. And I'm not seeing evidence that you've crossed chesterton's fence with them either.

I'll criticize hooks all day, but for all their footguns, they provide a level of abstraction (and a simplicity of implementation for it) that's really hard to argue with. They let you break up reactive stateful code in maybe the most scalable way I've ever seen, and their contract with the outside world allows for some crazy optimizations on the framework's part. I think the team is onto something really special here

Of course they're also easy to misuse, and they can be really "magical" until you fully grasp them. Those are problems the ecosystem will have to grapple with (and I know the core team is aware of them). Though the "magic" at least is due more to weirdness and inversion of control than it is to actual complexity. Having a grasp on how they work, I feel like I wouldn't have too much trouble implementing a basic version of the same system myself, because the primitives are ultimately not very complicated

I believe hooks are really good bones for building UIs, and I think they'll last because of it, even though the surface developer experience has some warts for now

andrewmcwatters13• 3 years ago

I think it's sufficient to say that having been exposed to hundreds of thousands of lines of code across different industries and programming languages, I don't like React Hooks, and I don't even like them repurposing the word "hook" which is otherwise known as a trampoline in other programming language contexts.

React Hooks, if anything should have just been called React Callback Queues.

As for emotionally charged words, maybe it's not appropriate in the current zeitgeist to post without some degree first of self-censorship, but it's how I feel, so I'm going to say it.

React Hooks were fanatically adopted, in my opinion. Side effects are a regular part of programming. I find it, thusly, infantilizing to hide those details.

I wish people would stop this sort of thing, but if you want to say your part and that's how you feel, say it too.

Edit: You've apparently even been downvoted for expressing this sentiment, which I hate on HN, because it's how you felt. I wish social sites wouldn't do this. No one should be able to invalidate that.

paulryanrogers• 3 years ago

Class components remain supported, and are documented in the Legacy API section of the new site.

So they're still not breaking backward compatibility. Looks like you don't have to refactor until you need something that's only hooks based.

nagonago• 3 years ago

front ends independent of any of the existing frameworks that exist today, which I think is probably controversial

Not sure controversial is the right word, in fact I think it is quite a common sentiment among developers, especially those that originally come from back-end. The only problem is finding a company that is willing to forgo the frameworks.

They do exist though. Here's a short list of companies that use vanilla JavaScript, most notably GitHub and Netflix:

https://gomakethings.com/companies-that-use-vanilla-js/

fndex• 3 years ago

I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

Clojure and ClojureScript very much appreciate that sentiment. re-frame, a library for creating React apps with ClojureScript is rock solid, many years old, and still on version 1, meaning no breaking changes so far. 5 years old re-frame code still looks the same today.

koito173• 3 years ago

I use re-frame, but you cannot deny that class components being deprecated is going to be pure trouble for re-frame. Re-frame relies on the reagent library's Reaction interface. While re-frame does not depend on anything else in the reagent library, it is natural to use Reagent for your rendering. But reagent itself emits class components by default, since it predated hooks by several years.

Now that class components are essentially deprecated in the documentation, and the fact that React 18 support is still an experimental feature in Reagent, people using ClojureScript and React today are in quite some trouble, especially since React is the only JS framework I know of that is compatible with functional programming.

While reagent is able to emit function components, there is a performance penalty to this, since it employs some hacks in order to be compatible with both hooks and ratoms. Thankfully there are some projects that are attempting to bring modern React[1] and even bring the whole re-frame API alongside it.[2]

Last weekend I decided to try out helix, refx, reitit, and shadow-cljs' lazy-loaded modules and managed to make a pretty nice demo app that uses essentially the re-frame API but it's all modern React and hooks, and the router was capable of lazily loading modules containing code of pages the user wanted to navigate to.

[1] https://github.com/lilactown/helix

[2] https://github.com/ferdinand-beyer/refx

Rapzid8• 3 years ago

The docs are kinda poor on them IMHO. They don't approach the hooks from first principles. For example look up the useImperativeHandle hook docs. Use those to explain simple questions:

Why do you need this?
Why can't I just update the ref however I want!

Look up forwardRef:

Why can't I just access ref as a prop?

Further, everyone is trying to cram all logic into hooks and components. It's to the point of insanity. Look, React is so popular I know most are using it for throw away marketing sites and other low-tier shit (sorry y'all but you know it) but.. This architecture doesn't fly in large apps; ee b2b etc.

React Router v6 seems to have no non-hook based APIs that aren't marked private!? They screwed the pooch on useNavigation; it causes unnecessary re-renders. Surprise surprise, but if they can't get it right...

jholman• 3 years ago

React Router v6 seems to have no non-hook based APIs that aren't marked private!? They screwed the pooch on useNavigation; it causes unnecessary re-renders. Surprise surprise, but if they can't get it right...

Whoa, you lost me here. React Router is no shining beacon of good API design. They've never done things well, just "well enough". I'm not saying RR is terrible, I'm not saying the RR devs should feel bad about how bad they are or something, I'm just saying that these guys are not the guys you want to point at for "if they can't get it right...".

(Example of RR being not-so-amazing: Initially (v1? v2?) they required you to use attributes for the components that would render in a route, with no way to specify props short of making a custom component that wrapped the one you wanted. Then they added the ability to pass a function as an attribute, which let you specify props, so that was usable but clunky. Then, in yet a third version of the API (I think this is by v4?), we got the ability to use JSX in children to fully specify the components, which obviously was the right choice all along, it's literally the point of JSX. And again, I'm not saying I'm a better software engineer than those guys; I think I'd have got this one right but I'm sure I'd have screwed up a dozen other things.)

robertoandred6• 3 years ago

You call other devs “infants” but are unable to understand how hooks work. It’s really not complicated under the hood.

dxchester• 3 years ago

Agreed that investing in standards is always a good bet. But at the same time, we have so many web frameworks in part because what is spec'd in plain JavaScript/HTML/CSS is not quite high-level enough to be really be a productive foundation just on its own. Going all the way back to raw `Document.createElement` will come with its own special pain.

With the WebComponents movement though, we are getting ever closer to being able to rely on native browser functionality for a good share of what frameworks set out to do. We're not all the way to bliss without frameworks, but for what it's worth here is my 481-byte library to support template interpolation with event binding in order to make WebComponents pretty workable mostly as-is: https://github.com/dchester/yhtml

reaperducer• 3 years ago

I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial

Do it. Don't be afraid to, either.

Over the years, I've put together a list of some big and VERY big companies whose web developers hand-code their web sites without assistance from the framework-du-jour.

I recently learned about a new one for my list: A nine-figure household name tech company.

The list is useful for when I'm in bars or developer meetups or coffee shops and someone who's only been putting together web sites for a few years starts preaching about how whatever shiny new thing they just learned about in junior college is the one and only way to do things.

gratitoad2• 3 years ago

You tease. Dunno why you’d go out of your way to not name names, but it’s working: Who?

leros• 3 years ago

I'm usually the guy who is several versions behind on every library and I stick with what I know instead of exploring new features. I will say that React has been pretty pleasant to work with in regards to not forcing me to rewrite my code much. They're pretty good about keeping the old methods around our several major versions so you have plenty of time to make changes to your app or just keep doing things the old way.

atsjie• 3 years ago

I want the decisions I make to last decades, not just a few years

New to frontend?

FpUser• 3 years ago

I use some narrow scope libraries. Other than that I use plain JavaScript with Web Components. No frameworks. Saves me a bunch of time.

rwalle• 3 years ago

You probably should have a better understanding of how hooks work and why they are better before posting a long and meaningless rant like this.

There are things that you complain when you are junior, but start to understand better and realize why people do certain things in a certain way when you get more experience and can look at things from a higher viewpoint.

FactoryReboot2• 3 years ago

Hooks were the beginning of the end of my interest in React. Truly a terrible concept. Way to magic. Not overly aesthetic, not to mention the async programming techniques the js community has developed for over a decade all kinda break down with hooks.

You can’t even just keep using class based as they have no way to consume hooks.

Unit testing of hook based code is non existent IME. It’s some kinda funky E2E feeling test.

React was my favorite framework before. It’s really a shame.

SPBesui2• 3 years ago

Unit testing of hook based code is non existent IME. It’s some kinda funky E2E feeling test.

I’m guessing you’re referring to the fact that you can’t access component state like you can with class components. If so, that’s not required to do a unit test. That’s a sign that implementation details are leaking into your tests.

motoxpro2• 3 years ago

They are just so simple to me that the "magic" never comes into play. Just a function that gets called when something in an array is different between renders.

bdangubic• 3 years ago

funniest thing to me is how many people identify themselves as "react person" or "angular person" and I am thinking "you'd be better off saying you are "cobol person"

anonyfox• 3 years ago

I‘d love to have a simple way of calling ReactDOM.renderToString() on my express server that does block to actually wait for API calls so that SSR‘ed HTML is populated. I am very willing to trade performance against simplicity here.

Besides some explorations for suspense and server components, there doesn’t seem to be any straightforward solution to that problem unfortunately

alvarlagerlof• 3 years ago

Maybe you can fetch the with an await and pass it down as a prop to the component in renderToString?

ddaletski• 3 years ago

I'm always wondering, why it took web devs so many years to create some meaningful reusable UI components (and I still don't see a wide adoption of something like that)? I just can't understand how reimplementing even such things as simple buttons every time from scratch is productive

jve3• 3 years ago

Currently microsoft product line like SharePoint, Dynamics (Power Apps), Office, Teams, etc, etc is based on FluentUI https://developer.microsoft.com/en-us/fluentui#/ components that gives also the developers a close enough solution to extend UI within said products.

lloydatkinson2• 3 years ago

Which itself is React, to be clear.

qudat• 3 years ago

Because there is a lot of creativity involved when you are placing pixels on a screen. You’d be surprised by how many different ways you can render a button. There is no single abstraction that satisfies all business requirements.

JCharante• 3 years ago

To be fair the designers keep changing the designs of buttons.

s-xyz• 3 years ago

Amazing! Love it

chrismsimpson3• 3 years ago

VanillaJS/web standards all the way. I love being able ship something knowing exactly what’s going to end up in the browser. I really don’t get the react cargo cult fad, and when it finally dies it won’t be too soon.

selfmodruntime7• 3 years ago

React will never die. It‘s as pervasive than jQuery and has been for a while now.

recursive5• 3 years ago

I'd settle for the hype levels to reach parity with jQuery.

chrismsimpson3• 3 years ago

“React will never die, just like jQuery”. Lol.

klysm6• 3 years ago

Sounds nice for a solo project.

chrismsimpson3• 3 years ago

You know react itself is written in something

dmak2• 3 years ago

I don't get how anyone can build a serious application on vanilla JS. I love vanilla JS, but it would require one to re-invent the wheel to manage all the state. You'll end up borrowing tons of ideas and rolling your own framework. At that point, you might as well have used something like React, Svelte, etc...

unmole• 3 years ago

react cargo cult fad

React has been around for nearly a decade now.

JaDogg• 3 years ago

Since I'm not a real frontend developer. I just use bootstrap + jquery. It works fine for personal projects.

jmull3• 3 years ago

I can't figure out why anyone chose to use react...

I understand the "it's dominant and has a large ecosystem" argument, but I just can't wrap my head around how enough people chose it for it to reach this position.

I've evaluated it a couple times and it just looks poorly conceived. Fixes and "improvements" have rolled in, but they are also poorly conceived and themselves need fixes.

Of course I know it might just be me... I didn't get the point of tailwind either, until I used it.

But I've also used react for a reasonable sized project and I still don't get it.

christophilus3• 3 years ago

What don’t you like, and what do you prefer? I like having view be a function of state (like in traditional web apps, except richly interactive).

jmull3• 3 years ago

It’s more of an idea than a library. The idea’s good but the implementation is awkward and incomplete. You’re endlessly writing boilerplate and incorporating libraries for even basic and typical cases that a more thoughtful design would make unnecessary. Even with multiple evolutions the problems are only somewhat resolved. The virtual DOM was a bad idea from day 1 and remains so. React wants components to be the unit of rendering, but an app wants a component to be a unit of app UI. These concerns end of conflicting and competing, which the dev has to do the heavy lifting to resolve, with things like useMemo/Callback. It uses javascript to represent HTML (HTML is already the ideal way to represent HTML declaratively).

what do you prefer

Svelte, for the case you mention.

doodlesdev2• 3 years ago

The original API when it was originally released was much saner. That was before JavaScript even had "classes" which meant React classes didn't have nearly as much boilerplate. After they migrated the API for React class components to be JavaScript classes it all went downhill. And then the functional people came and the rest is history.

klysm6• 3 years ago

What's your preferred framework? I quite like react with hooks - it's the best thing (to me at least) I've used so far to make UIs.

meowtimemania• 3 years ago

React had a small simple API surface, made it super easy to create reusable components, and was more performant than some of the other dominant solutions (AngularJS)

_boffin_• 3 years ago

i'm with you... i'm with you.

sroussey• 3 years ago

Using react server components these days and don’t see much about it.

codeptualize13• 3 years ago

Why are so many comments about class components, I thought we ended that debate 3 years ago?

Hooks are better because they allow you to reuse component logic, impossible with class components. They solve all the issues and gotcha's of HOC's.

Don't compare class components with hooks, compare HOC's with hooks.

The best way to grow appreciation for hooks is to try wrapping many HOC's and deal with conflicting props and "innerRefs". People seem to very easily forget the horrors of the old.

Also lets be real, hooks aren't that bad. Yes dependencies arrays and useEffect take some getting used to, but I rarely get into situations where I actually get into questionable territory. Use react-query/swr for fetching, use Zustand (or whatever) for state, and you cut out 95% of the problems.

Anyway, the new docs are great, well done, nice work!

spankalee2• 3 years ago

Hooks are much worse because they poorly emulate classes.

What you need for components is a stateful container, with an initialization phase, a render function that can be called for each update, and lifecycle methods that are called at lifecycle events.

Classes give you exactly this:

- Constructor for initialization

- Class fields for state

- A method for rendering that can be called multiple times, which can reference state

- Lifecycle methods

Classes are simple, standard, and give you everything you need for UI components. They were practically invented alongside the concept of UI components.

Hooks try to cram all of this into the repeatedly called render method and it's just a failure.

- You have to put initialization into callbacks because the whole component is called multiple times

- It's difficult to manage object and callback identity across renders requiring useCallback() and useState() to fix

- Lifecycle callbacks are put into hook arguments, but they're just trying to be methods and end up recreating the lifecycle closure every render.

- Hooks have restrictive rules on their usage

- Hooks make a function no longer just a function. It needs to be invoked inside a hook context, making it much less portable than a constructor

- Hooks hide their state within the hooks system, making them much harder to introspect and debug.

Hooks supposedly solve this composition problem and allow reusing logic, but that is entirely possible with classes. It's just a huge amount of FUD and misinformation to say that you can't do composition with objects. All you need is an object interface that is similar to the component interface that the component delegates to from its lifecycle methods. This is a simple and standard pattern to use and implement: it's just a single line of code per lifecycle method. And it's easily introspectable with a debugger: just follow object references to the helper objects.

lit.dev does with with reactive controllers: https://lit.dev/docs/composition/controllers/

It's a very simple alternative to custom hooks, and eliminates the need for all the builtin hooks.

dylanowen2• 3 years ago

100% this. Reading complex functional components is challenging because you're creating the functionality of a class with non of the organization.

robertoandred6• 3 years ago

Sounds like you should stop trying to think of hooks as classes. They're not.

oaxacaoaxaca• 3 years ago

THANK YOU. Very well said. I've been annoyed by hooks since they came out and you described my sentiments perfectly.

orange83• 3 years ago

This kind of reminded me of the module pattern [1] popular with ye olde jQuery plugins. Just realized that hooks try to emulate what JS does natively, which is keeping track of all local variables in a functions calling scope. Meaning that if that function returns an object, that Object still has access to all the variables declared when that function run.

[1] https://stackoverflow.com/questions/17776940/javascript-modu...

zarzavat• 3 years ago

Would generator functions help?

    function* Counter(props) {
      const [state, setState] = makeState(0);
      const incr = () => setState(state.value + 1)
      while (true) {
        yield <div onclick={incr}>{ state.value }</div>
      }
    }

lmm• 3 years ago

Classes with state are a nightmare. You can never tell what has changed or where. Having the state in the hook system where it's visible to your tools and you can actually see what's changed between one render and the next is a huge win.

branko_d3• 3 years ago

Most importantly: hooks make functions that look pure actually impure.

Before hooks, if you wanted to call a functional React component, you could reasonably assume it's pure - it depends just on props and nothing else. Only when trying to use a class component did you needed to start to worry about it's internal state and how the lifecycle influences it.

With hooks, you are never sure until you look into the function's implementation!

codeptualize13• 3 years ago

It’s funny that controllers are conceptually not that different from hooks just with classes. Question: can controllers access everything on the host? As that would easily turn into a giant mess. Probably you shouldn’t but isn’t that the same as hooks rules?

Classes have lots of rules and best practices to prevent a mess, just like hooks. Also stateful classes are notoriously hard to debug as everything can change everything all the time.

I think you also should try hooks for a bit. Some of your statements about them are incorrect or really not that prevalent in normal use, you might be surprised how nice they can be. Especially use react-query or swr for fetching and something like zustand for state.

recursive5• 3 years ago

Hooks are better because they allow you to reuse component logic, impossible with class components

I've heard this said before, but I don't understand. Could you give an example of component logic that can't be reused under class components?

codeptualize13• 3 years ago

Sure! It's generally about "stateful logic". Basically logic that relies on state and/or the lifecycle methods (componentDidMount, componentDidUpdate, etc) as with classes those are only available as part of a component.

You can "sort of" reuse component logic with classes, the most common way is by using Higher order components (see https://legacy.reactjs.org/docs/higher-order- components.html).

The example in that article is pretty good: Subscribing to some external data source. That requires on mount, state, and on unmount.

Using HOC's is not actually reusing logic though, it's creating more components and wrapping them to compose the logic. It's a workaround.

HOC's have a bunch of downsides, imo the most obvious one is the props; you need to pass the previous props, and merge in the new ones. That can create conflicts. Another typical one is refs. You need to be very meticulous about structure and how you compose and order your HOC's to make sure it all works.

In hooks you can define this stateful logic truly disconnected from a component, resolving a lot of the issues of HOC's as you can just call a bunch of functions without impacting the render tree. The "plumbing" is much simpler.

Hope that is sort of clear, but let me know if I should clarify any of this.

idreyn2• 3 years ago

I have a hook that I copy around between projects called `useViewport()`. All it does is watch the current viewport size and updates its value when that changes. Because it's a hook, I can call this function from any component body:

  const { width, height}  = useViewport();
  return <div>Viewport: {width} {height}</div>

Zooming in, this is just built from a useEffect() to bind event listeners, and and a useState() to hold the current value. Zooming out, it would be easy to write a useBreakpoint() hook that mostly just calls useViewport(). Hooks compose.

Before hooks, there weren't great patterns for isolating units of stateful logic from the presentational side of React. A really common pattern was to use "render props" where a component keeps some internal state and passes it into a function-as-child:

  <ViewportWatcher>
    {({ width, height}) => <div>Viewport: {width} {height}</div>}
  </ViewportWatcher>

You'd see these provider-components nested three or four layers deep, and it got ugly. Hooks solved this.

mikeryan• 3 years ago

Take a look at Use hooks libraries for examples of code that you may want to have portability with (this is they typescript one because its the one I've used)

One of the simplest examples is "useToggle" which just sets a state variable to true or false. Not hard to write in a class component but it's still stuff that you may end up writing a lot.

A lot of similar ones are click and event handlers that need to be cleaned up after the component is unmounted.

useIsMounted is one I use a lot too to ensure I'm not trying to write state on an API callback once a component is unmounted.

You could add each of these to a class with an hoc and end up with withToggle(withIsMounted(withUseMediaEvent(MyComponent))) but that tends to be a bit of a mess.

https://usehooks-ts.com/

spion15• 3 years ago

impossible with class components

I'm not sure thats really true. In a different world, the react constructor functions would have access to `this.useState` and `this.useEffect` and then you could extract any logic you like by dispatching `yourFunction(this)`. HOC are not the only alternative design.

Hooks really push at the boundary of the language and I'm not sure they're an optimal path once you actually start dealing with state.

codeptualize13• 3 years ago

Access to this.setState would be horrible, imagine the conflicts. You need separate state, and then you sort of have hooks again.

rimunroe9• 3 years ago

Hooks really push at the boundary of the language and I'm not sure they're an optimal path once you actually start dealing with state.

How do they push at the boundary? I feel like so many people talk about them being magical, but I don't see how they're any different than any other effectful function call. Is the idea of tracking call order that exotic?

This is a very simplified example of how hooks work under the hood:

  let hookStates = [];
  let currentHookId = 0;
  let firstRun = true;

  function endRun() {
    firstRun = false;
    currentHookId = 0;
  }

  function useState(initialValue) {
    const hookId = currentHookId++;
    if (firstRun) {
      hookStates[hookId] = initialValue;
    }

    function setter(nextState) {
      hookStates[hookId] = nextState;
    }
    return [hookStates[hookId], setter]
  }

  let actions;

  function run() {
    const [a, setA] = useState(1);
    const [b, setB] = useState(2);
    
    // this is done because we're not setting up event handling
    // and we need some way to trigger external updates
    actions = {setA, setB}
    endRun();
    return a + b;
  }

  function assert(received, expected) {
    if (received !== expected) {
      let error = new Error(`Expected ${expected}, but received ${received}`);
      error.name = 'AssertionError'
      throw error;
    }
  }

  assert(run(), 3);

  actions.setA(3);
  assert(run(), 5);

  actions.setB(5);
  assert(run(), 8);

  actions.setA(1)
  actions.setB(-1)
  assert(run(), 0);

Obviously this example doesn't include tracking more than one component, but as far as I know hook state gets tracked pretty much the same as the state on class component instances.

I could understand thinking they're magical if you were under the impression you were the one calling the component functions rather than React, but I think my impression was always that it was still React's job to call the function component (otherwise, createElement seems like a waste). They might have at one point said that it was okay to do that in tests, but I'm not sure about that, and it would have been out the door the moment function components started supporting refs.

pharmakom2• 3 years ago

I guess it’s because whilst hooks improve on some aspects, they are quite counter intuitive and very easy to use incorrectly. I don’t think hooks is the final answer to side effects and state in react.

hbrn2• 3 years ago

I remember a while ago, if you were to mention HOC wrapper hell in React community, most folks would jump to defend it.

Eventually, React team accepted that it is a problem, and presented hooks as a solution. The very same people who would defend wrapper hell yesterday, would start crapping on it today.

I think you're right that hooks are flawed and not the final answer, but the community won't accept it until "React gods" say so. It would be quite funny if React team eventually decides to go compiler way (a la Svelte) and all the people grasping for reasons to hate Svelte would have to change their opinions again.

interstice• 3 years ago

Is there a hook for an error boundary component yet or is a class component still the easiest way?

sophiebits4• 3 years ago

Not yet! Other improvements have been higher priority so far.

Many people also use the react-error-boundary npm package, and some frameworks have their own error boundary APIs (eg: https://beta.nextjs.org/docs/routing/error-handling).

klysm6• 3 years ago

I encourage people to copy what they need out of react-error-boundary and tightly integrate it with their stack. It’s really not bad

Vinnl2• 3 years ago

Hmm, I can't find the "Edit this page" link that many Docusarus (which I assume this is?) sites often have, and I can't find the repo either, so I can't submit a PR, but... There's no RSS feed for the blog :(

sophiebits4• 3 years ago

Not Docusaurus, but the source is here:

https://github.com/reactjs/reactjs.org (currently in the "beta" directory)

Vinnl2• 3 years ago

Thank you! Makes it a bit more work, but maybe I'll look at submitting a PR later.

Diggsey• 3 years ago

All of the new documentation is horribly laggy in Firefox and all of the code sections are broken (eg. the visible cursor position does not match the actual cursor position...)

This is latest stable Firefox on a high spec Windows 10 laptop.

Not a great look given what React is supposed to do!

debacle• 3 years ago

I like classes because they're easier to code review and easier to read/reason about. The artifical limitations are good. At a large org that's way more important than initial write.

rglover• 3 years ago

Oh, weary traveler, if yer tired of your APIs a changin' join us o'er at the Joystick [1] and enjoy a stable sea like y've never seen bafore.

[1] https://github.com/cheatcode/joystick

funstuff007• 3 years ago

We’ve included diagrams, illustrations, challenges, and over 600 new interactive examples.

600! It's hard for the competition to keep up with that.

adamzerner• 3 years ago

I've never understood why React components are considered to be pure. The output is not just a function of the props, it's also a function of the state (as in `useState`) and context (as in `useContext`).

klysm6• 3 years ago

Agree, but it should be a pure function of its arguments and the state

isntbilly• 3 years ago

jerrygoyal• 3 years ago

People tend to overuse Effect, this article explains it well

https://react.dev/learn/you-might-not-need-an-effect

megous3• 3 years ago

Nice demo of sluggishness of React:

https://react.dev/learn/updating-objects-in-state

https://megous.com/dl/tmp/zyrzbzjqxccvvdniorpj.webm

(Top of the line desktop AMD chip.)

The code has no transition, no setTimeout, no nothing that would indicate any delay. The dot should always be right under the cursor. This will happen with every similar UI pattern (want to resize something, move a slider, etc. etc.)

I guess this is a result of tradeoffs React has to do by insulating people from DOM.

There's probably some way to force immediate DOM update, but then you're pulling in a lot of useless diffing and checking for each frame, instead of just updating the single el.style.something property you'd do when directly using DOM API and leaving the browser to do the rest.

senttoschool2• 3 years ago

(Top of the line desktop AMD chip.)

Slightly off topic but my M1 Pro Apple Silicon Mac does not lag like your top of the line AMD chip.

I know most consumers run React code with CPUs slower than Apple Silicon chips but this post is more of an endorsement for the M1 lineup.

geodel• 3 years ago

This is relief. I was afraid that M1 Max would be minimum requirement for smooth experience.

jhugo• 3 years ago

Zero lag on my M1 MacBook Air too.

megous3• 3 years ago

You're comparing different software rather than different CPUs.

andrewmcwatters13• 3 years ago

This doesn't have anything to do with React, it has to do with refresh rate, vertical sync, and the fact that your cursor position is updated by hardware and doesn't undergo the same update process as the rest of UI compositing in an operating system.

Draw a software cursor, and the same exact thing happens.

In fact, in effect, the red dot is a software cursor.

You can accomplish visualizing the same lag in a traditional update-draw loop in game software.

Cursors are special. Sibling comments here don't experience the same effect, because they're running displays at higher refresh rates.

That's it.

megous3• 3 years ago

Hm, right. Good to be corrected. Not sure why the lag is so big, though. Looks like it's 3 frames looking at slowmo capture of the screen.

I guess you can take your cursor position at the beginning of scanout of the previous frame, render the new browser layer content, tell the compositor to update both cursor layer position, and browser layer at the next scanout, and both should have matching positions on the next frame. Maybe if the compositor is updating the cursor layer position from mouse position known right at the momen of atomic commit, there may be some difference.

Well, this is Xorg I'm using, and it's not using atomic DRM API, so things are not well synchronized.

ajkjk2• 3 years ago

For anything like animation in React I would use CSS transitions or using direct updates on refs without triggering rerenders. It takes only a simple model of "what a rerender is" to understand that this is running potentially _way_ more code than it needs to for every update and injecting scripting frames before the actual animation update happens.

So this should be `ref.current.style = {x: <whatever>, y: whatever}`. It's also a great use for useImperativeHandle() if it gets any more complicated. This is the example from the docs updated to use a ref: https://codesandbox.io/s/lucid-grothendieck-iquzfj?file=/App...

On this example it pretty much looks the same, which I assume is because of what the sibling comment says, that any cursor drawn in software is going to be slower than in hardware, and the animation and app are trivial so the rerender is basically free. But this way is still better, and it'll be more obviously better if the components being animated are complex. There's not going to be any way to do it faster in JS, but React can be a lot slower depending on what happens on rerenders (which is often, if using imported components, somewhat out of your control).

herpderperator• 3 years ago

Apple M1: https://www.dropbox.com/s/ivz9hr2pcer5pt1/react_dot.mov?dl=0

dmak2• 3 years ago

If you're doing anything animation related, there is no point in using React's useState because it causes re-renders. The right approach here is to use useRef.

mmis1000• 3 years ago

Do you have mouse that have much higher update rate than monitor? The mouse event frequency is generally capped at the update rate of monitor unless you use `pointerrawupdate` which will actually give you raw mouse event without delay.

Rapzid8• 3 years ago

There will always be the potential for lag because the OS UI thread is updating the native mouse pointer position separately from the browser UI thread updating the page.

A similar issue occurs with native scrolling and fixed position elements whose positions need update every frame. You must take control of the scrolling in JS in order to prevent jitter.

mattgperry2• 3 years ago

Your intuition is correct - there's nothing to indicate any delay.

Look at your profiler. Notice any significant overhead? You don't.

Implement this same thing using events and `.style` directly. You will get the exact same result.

The pointerEvent => style feedback loop is unfortunately very slow, more or less so in different browsers/operating systems.

Interesting that you would know so little about this and yet feel confident enough to make a proclamation like this is evidence of React's performance.

njsubedi• 3 years ago

It’s funny how react.com redirects to reactjs.org and that redirects to react.dev domain because most companies only use newer tlds because dotcoms are unavailable

intellix• 3 years ago

You can pretty much skip React and go straight to Qwik as it solves N+1 and it fixes the ability for low quality devs ruining perf with useEffect since you have signals ala Solid

tomgp• 3 years ago

Lovely site but it got my hackles up right off the bat ...

"The library for web and native user interfaces"

_A_ library, it's _a_ library not _the_ library.

liendolucas• 3 years ago

I was relatively happy with the React class model, for me it was very clear just to override any required methods in a class.

To this day if I need to do something in React I can pick it up quickly because is a very simple model: it follows the template design pattern, which is one of the most powerful and dumb design patterns (I'm talking obviously about the class model).

What's my current issue with React? Well in the same way that they have decided to go with hooks and all that, nothing is preventing those folks tomorrow to wake up to say: "You know what? What we really really need is not functional components but a hybrid approach, not fully functional not fully object oriented" and then the game starts again.

I worked for a very limited time in one company not long ago, and a guy there came and said something like: "We really should start using hooks" and I replied: "Really? Why? Can you show me a true or concrete advantage using the functional style over the OO approach?" then he said: "Well, I don't really need to do that just watch this video" and sent me a link of a video (if I recall correctly) of the creators explaining all the hooks stuff. I didn't even bothered to continue discussing (how can you discuss when someone is 100% biased?).

My point is that many people out there just take for granted whatever ideas these people are pushing out and not questioning things anymore. I'm not saying that hooks are good or bad a thing (I really don't know and if I need to learn hooks because that's the style used in a codebase, sure I'll do it and probably learn something), but blindly embracing things just for nothing is harmful.

ruicaridade• 3 years ago

To me, the main benefit of react hooks is it eliminates higher-order component hell. It's so much easier to extract common behaviour from different components to a re-useable hook, rather than wrapping a class with a million different higher-order components: `withRouter(withFoo(withBar(MyComponent)))`.

codingdave• 3 years ago

When hooks came out, myself and the other senior devs on our team had that same inertia-driven reaction. We knew classes, we were comfortable with classes, and they worked. So we asked the same question - "Why hooks?"

So we sat down and actually used hooks for a few days - refactored small and large components to be sure we understood them and saw the difference in the code. We found it to be a perspective change -- once we made that change and got used to the new syntax, we loved it. Our code was simpler and easier to maintain. Once we really learned when to use useEffect so as to not abuse it for everything under the sun... the code got better still.

So while you are correct that blindly embracing hooks would be harmful... Blindly rejecting them is equally harmful.

willio58• 3 years ago

Same experience for my team a couple years back. We hated the idea of changing everything to hooks, then we actually started using them and fell in love. So much complexity fell out of our code we couldn't justify sticking with class components.

Having said that, there are some gotchas with hooks that aren't trivial and can make them difficult to use/understand without significant comments. But hey, what code doesn't fit that description?

DyingAdonis• 3 years ago

React is a leaky abstraction.

https://twitter.com/clark_gunn/status/1636565797412773888

FractalHQ• 3 years ago

As someone who learned web dev with Svelte, it seems so obvious to me that React is full of convoluted apis born from tech debt, and such a bad DX compared to what is possible today. I imagine if I learned React first, it wouldn’t be nearly as obvious to me how mush worse it is than it should be.

Introducing react.dev

Related Stories