Hacker News Reader

I'm all for an advancement that simplifies things, and from the sound of it, hooks enables writing of simpler code.

Two things stand out about hooks to me (from what I have read, have not used them yet):

1: well suited to writing functions rather than classes - this is appealing because there is a line of thinking that values function composition over object orientation.

2: it sounds this finally solves one of the major challenges in react which is simple cross cutting. Cross cutting was always painful and I'll be very happy if this is cleanly solved.

I'm hesitant about new functionality that increases complexity, or is harder to understand and grasp. I'm very enthused about anything that goes the other way.... the industry must constantly strive for simpler ways to do everything.

I think the crux of the issue is agreeing on what is 'simpler code'. I think using lines of code as a measure of simplicity is flawed.

For me simplicity is the three C:

Clarity, in terms of how many concepts do I need to know to understand given some lines of code. The fewer the better.

Coherence, how similar is the expressions I write to what I want to say in terms of the given language. The more similar the better.

Confound, how surprising is the behavior of the code? the less the better.

The issue with hooks I think is that they're trying to treat symptoms rather than solve the problem, if you read the original motivation document by Dan, it talks about State Logic Reuse, Complex Components and People Don't Understand Classes; I think these problems can be tackled much better by their own without trying to add more APIs to React or taking drastic measures like completely change the way people think about React components.

@omeid2 I think you've distilled the issue very well -- it's all about "what is simpler code?".

I hadn't thought of the issue in terms of the three C's you've mentioned, but the criteria also seems accurate.

In my opinion, the popular SPA frameworks (Angular, React, Vue, etc) all suffer from similar problems. They build abstractions on top of abstractions, they force you to learn domain-specific languages (e.g., JSX), lots of new concepts to learn before you can be productive, they are fairly opinionated about how your application should be structured, etc.

If you have the time, take a look at this JS framework I put together ( https://github.com/elliotnb/nimbly ) and it's state management dependency ( https://github.com/elliotnb/observable-slim ). I built the framework so developers can take advantage of the benefits of modern frameworks (templating, data binding, state management, no explicit DOM manipulations, automated unit testing, loosely coupled modular components, etc) but without the typical drawbacks of modern frameworks. The framework has far fewer abstractions than React or Vue, requires no domain specific language (i.e., you write in plain HTML, CSS and JS), and does not require compiling/transpiling. The framework embraces the DOM instead of abstracting away from it and still refreshes/re-renders components in a highly performant manner via DocumentFragments.

We've used the framework fairly extensively at my work because it plays very nicely with our jQuery-heavy legacy code and allows for much easier re-factors.

The observer library has gained a fair bit of interest from other developers (~2k monthly downloads via npm) and it'd be great if I could interest others in trying out the framework too. I'd love to hear feedback from anyone who takes the time to try it out. Other contributors would be fantastic.

> I hesitate to bring up a cliché, but it's starting to feel like React is the new jQuery

I don't understand this comparison. jQuery extended the existing DOM API to make it more user friendly and made it cross browser compatible (an incredible thing in it's age). React does nothing like this - it brings a completely different concept to designing user interfaces that has nothing to do with the DOM api.

If anything, I see hooks as a response to the community that was installing React+Redux(mobx/whatever global state manager library is flavor of the week) by default. This feature makes it possible to use React as more of a one stop solution, which I definitely welcome.

> I'm already trying to anticipate what comes after React, in which case I want my code to depend on the smallest possible API surface area.

That's a fools errand. The code I wrote 10 years ago that relies on jQuery still relies on jQuery (and guess what -- it still works the same as it did when I wrote it!). And the code I wrote 5 years ago that relies on angular1 is still in production (and guess what -- it's fast and incredibly bug free because it's had so long to work out the kinks). Despite these frameworks no longer being fashionable, they still serve in production environments fantastically.

You don't have to rewrite your user interface code just because something else came along. You can embrace the positives of the library or framework that was being used at the time you wrote that code and create a rock solid application. Your goal shouldn't be to write code that depends on the smallest API surface because good code that correctly uses a well written API (which both jQuery and react are) will not be hard to maintain down the road regardless.

1. Isn't React sort-of magic to begin with?

2. Don't hooks remove the need for redux, etc.? Meaning, don't hooks radically reduce the amount of libraries you need to know about?

3. I prefer to use pure React and not have to choose between Redux, Flux, Mobx etc. And, then do I need to use redux-thunk, etc?

I actually really like the progression towards hooks. I think the articles from the core team (like Dan Abramov) have been well written, explaining not just the how but the why, and it feels like hooks serve to make things simpler and more readable. Yes, you have to throw away a lot of things you spent time learning, but I'm not sad to see anything go away that hooks now handles.

I feel like if hooks remove the need for redux for you, you actually never needed redux in the first place.

What Redux brings to the table is separation of Data from Components, it is not uncommon to use the same data point (user profile, user organization/s, et al) in various components. Moving this to component states either requires a lot of prop passing or duplication (api calls!), short of using Context, which is kind of Redux-ish all over again.

> Isn't React sort-of magic to begin with?

That's true, especially JSX caused an uproar in the beginning as "too much magic", and then was gradually accepted as a vast improvement to previous/other ways of templating.

> Don't hooks radically reduce the amount of libraries you need to know?

I'm really hoping so! If they do indeed "serve to make things simpler and more readable", it would be a net positive, regardless of any initial misgivings and possible effort to migrate.

React's core isn't magical insofar as its core functionality (virtual DOM + "update everything on any change") could fit on a 3x5 index card. Implementing it is definitely hard though...

Yes. You need “magic” to be able to write and Reason about your programs in a functional style, while still having side effects and state that changes over time. All functional programming environments have this.

I hardly think "not being pure functional" is what the op means by "magic"

Perhaps not, but React hooks in my opinion aren't any more magical than the other internals of React that allow you to use a function style to implement component trees that change over time.

>Magic, in the unfavorable sense

This is a common first criticism. There isn’t much magic going on implementation-wise (you could probably implement a simple version of Hooks yourself in <200 lines).

The static call order is controversial. But I strongly encourage you to play with it before forming a final opinion. Pretty much everyone who loves it now hated it at first. (I’m not an exception to that.)

It’s not even as much a technical limitation (we could make arbitrary order work) as confusing semantics if you remove it (how can state be conditional?).

So static call order seems like something you’d enforce with a linter anyway. At that point the cost of allowing dynamic call order becomes not worth it. (Both in API and runtime overhead.) I wrote about it here: https://overreacted.io/react-as-a-ui-runtime/#static-use-ord...

Magic is bad when it’s confusing to use or debug. There are some challenging aspects in using Hooks (like in any programming model, there are cases made easier and cases made harder) but the static call order is not one of them in practice.

>Scope creep: if anything, I wish React focused on reducing its size and API surface.

Regarding file size, ironically, Hooks can decrease the overall app file size because function calls minify better (more things can be mangled). The implementation itself makes up for less than 4% of React.

We’re working on making it smaller — but there’s a balance between size, runtime performance and providing abstractions that help remove application and other library code (usually much more impactful). Numerous libraries that migrated to Hooks reported savings in size.

>the goals of hooks would have been better served with a separate, tiny library that doesn't need to know anything about React, and usable anywhere else, with plain functions that can be tested or reused independently.

Regarding API surface and the notion of what should and shouldn’t be in React, you might think about it differently if you think about React API from first principles.

Here’s a longread you might find interesting that talks through 90% of React on one page, including Hooks. https://overreacted.io/react-as-a-ui-runtime/

Cheers.

Thank you for the thoughtful reply. I'm a fan of your work and writings, they've been valuable for the whole JS/React ecosystem.

> you could probably implement a simple version of Hooks yourself in <200 lines

It reminds me of the Egghead video course in which you described "how to write your own Redux". That was a great explanation of the paradigm, and transformed how I think about state management in an application.

What I love about the concepts behind the paradigm, is that they can be implemented (as they are in Redux and elsewhere) as a handful of tiny functions that work with or without React, for composable and reusable state and actions.

I think my hesitation about Hooks as they're implemented, is that it seems to go against the ideal of de-coupled, pure functions. Although it does encourage that for the users of hooks, its own implementation feels coupled and impure.

For example, people are applying the Flux/Redux paradigm outside of React components and the UI/views layer, like server-side or independent features that need to manage their own states. I wish that Hooks had taken a similar approach to Redux, as a canonical approach to a generic and generally applicable paradigm, where one could "write your own Hooks".

> I strongly encourage you to play with it before forming a final opinion. Pretty much everyone who loves it now hated it at first. (I’m not an exception to that.)

Yes, I'll keep an open mind and study it more.

I read "React as a UI Runtime" when it was published, and it was insightful (will read it again to really digest it). I do love the concepts and principles on which React has been built, so I'll try to understand the reasonings behind how/why Hooks were implemented the way they are.

FWIW, I wrote up an alternative proposal for hooks that was based on pure functional programming patterns.

It's more complex but doesn't resort to the impure functions like hooks which cause the same order/conditionals rules.

https://paulgray.net/an-alternative-design-for-hooks/

I think the next big framework will build on top of the declarative jsx-style rendering from react, while also providing pure abstractions of the side-effecting browser APIs

Interesting! Please do submit it on HN, I'd be curious to see what people think.

I think I agree, but we'll see. Personally, I'd like to read about the politics that lead to this kind of feature, rather than just the feature by itself.

Not sure what you mean by politics in this context, but I explain the motivation here: https://news.ycombinator.com/item?id=19206401

Happy to elaborate on specific points. (This is a very condensed summary.)

A slightly longer version that requires less context: https://medium.com/@dan_abramov/making-sense-of-react-hooks-...