Hacker News Reader

Comment by PKop | Hacker News Reader

> I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be.

It is. Because through experience developers realized these concerns need to be addressed, and handled... by something. It is unavoidable to have a useful application. Having the framework integrated to help you do so is much less painful than piecing together separate tools, or having 20 different libraries construct their own way to do so (if it is solveable in a uniform way that simply needs to be advocated and agreed upon).

But in any case, why can't you just not use them?

What is the pain point caused by ignoring the changes... and choosing separate tools to solve these problems if that's what you prefer?

View on HN

Well, with any large, complex system, you have to learn enough about everything to know what not to use. I have been developing applications of many types for decades and it seems every time I look at react (I am responsible for one production react app that I did not write) it seems there is some new major change on how to approach the entire framework...it's daunting. And with all the constant changes to the main underlying technologies (HTML, CSS and JavaScript), it's even more so...

If the Jquery authors said ‘if u don’t like sizzle selector, feel free to use standard dom functions to grab your elements’

We’d all be pissed if the sizzle selector wasn’t awesome and well thought out api.

What I keep seeing with React is really bad api design with things like hooks (because classes are so complicated, someone link that documentation post) and redux is horrific boilerplate to manage global state.

Ok no problem, don’t use it. Discourse ends there right?

No I’m sorry, reducers, hooks, ‘suspense’ stuff is not intuitive. This needs to be properly discussed.

Can I possibly even start the discussion at why the hell these things are being named in this way? Is that not a start? Functions and Classes are stupid? A debounce function that’s possibly a promise, stuff we know about, is suddenly like the ‘suspense’ api? Does any thought go into this anymore for how average developers have to approach this horseshit?

> Can I possibly even start the discussion at why the hell these things are being named in this way?

This reminds me a lot of Perl with its creative naming for things, e.g. promises giving you a `Vow` object that you can `keep()` or `break()`. Or how you `bless` an associative array into becoming an object of a certain class.

On the one hand, it is good to have precise and specific terms without reaching for a thesaurus or overloading the same term (e.g. the many meanings of `static` in C).

On the other hand, if every framework and language invents its own terms for everything under the sun, that will not help polyglots or newcomers.

(On the third hand, we have foreigners trying to spot a difference between a "promise" and a "vow".)

Promises are my favourite example of this, because just between C++, C#, JavaScript, and Perl, I can find three-and-a-half different taxonomies for the same functionality.

Those are advanced resources. For what they do, they are pretty straightforward, but if you are just starting, you don't need to care about reducers, hooks, suspense. You don't even need to do a SPA to take advantage of react, thus, you don't even need a router to start.

You sound like such a shill. You don’t need anything in this life dude. But let’s say you do, or let’s say a subset of people do, and the feedback they comeback with is ‘this thing could be a lot better’, and shills like you come back with ‘well you probably didn’t need this’. Give it a rest.

Well. You're free to improve on it them. Maybe doing something useful would help you to control your anger issues, dude.

Reply on news.ycombinator.com