Hacker News new | ask | show | jobs
by throwaway4good 722 days ago
Could it be that you never tried to understand react and why the approach makes sense to millions of developers?
2 comments

We could waste each others time getting into the specifics but I can summarize it.

It has affordances and design patterns that inexperienced, new, novice programmers find attractive and tempting but comes with all of the warts and issues surrounding intuitive patterns. That's why it takes over 10 years to get good at programming - counterintuitive insights are the clarifying beacons on any sufficiently complex project.

People are "react programmers" instead of actually understanding the specs, standards, javascript, protocols or how things actually work.

It's about 100 times easier to find a mediocre junior programmer than a comptent one. React allows, at a great cost of time, resources, and money, a large team of mediocre junior programmers to eventually create what once required a competent engineer and that is why it's popular.

Your offshore outsourced $15/hr programming firm can now make a half-assed website or app and you don't actually need to find someone who knows what they are doing.

If you've actually worked in the industry, actually dealt with code, been put on projects that are off the rails, you know this is true. You know this is exactly what is happening.

Then management is unwilling to pony up the $250k to attract the right talent so you get stuck with the job of making heroic efforts to prevent the house of spaghetti from collapsing.

You've been there. You've done this. You know exactly what I'm talking about.

I don’t think it’s fair to blame React for the flood of shitty people. It’s a symptom of the problem, not the cause.

If I had to manage the collapsing house in Rust I imagine it’d be much, much worse (though I can’t say I ever had that experience, so who knows?).

What you write about has got nothing to do with react.
I'm sorry. I can't respond to such flippantly rude insincerity without violating the Terms of Service
I do not mean to be rude but what you describe is an organizational problem.
This is perhaps my least favorite reasoning: you're holding it wrong. There will always be organization issues. Conways Law exists. The tooling matters because it encourages or is ergonomic in certain ways.

I hear this in my circles around Python which encourages spaghetti code and reaching into private parts of other's code. Yes, you can prevent this with better libs/modules, solid leadership and a steadfast resolve with adequate tooling. Or you can use a tool that makes spaghetti harder to write and pick something like .net or Go.

They're inherently connected. https://en.wikipedia.org/wiki/Conway%27s_law

There's an extension to this - a codependency. The system imposes structure back up the chain.

These choices can become good organizational fits because they reflect the separation of concerns of a project decided by management. It's almost invariably a management that doesn't know how to code or build software.

I will give you this: The emergence of mature powerful web browsers made it possible to move a lot of functionality to the end-user's device and that gave raise to the frontend / backend developer split. But you are pointing to a specific frontend technology (react) and that is not the culprit here.
> Could it be that you never tried to understand react and why the approach makes sense to millions of developers?

Could you summarise it for me? Sort of along the lines of:

<this is what is needed>:<this is what React provides>

It was the "view as a (pure) function of your model" approach that was architecturally new in react.

This article explains it using a bit of react jargon (action, store, dispatcher) which is kind of unnecessary - but that's what I got from a quick google:

https://medium.com/@asif-ali/react-architecture-vs-mvc-unidi....

React Architecture vs. MVC: Unidirectional Flow Advantage.