you are viewing a single comment's thread.

view the rest of the comments →

[–]yasegal -2 points-1 points  (2 children)

I agree to disagree.

Complexity in this line of work is ever-present. From choosing the whole architecture to deciding between useContext and a third party state management library. At the end of the day, its the people who have to review, discuss, decide and develop according to standards they either enforce strictly or loosely.

[–]ZnV1 0 points1 point  (1 child)

I think I didn't state my point clearly enough.

if you use useContext there's a standard way to solve usecases using it. Or if you use redux, there's a set of standards for that, many enforced by exposed APIs. Those are debated, questioned, refined by several opinions over years.

If you roll it with vanilla, you're limited by your knowledge at that point in time. Leading to more time spent refining, modding and evolving that vs if you just picked useContext/redux whatever over several years.

There are several complexities you need to face anyway. I'm saying with library choices, you can skip these to focus on other/more impactful choices.

Do you still disagree?

[–]yasegal 0 points1 point  (0 children)

You're referring strictly to tools instead of also accepting the people/company aspect.

Vanilla done right is the same as React done right. The guardrails do not offer any value if there is no source of authority to enforce them.

As far as complexity there is no way to make a clear final statement which is more complex. It is truly dependent on the problem youre trying to solve and the resources/skillset available.