Comment by motorest | Hacker News Reader

Comment by motorest | Hacker News Reader

Parent Full thread

> The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").

I think this argument isn't valid. The problem that React solves is creating reactive user interfaces. React is trivial to use in it's happy path. The tool's complexity is a red herring because using the tool is trivial and effortless.

To me, this argument is based on specious reasoning. Take for example vending machines. They are trivial to use: pick a product, pay, see it drop and pick up your item. It's dead simple. Does it make any sense to whine that buying items from an automated system is a problem not everyone has, and that the vending machine is far more complex than a seller behind a counter? No. What makes sense is the complexity from the user's perspective, and what effort it requires them to achieve the goals they set forth to achieve. And React makes it trivially easy to put together highly performant reactive web apps.

Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.

> Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.

No, not really. There is more to picking up a tool than some rando's simplistic drive-by judgement. For example, say you have a React SPA managed by a team which built and manage their whole platform, from the CICD pipelines to the hosting solution. All your infrastructure was built around providing a React app and it's backing services. You are then suddenly faced with a need to implement a feature where a user after clicking on a link navigates to a page that just shows static text. Now think. If you implement that page with React then that's a one-point task. Just create a component, fill it with text, post a PR, done. What level of effort does it take you to implement that with another technology? If you go with the simplistic take that plain HTML is better, now you need to set aside time to sort out support for styling, sort out where and how to deploy those assets, work on a process to automate the deployment, etc etc. Now your simplistic drive for simplicity turned into something between a week and a month's worth of work requiring infrastructure changes and adapting deployment strategies, all of this requiring not-so-trivial QA and testing work.

What problems did you solved? Can you describe your system as simpler, and keep a straight face?

You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter.

> You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter.

Not really, the article is about a belief some other approach would be preferable based on superficial and specious reasoning.

My example proved that this kind of superficial and simplistic analysis fails to account for critical aspects which are key to explain why a decision was made.

This doesn't go away by complaining that I refuted your point while I could easily not refute it.

The whole argument is silly, if you think about it. What could possibly possess anyone to believe they are the only ones who know better and everyone else in the world who disagrees is stupid and doesn't know what they are doing?

> The article is about the latter.

And yet fails to provide a single example.

I'd certainly be interested in seeing what kind of websites this guy produces that are written in "javascript". If any. And it is rather damning that his own website that host the blog is written in react, not "javascript".

> They do it because someone else told them so.

Alternatively, they do it because if you are holding a React, everything looks like it should be implemented using a React. While the finished product might be more complex than needed, it is less complex for them, because they have used a tool they understand well.

> people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.

No, they do it because it's simpler.

Maybe they do it because they like React? :)

> The problem that React solves is creating reactive user interfaces

The problem that React originally aimed to solve was creating reactive user interfaces in facebook's monorepo monolith where 1,000+ software engineers are constantly churning code.

This is potentially not the same problem that you are envisioning there, and it tends to put rather different constraints on the solution.

> The problem that React originally aimed to solve was creating reactive user interfaces in facebook's monorepo monolith where 1,000+ software engineers are constantly churning code.

Nonsense. React's selling points have nothing to do with repo structure or the number of engineers working on a project.

If you ever used React at all, you would understand that updating the entire state of the appocation after receiving any input is a non-trivial feature that React turned into a trivially solved problem.

On top of that, React adds modularity and composability.

I wonder if you're criticizing something you have absolutely no experience in.

why it does things the way it does is relevant - the reason facebook had problems with state management and modularity was the sheer number of engineers working in a single shared codebase (I was there, it was miserable)

If you were building a state update layer without Facebook’s constraint of extreme scale, it might look rather different

(Also, I’m not criticising react - it solves a variety of problems well. If they are the same problems you have, great)

> why it does things the way it does is relevant -

Yes. React automatically detects the minimum set of changes to a DOM that is required to update it's state, and manages how those updates are applied to maximize performance. It transparently handles both app state changes, and basic changes to views triggered by updates to models.

This is a problem everyone in webdev has. Everyone.

Did you saw any of the comments here on how a little JavaScript allows people to update the DOM?

> the reason facebook had problems with state management and modularity was the sheer number of engineers working in a single shared codebase (I was there, it was miserable)

No.

The reason why Facebook had problems with state management and modularity was because Facebook had to maintain websites.

The reason why Facebook developed React was because they had clever people who identified the problem and were given resources to work on a way to turn a hard problem they experienced into a trivially solvable problem.

Companies, big and small, develop their own tooling and infrastructure to improve efficiency, and they do it all the time.

The argument is valid and doesn't need over analyzing.

Using react for simple simple things makes it not simple.

> The argument is valid and doesn't need over analyzing.

No, it isn't. A big part in your failure to understand the problem is your refusal to look at what you're doing, which you try to dismiss as "over analyzing". As if reaching the conclusion that a simplistic proposal brings unacceptable tradeoffs means you are looking where you shouldn't.

> Using react for simple simple things makes it not simple.

Did you actually took any time to think through that assertion? I don't think so. For starters, you didn't even stopped to think why React is used at all. Why was that?

Reply on news.ycombinator.com