Hacker News Reader

Comment by phailhaus | Hacker News Reader

Yeah I absolutely love hooks, but it definitely has a learning curve. But damn, you can do nearly anything with it. One of my favorite projects involved using hooks to manage p2p connections using WebRTC, which would have been a nightmare to write without hooks. Haven't looked into signals yet, it's interesting that it almost looks identical. I wonder how it decides when to rerender.

View on HN

So you're building business logic into your view components? This used to be simple in the old days when we used MVC.

No it wasn't, MVC was a mess because your views would trigger your controllers, which would propagate changes back down to your views in entirely unpredictable and inconsistent ways.

With hooks you're still free to manage business logic elsewhere, it just means that you can trivially reuse them across your application without worrying about order-dependence. So I was able to write a hook that returned connection state, and then drove my views off of that reactively.

I think you're thinking of MVVM, not MVC.

Which honestly was most SaaS products. My first internship was MVVM and killed my motivation to ever do web development.

9 years later my new work involves some react (barely 15% of the job tbh) and I really don't hate it as much.

It's MVC. Having your views driven off models is nice in theory, but a disaster in practice as the number of models proliferates. You lose control over how and when your views render, which results in all sorts of subtle and strange bugs that are difficult to debug. Each view may have its own logic for what to do when the model changes in specific ways, and what controller events to fire in response. Without unidirectional data flow, trying to even reproduce a bug becomes a nightmare.

MVC is unidirectional.

Nope, not between views. View triggers controller, updates model, triggers some random set of views to update, which triggers controllers, which triggers other models, etc. There is no hierarchy there, nor any batching to avoid rendering inconsistent intermediate state. You have no control of how an update affects your UI.

With React, data flows down from the top of the component hierarchy, always. And it doesn't render until all state changes have been made, so you only render after your data has reached consistency.

Incorrect. In fact, you can use React as the 'V' in MVC. That's how it was orignally designed. See here: https://github.com/facebook/react/tree/015833e5942ce55cf31ae...

I am done with this thread.

One of my complaints about reading computer science and/or programming books in the early 2000(or late 1990s?) was the contradictory definitions of MVC in books I read at the time. I think one book even indicated that MVVM(I think) was often referred to as MVC as an explanation for why this happened. So it understandable people still have conflicting definitions.

Here is a random example[1] I pulled up of someone one thinking MVC is not unidirectional but MVVM is. I am not commenting on the correctness of this impression.

> MVVM is better than MVC/MVP because of its unidirectional data and dependency flow. Dependency is one way,...

[1] https://dev.to/vtsen/mvc-vs-mvp-vs-mvvm-design-patterns-443n....

That's not what we're talking about at all, and you've lost the plot. The reason why React has won out for over a decade is because of the abject failure of MVC to materialize its benefits. It just doesn't scale.

What about it doesn't scale? Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. If MVC doesn't scale the folks who maintain those frameworks would have noticed by now.

The issue is that React was never (as far as I'm aware, please correct me if I'm wrong) encorporated into a full MVC (or similar) framework; its original intent was to be just the V, taking state (the model) and rendering it.

But what happened instead is that people wrote the controller parts into React components as well. In some codebases there's a very clean separation - 'logic' components that handle and manipulate state, and simpler 'view' components that just take props and render something.

But I haven't yet seen a framework that uses React as just a view layer.

Reply on news.ycombinator.com