5 ms·

After spending so long writing React code, I'm now working on a large Vue project at work. Everyone used to say Vue was the easier of the two, the more approach

After spending so long writing React code, I'm now working on a large Vue project at work. Everyone used to say Vue was the easier of the two, the more approachable option — but I'm starting to see it differently. React, in its elegance, gives you components that are essentially just functions — and beyond that, there's not much more to it (setting aside the whole Next.js ecosystem). It's the most elegant thing I've encountered in frontend development. Vue, on the other hand, feels like a jumble. You can tell it was clearly adopted and glorified by backend developers who didn't want to properly learn JavaScript — and what emerged is this awkward mashup that never quite coheres into something clean.

b4ckup 4mo ago
I never get this take. A react component is not just a function, it's a function plus a magically injected context that is accessed through hooks which requires all kinds of guarantees that you have to be aware of otherwise it will have hard to debug consequences. Imo it's anything but elegant. I did projects in all major frameworks and am building a huge angular web app currently. In angular a component is represented as a class plus template (plus styles). A event listener is mostly calling a method on the class. A state can be as simple as a property on the class. It's very natural and there are way less caveats (although not zero).
- TonyStr 4mo ago
  Maybe you would prefer React's class-based syntax. It's still there if you want to use it
  - b4ckup 4mo ago
    I actually do and my critique is directed at function components which seems to be the standard nowadays.
- mpweiher 4mo ago
  > I never get this take. A react component is not just a function, Exactly. I did a somewhat longer writeup a while back. https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... The pull request is still open :-)
  - SebastianKra 4mo ago
    Interesting that you still stand by that, even after Apple moved to the exact same model with Swift UI. Narrowmindedly worrying about syntactical differences is contributing nothing to the conversation. The point is relinquishing control of state to the framework (be it via props, hooks or @State), and drawing the UI as a pure representation of whatever the framework tells you. Hence ui = f(state). This gets you a metric ton of advantages, which is why every modern framework is doing it. Classes, by themselves, are inadequate as containers for state unless that state must only exist in memory and never be observed, synchronized or serialized. You can attempt to patch that with decorators, ORMs or whatever, but now you're doing the same thing as React is doing with functions.
    - mpweiher 4mo ago
      Interesting that you would think Apple introducing Swift UI would have any bearing on the correctness of that blog post. Why do you think it would? Did you misread my post as "ha ha, Apple does it differently and therefore react is wrong"? If so, you certainly misread it a lot, and you have the wrong person. I have tons of posts about Apple getting things wrong. Anyway, did you miss the following part? I also think that despite all the flaws, react.js and react.native are currently eating native development's lunch. Clearly I made the point in my post that this approach has a lot of mindspace, despite the obvious flaws, so not sure how you pointing out that this approach has a lot of mindspace invalidates my post. > Hence ui = f(state). Every UI is always some mapping of the state. Otherwise it isn't really a UI, is it? What would it be, in your opinion, if it didn't map the state? > pure representation What does "pure representation" mean to you? I covered in the post that it sure as hell isn't a pure function of the state. And cannot be. Did you miss the part where David Abramov conceded that point? To elaborate a bit, React components aren’t always “pure” in strict FP sense of the word. They’re also not always functions (although we’re adding a stateful function API as a preferred alternative to classes soon). Support for local state and side effects is absolutely a core feature of React components and not something we avoid for “purity”. > This [ui=f(state)] gets you a metric ton of advantages, Well, yes. Like being a working UI, for example, which is why MVC is also structured this way. But can you elaborate the specific advantages you believe the react approach gives us over, say, MVC? The post elaborates that it would be really nice if UI were a pure function of the state. But it just isn't. And trying to pretend that it is might seemingly buy you some of those advantages, but at a huge cost.
- satvikpendem 4mo ago
  React uses an algebraic effectful function model which is elegant once one understands it: https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/
  - b4ckup 4mo ago
    So it makes sense because there's a fancy name for it? For a moment let's just imagine you are inventing a brand new UI framework. You obviously want to have components in it. So how do you represent a component in your new framework? A component needs state, logic and a way to render that state. Do you choose to represent the component as a class which naturally encapsulates state as properties and logic as methods or do you choose to represent components as functions which lack state so you bolt it on via an implicitly injected context that you access via abstractions?
    - satvikpendem 4mo ago
      Read into how OCaml 5 does it and you'll have your answer.
TonyStr 4mo ago
How long have you used Vue? I had a similar opinion on Vue a few years ago, coming from a background of React as well. But now I prefer it over React, and reach for it in both personal and professional projects. The ergonomics are a bit different; there are things that are easier to do in React, and things that are easier to do in Vue, but the fact that it uses signals is a huge plus for me.

b4ckup 4mo ago

I never get this take. A react component is not just a function, it's a function plus a magically injected context that is accessed through hooks which requires all kinds of guarantees that you have to be aware of otherwise it will have hard to debug consequences. Imo it's anything but elegant. I did projects in all major frameworks and am building a huge angular web app currently. In angular a component is represented as a class plus template (plus styles). A event listener is mostly calling a method on the class. A state can be as simple as a property on the class. It's very natural and there are way less caveats (although not zero).

TonyStr 4mo ago
Maybe you would prefer React's class-based syntax. It's still there if you want to use it
- b4ckup 4mo ago
  I actually do and my critique is directed at function components which seems to be the standard nowadays.
mpweiher 4mo ago
> I never get this take. A react component is not just a function, Exactly. I did a somewhat longer writeup a while back. https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio... The pull request is still open :-)
- SebastianKra 4mo ago
  Interesting that you still stand by that, even after Apple moved to the exact same model with Swift UI. Narrowmindedly worrying about syntactical differences is contributing nothing to the conversation. The point is relinquishing control of state to the framework (be it via props, hooks or @State), and drawing the UI as a pure representation of whatever the framework tells you. Hence ui = f(state). This gets you a metric ton of advantages, which is why every modern framework is doing it. Classes, by themselves, are inadequate as containers for state unless that state must only exist in memory and never be observed, synchronized or serialized. You can attempt to patch that with decorators, ORMs or whatever, but now you're doing the same thing as React is doing with functions.
  - mpweiher 4mo ago
    Interesting that you would think Apple introducing Swift UI would have any bearing on the correctness of that blog post. Why do you think it would? Did you misread my post as "ha ha, Apple does it differently and therefore react is wrong"? If so, you certainly misread it a lot, and you have the wrong person. I have tons of posts about Apple getting things wrong. Anyway, did you miss the following part? I also think that despite all the flaws, react.js and react.native are currently eating native development's lunch. Clearly I made the point in my post that this approach has a lot of mindspace, despite the obvious flaws, so not sure how you pointing out that this approach has a lot of mindspace invalidates my post. > Hence ui = f(state). Every UI is always some mapping of the state. Otherwise it isn't really a UI, is it? What would it be, in your opinion, if it didn't map the state? > pure representation What does "pure representation" mean to you? I covered in the post that it sure as hell isn't a pure function of the state. And cannot be. Did you miss the part where David Abramov conceded that point? To elaborate a bit, React components aren’t always “pure” in strict FP sense of the word. They’re also not always functions (although we’re adding a stateful function API as a preferred alternative to classes soon). Support for local state and side effects is absolutely a core feature of React components and not something we avoid for “purity”. > This [ui=f(state)] gets you a metric ton of advantages, Well, yes. Like being a working UI, for example, which is why MVC is also structured this way. But can you elaborate the specific advantages you believe the react approach gives us over, say, MVC? The post elaborates that it would be really nice if UI were a pure function of the state. But it just isn't. And trying to pretend that it is might seemingly buy you some of those advantages, but at a huge cost.
satvikpendem 4mo ago
React uses an algebraic effectful function model which is elegant once one understands it: https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/
- b4ckup 4mo ago
  So it makes sense because there's a fancy name for it? For a moment let's just imagine you are inventing a brand new UI framework. You obviously want to have components in it. So how do you represent a component in your new framework? A component needs state, logic and a way to render that state. Do you choose to represent the component as a class which naturally encapsulates state as properties and logic as methods or do you choose to represent components as functions which lack state so you bolt it on via an implicitly injected context that you access via abstractions?
  - satvikpendem 4mo ago
    Read into how OCaml 5 does it and you'll have your answer.

TonyStr 4mo ago

How long have you used Vue? I had a similar opinion on Vue a few years ago, coming from a background of React as well. But now I prefer it over React, and reach for it in both personal and professional projects. The ergonomics are a bit different; there are things that are easier to do in React, and things that are easier to do in Vue, but the fact that it uses signals is a huge plus for me.