[andrewstuart]

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.

[omeid2]

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.

[EB66]

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