20 ms·

I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real

I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extremely powerful and elegant (just read about gen_server in Erlang or the State monad). I am never a fan of two way data binding as an alternative. It's extremely hard to reason about, and it's not nearly as composable or simple as a tree of functional transformations. So I think that, if you compare Vue to React Component classes, Vue can be quite nice, but the reality is that idiomatic React should have you writing 80%+ small, simple, composable functions with no state, and you really can't get any syntactically barer then that. It's also the way I teach React. When you first see a function going from state to jsx, it really just makes so much sense, and you ask yourself why you'd ever bother with anything else.

certifiedloud 8y ago
Do you have any suggested resources for learning React in this way?
- ilovecaching 8y ago
  Honestly, there isn't much to learn. It's just a function that takes props and returns a React component (usually via JSX). The only big decision is the props API. https://reactjs.org/docs/components-and-props.html https://reactjs.org/docs/components-and-props.html The best thing to do is just to brush up on functional concepts, thinking about things in terms of composition and application, and threading state through your application and flowing back through to the top via dispatches. Learn more about flow (the concept, not the framework). I like to picture a waterfall, where the water is state that always keeps flowing no matter what it hits. State should start at the top from some source, we don't care what that is, and then flow through the application down into the leaves. Functions can do transforms and reductions on state, but they should never hold on to state the way class components do.
- lhnz 8y ago
  My recommendation is to read through this: https://github.com/reactjs/react-basic https://github.com/reactjs/react-basic
swoongoonz 8y ago
110% agree
jxub 8y ago
State management by process-directed messages is a really neat way to avoid throwing oneself under the OOP bus. Furthermore, Elixir has Agent, a higher abstraction on top of Erlang/OTP gen_server that's easier to grok and use in many simple cases with no need to separate the public interface and OTP callbacks.
buremba 8y ago
I wonder how you avoid writing stateful components in real-world complex SPAs.
- ilovecaching 8y ago
  It's quite easy, I honestly think the only roadblock is how one thinks about computation. If you think of your UI as a single computational expression you're building up from functional composition, then the issue of state never arises. It's just about defining the shape of the interfaces.
  - buremba 8y ago
    Sounds cool but I can't actually imagine the way you described. :) Any tutorials, articles?
    - xj9 8y ago
      try working through some tutorials on erlang/otp supervisor trees. the concepts are very similar.
- 33degrees 8y ago
  You manage your state outside your components, using Redux / Relay / MobX etc...
- williamdclt 8y ago
  Quite easily. The state is held in Redux or whatever, the only state held by components are UI stuff (is this section collapsed? Is this date picker open?). In the last SPA I wrote there's about 100 components, less than 5 of them are stateful.
- The_suffocated 8y ago
  Discussions of this sort are often confusing. When one talks about using Redux or some javascript library to do "state management", I always wonder whether one is talking about application states (i.e. states originating from business logic but unrelated to UI) or UI states.
stupidcar 8y ago
If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a complex web app, a component nested twenty levels deep may need to display pieces of information, like the user's date of birth and the current temperature on Mars, that none of its parent controls cares about. At that point, you can either bite the bullet and pass state through layer upon layer of props, completely eliminating any semblance of separation of concerns in your component layering, or inject state into your components via some other mechanism, like Redux/MobX/Context. At which point, JSX is basically just another fancy HTML templating library. "Idiomatic" React is a fun game to play when doing basic examples, using something like a todo manager, but as soon as you're in the real world, you hit its limitations very quickly.
- smackay 8y ago
  For me (Vue + Vuex) the choice was simple: you get undo for free. Having a shared store really does change the way you look at web apps - it's almost a completely different paradigm. If you can avoid re-loading the data for a view if you already have it then then opening a new view to edit a subset of the data instead of dealing with popup makes life so much easier - you get a lot more freedom with the UX and going back to the previous view with the parent data is almost zero-cost.
  - ilovecaching 8y ago
    You can have undo for free using React as well. React doesn't care about how you manage your state changes, and it will selectively render only the parts of your app that changed.
    - drb91 8y ago
      Not to mention, I believe time travel is an officially supported functionality for redux, if you choose to use that.
qudat 8y ago
It saddens me that JSX became so popular in the React community. I find the syntax verbose and hard to read ... similar to HTML. At my last company we used `react-hyperscript` which was a simple wrapper around `react.createElement`. Ultimately, the React developers made the mistake of making `createElement` so annoying to work with, I assume because they bought into JSX. Granted, JSX might have been necessary when React was first created in order to ease people into transitioning to HTML in JS, but I feel like we can move passed that now. I highly recommend `react-hyperscript`: https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript
- wetpaws 8y ago
  excuse me if i'm wrong, but isn't it just a snippet for react.createElement?
  - aylmao 8y ago
    react-hyperscript seems to also parse class names ('div.example'), ids ('h1#heading') and come with other goodies. Looks pretty interesting, and I appreciate they doing away with the need of a pre-processor ¯\_(ツ)_/¯
    - wetpaws 8y ago
      I looked through the code and it's about 40 lines long. I don't mind of people using small libraries like this, but it's a bit fun to see it presented as some kind of revelation :)
- interlocutor 8y ago
  If you care about compile-time checking (you would, if you work on medium to large applications) then JSX (or the TypeScript variant, TSX) is much better because it catches invalid or mistyped attribute names etc.
  - bodas 8y ago
    Only because it is more mature. No reason you can't write a linter for hyperscript.
kevin_thibedeau 8y ago
> I am never a fan of two way data binding as an alternative. The author is wrong. Vue doesn't have two-way binding. It has one-way binding with events. Components can't force anything upon their parent's state with an event.
- aylmao 8y ago
  I mean, Vue calls it two-way data binding. From their website: > "You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases." I'm not knowledgeable enough on the matter to say if this is or isn't, and to compare vs Angular, etc. But don't blame the author for this one ¯\_(ツ)_/¯ [1] https://vuejs.org/v2/guide/forms.html https://vuejs.org/v2/guide/forms.html
  - orangecat 8y ago
    As discussed in https://vuejs.org/v2/guide/components.html#Using-v-model-on-Components https://vuejs.org/v2/guide/components.html#Using-v-model-on-... <Component v-model="foo"> is basically shorthand for <Component :value="foo" @input="foo=$event"> In particular, the child can't affect the value of the parent's "foo" attribute except by sending an event. This is in contrast to Angular 1 where changing "foo" in the child would also change it in the parent, which would often lead to confusing data flow cycles.
  - kevin_thibedeau 8y ago
    "v-model" is syntax sugar emulating a two-way binding to simplify form creation. Under the hood it's a one-way bound prop, an event, and an implicit event handler. Ordinary events can't mutate state without an explicitly created handler. All props form a one-way-down binding between the child property and the parent one: when the parent property updates, it will flow down to the child, but not the other way around. This prevents child components from accidentally mutating the parent’s state, which can make your app’s data flow harder to understand. https://vuejs.org/v2/guide/components-props.html#One-Way-Data-Flow https://vuejs.org/v2/guide/components-props.html#One-Way-Dat... AngularJS uses two-way binding between scopes, while Vue enforces a one-way data flow between components. This makes the flow of data easier to reason about in non-trivial applications. https://vuejs.org/v2/guide/comparison.html#Data-binding https://vuejs.org/v2/guide/comparison.html#Data-binding
_bxg1 8y ago
I've been using React full-time for a year and a half now, and I've never felt like pure-functional components are a good fit for more than a handful of use-cases. If all you're doing is displaying data, then sure, they're really elegant, but most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled, which means pretending they aren't feels gross and weird (I'm looking at you, Redux).
- aylmao 8y ago
  > most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled I think this is what the Flux model is all about, making UI code actually be a pure function of state. By that, I mean literally a function, where state is the argument, and where all you render depends solely on said argument. If you want to change what is rendered, you send a message and a Store deals with the state modification. Once it's done, it calls your pure function again, this time with a different state, so you get a different render. This IMO, decouples state and and view instead of tightly coupling it. Redux is the best Flux implementation to demonstrate this IMO because it puts all state in a single Store. The messages to this Store can come from anywhere: UI, server, me typing on the console, etc. The state changes independently of the UI and in fact I could have a full application without having a UI whatsoever. Or I could have a UI without knowledge of my state's topography, because Redux lets me morph and cherrypick my state before I pass it to a component as props. I think that's a good exercise: to try and build an application thinking of it as a series of actions on state first --and then how that may play onto UI-- to get to appreciate functional components. I'm curious to know why you think why you think Redux only "pretends" they aren't though. (:
  - _bxg1 8y ago
    Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function). So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store). Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, and isn't just idyllic, agnostic "data". Things like "is this menu open or closed?" and "what's the current string value of this input (which isn't meaningful until the form is submitted)?" In Flux, those things tend to add a ton of boilerplate in terms of change actions, and split tightly-related concerns into separate corners of the codebase (if I remove this menu component I have to remove its open/closed state variable and the corresponding action). To be sure, there's not really a great way to decouple things in the reactive architecture. I personally lean towards stateful components that are decoupled at their boundaries instead, which does carry its own downsides. The only solution I've ever seen that truly felt right was two-way databinding, which Vue (sort of) still has, but which has fallen out of fashion in general because it requires "magic" and because it tends to come with performance costs.
sbjs 8y ago
Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language. React is just JavaScript and HTML.
- rawTruthHurts 8y ago
  I'm not sure attributes named as "ref" or "className" qualify either as Javascript or HTML
  - dmitriid 8y ago
    They qualify as JavaScript because className etc. are exactly how you work with HTML attributes from Javascript: https://developer.mozilla.org/en-US/docs/Web/API/Element/attributes https://developer.mozilla.org/en-US/docs/Web/API/Element/att...
  - deleted 8y ago
    [deleted]
- ipntu 8y ago
  The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX. It's not much, really. I personally find Vue templating syntax much easier to follow than JSX, but that's because I'm used to it. I honestly believe that's how React users feel about JSX too.
  - dmitriid 8y ago
    > The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX This is patently not so. Vue has: - three different html-like attributes - three different scripting languages in templates (two Javascript-like, one Javascript, but only expressions) - one scripting language for controller/model which actually breaks JS assumptions (about what `this` is, for example) by magiacally hoisting some (but not all) properties of an object https://pbs.twimg.com/media/DbVEoKOX0AEEen6.jpg:large https://pbs.twimg.com/media/DbVEoKOX0AEEen6.jpg:large
toolongdidntwri 8y ago
The only thing that bothered me was that there wasn't a way to tell Vue to disable reactivity with a clear pattern: see https://github.com/vuejs/vue/issues/1988 https://github.com/vuejs/vue/issues/1988 So e.g. if you want to have a Leaflet map i.e. `this.map = L.map(...);`, Vue will automatically add reactivity to this property. Sometimes I had big problems with this behavior (or it was simply annoying), so I wrote vue-static based on ideas of the core developers: https://github.com/samuelantonioli/vue-static https://github.com/samuelantonioli/vue-static Now I can have big objects in the Vue component which don't get automatically tracked using the reactivity system. - - - A problem for many beginners: Another problem with the reactivity system is that sometimes you have a route like `/employees/:id` and edit an object. But on abort, you want to rollback. One thing you always have to do is to copy the object you want to edit (I use lodash's `_. cloneDeep(obj)` for this). If you use Vuex, it's not such a big deal because it works using immutable state, but when you work with a plain javascript object this will definitely generate some headaches. - - - But otherwise, I think Vue is definitely the way to go. `v-model` can be seen as syntactic sugar while you have to add it to react inputs and textareas manually (using onchange and setState). You can write stateless Vue code just fine and use JSX. On the other hand, React misses some of the cool features like the Vue component files (.vue files) and its templating language. And the best is: The framework doesn't say that you have to use it. It's not so opinionated but still feature-complete with the official plugins.
xiphias 8y ago
Two-way data binding and composability don't have to be exclusive. I wrote a web framework that provides the two together, though it's right now in early state. Feel free to try it out / use it though if you're interested: http://reactiverelations.org/ http://reactiverelations.org/

certifiedloud 8y ago

Do you have any suggested resources for learning React in this way?

ilovecaching 8y ago
Honestly, there isn't much to learn. It's just a function that takes props and returns a React component (usually via JSX). The only big decision is the props API. https://reactjs.org/docs/components-and-props.html https://reactjs.org/docs/components-and-props.html The best thing to do is just to brush up on functional concepts, thinking about things in terms of composition and application, and threading state through your application and flowing back through to the top via dispatches. Learn more about flow (the concept, not the framework). I like to picture a waterfall, where the water is state that always keeps flowing no matter what it hits. State should start at the top from some source, we don't care what that is, and then flow through the application down into the leaves. Functions can do transforms and reductions on state, but they should never hold on to state the way class components do.
lhnz 8y ago
My recommendation is to read through this: https://github.com/reactjs/react-basic https://github.com/reactjs/react-basic

swoongoonz 8y ago

110% agree

jxub 8y ago

State management by process-directed messages is a really neat way to avoid throwing oneself under the OOP bus. Furthermore, Elixir has Agent, a higher abstraction on top of Erlang/OTP gen_server that's easier to grok and use in many simple cases with no need to separate the public interface and OTP callbacks.

buremba 8y ago

I wonder how you avoid writing stateful components in real-world complex SPAs.

ilovecaching 8y ago
It's quite easy, I honestly think the only roadblock is how one thinks about computation. If you think of your UI as a single computational expression you're building up from functional composition, then the issue of state never arises. It's just about defining the shape of the interfaces.
- buremba 8y ago
  Sounds cool but I can't actually imagine the way you described. :) Any tutorials, articles?
  - xj9 8y ago
    try working through some tutorials on erlang/otp supervisor trees. the concepts are very similar.
33degrees 8y ago
You manage your state outside your components, using Redux / Relay / MobX etc...
williamdclt 8y ago
Quite easily. The state is held in Redux or whatever, the only state held by components are UI stuff (is this section collapsed? Is this date picker open?). In the last SPA I wrote there's about 100 components, less than 5 of them are stateful.
The_suffocated 8y ago
Discussions of this sort are often confusing. When one talks about using Redux or some javascript library to do "state management", I always wonder whether one is talking about application states (i.e. states originating from business logic but unrelated to UI) or UI states.

stupidcar 8y ago

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a complex web app, a component nested twenty levels deep may need to display pieces of information, like the user's date of birth and the current temperature on Mars, that none of its parent controls cares about. At that point, you can either bite the bullet and pass state through layer upon layer of props, completely eliminating any semblance of separation of concerns in your component layering, or inject state into your components via some other mechanism, like Redux/MobX/Context. At which point, JSX is basically just another fancy HTML templating library. "Idiomatic" React is a fun game to play when doing basic examples, using something like a todo manager, but as soon as you're in the real world, you hit its limitations very quickly.

smackay 8y ago
For me (Vue + Vuex) the choice was simple: you get undo for free. Having a shared store really does change the way you look at web apps - it's almost a completely different paradigm. If you can avoid re-loading the data for a view if you already have it then then opening a new view to edit a subset of the data instead of dealing with popup makes life so much easier - you get a lot more freedom with the UX and going back to the previous view with the parent data is almost zero-cost.
- ilovecaching 8y ago
  You can have undo for free using React as well. React doesn't care about how you manage your state changes, and it will selectively render only the parts of your app that changed.
  - drb91 8y ago
    Not to mention, I believe time travel is an officially supported functionality for redux, if you choose to use that.

qudat 8y ago

It saddens me that JSX became so popular in the React community. I find the syntax verbose and hard to read ... similar to HTML. At my last company we used `react-hyperscript` which was a simple wrapper around `react.createElement`. Ultimately, the React developers made the mistake of making `createElement` so annoying to work with, I assume because they bought into JSX. Granted, JSX might have been necessary when React was first created in order to ease people into transitioning to HTML in JS, but I feel like we can move passed that now. I highly recommend `react-hyperscript`: https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript

wetpaws 8y ago
excuse me if i'm wrong, but isn't it just a snippet for react.createElement?
- aylmao 8y ago
  react-hyperscript seems to also parse class names ('div.example'), ids ('h1#heading') and come with other goodies. Looks pretty interesting, and I appreciate they doing away with the need of a pre-processor ¯\_(ツ)_/¯
  - wetpaws 8y ago
    I looked through the code and it's about 40 lines long. I don't mind of people using small libraries like this, but it's a bit fun to see it presented as some kind of revelation :)
interlocutor 8y ago
If you care about compile-time checking (you would, if you work on medium to large applications) then JSX (or the TypeScript variant, TSX) is much better because it catches invalid or mistyped attribute names etc.
- bodas 8y ago
  Only because it is more mature. No reason you can't write a linter for hyperscript.

kevin_thibedeau 8y ago

> I am never a fan of two way data binding as an alternative. The author is wrong. Vue doesn't have two-way binding. It has one-way binding with events. Components can't force anything upon their parent's state with an event.

aylmao 8y ago
I mean, Vue calls it two-way data binding. From their website: > "You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases." I'm not knowledgeable enough on the matter to say if this is or isn't, and to compare vs Angular, etc. But don't blame the author for this one ¯\_(ツ)_/¯ [1] https://vuejs.org/v2/guide/forms.html https://vuejs.org/v2/guide/forms.html
- orangecat 8y ago
  As discussed in https://vuejs.org/v2/guide/components.html#Using-v-model-on-Components https://vuejs.org/v2/guide/components.html#Using-v-model-on-... <Component v-model="foo"> is basically shorthand for <Component :value="foo" @input="foo=$event"> In particular, the child can't affect the value of the parent's "foo" attribute except by sending an event. This is in contrast to Angular 1 where changing "foo" in the child would also change it in the parent, which would often lead to confusing data flow cycles.
- kevin_thibedeau 8y ago
  "v-model" is syntax sugar emulating a two-way binding to simplify form creation. Under the hood it's a one-way bound prop, an event, and an implicit event handler. Ordinary events can't mutate state without an explicitly created handler. All props form a one-way-down binding between the child property and the parent one: when the parent property updates, it will flow down to the child, but not the other way around. This prevents child components from accidentally mutating the parent’s state, which can make your app’s data flow harder to understand. https://vuejs.org/v2/guide/components-props.html#One-Way-Data-Flow https://vuejs.org/v2/guide/components-props.html#One-Way-Dat... AngularJS uses two-way binding between scopes, while Vue enforces a one-way data flow between components. This makes the flow of data easier to reason about in non-trivial applications. https://vuejs.org/v2/guide/comparison.html#Data-binding https://vuejs.org/v2/guide/comparison.html#Data-binding

_bxg1 8y ago

I've been using React full-time for a year and a half now, and I've never felt like pure-functional components are a good fit for more than a handful of use-cases. If all you're doing is displaying data, then sure, they're really elegant, but most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled, which means pretending they aren't feels gross and weird (I'm looking at you, Redux).

aylmao 8y ago
> most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled I think this is what the Flux model is all about, making UI code actually be a pure function of state. By that, I mean literally a function, where state is the argument, and where all you render depends solely on said argument. If you want to change what is rendered, you send a message and a Store deals with the state modification. Once it's done, it calls your pure function again, this time with a different state, so you get a different render. This IMO, decouples state and and view instead of tightly coupling it. Redux is the best Flux implementation to demonstrate this IMO because it puts all state in a single Store. The messages to this Store can come from anywhere: UI, server, me typing on the console, etc. The state changes independently of the UI and in fact I could have a full application without having a UI whatsoever. Or I could have a UI without knowledge of my state's topography, because Redux lets me morph and cherrypick my state before I pass it to a component as props. I think that's a good exercise: to try and build an application thinking of it as a series of actions on state first --and then how that may play onto UI-- to get to appreciate functional components. I'm curious to know why you think why you think Redux only "pretends" they aren't though. (:
- _bxg1 8y ago
  Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function). So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store). Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, and isn't just idyllic, agnostic "data". Things like "is this menu open or closed?" and "what's the current string value of this input (which isn't meaningful until the form is submitted)?" In Flux, those things tend to add a ton of boilerplate in terms of change actions, and split tightly-related concerns into separate corners of the codebase (if I remove this menu component I have to remove its open/closed state variable and the corresponding action). To be sure, there's not really a great way to decouple things in the reactive architecture. I personally lean towards stateful components that are decoupled at their boundaries instead, which does carry its own downsides. The only solution I've ever seen that truly felt right was two-way databinding, which Vue (sort of) still has, but which has fallen out of fashion in general because it requires "magic" and because it tends to come with performance costs.

sbjs 8y ago

Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language. React is just JavaScript and HTML.

rawTruthHurts 8y ago
I'm not sure attributes named as "ref" or "className" qualify either as Javascript or HTML
- dmitriid 8y ago
  They qualify as JavaScript because className etc. are exactly how you work with HTML attributes from Javascript: https://developer.mozilla.org/en-US/docs/Web/API/Element/attributes https://developer.mozilla.org/en-US/docs/Web/API/Element/att...
- deleted 8y ago
  [deleted]
ipntu 8y ago
The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX. It's not much, really. I personally find Vue templating syntax much easier to follow than JSX, but that's because I'm used to it. I honestly believe that's how React users feel about JSX too.
- dmitriid 8y ago
  > The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX This is patently not so. Vue has: - three different html-like attributes - three different scripting languages in templates (two Javascript-like, one Javascript, but only expressions) - one scripting language for controller/model which actually breaks JS assumptions (about what `this` is, for example) by magiacally hoisting some (but not all) properties of an object https://pbs.twimg.com/media/DbVEoKOX0AEEen6.jpg:large https://pbs.twimg.com/media/DbVEoKOX0AEEen6.jpg:large

toolongdidntwri 8y ago

The only thing that bothered me was that there wasn't a way to tell Vue to disable reactivity with a clear pattern: see https://github.com/vuejs/vue/issues/1988 https://github.com/vuejs/vue/issues/1988 So e.g. if you want to have a Leaflet map i.e. `this.map = L.map(...);`, Vue will automatically add reactivity to this property. Sometimes I had big problems with this behavior (or it was simply annoying), so I wrote vue-static based on ideas of the core developers: https://github.com/samuelantonioli/vue-static https://github.com/samuelantonioli/vue-static Now I can have big objects in the Vue component which don't get automatically tracked using the reactivity system. - - - A problem for many beginners: Another problem with the reactivity system is that sometimes you have a route like `/employees/:id` and edit an object. But on abort, you want to rollback. One thing you always have to do is to copy the object you want to edit (I use lodash's `_. cloneDeep(obj)` for this). If you use Vuex, it's not such a big deal because it works using immutable state, but when you work with a plain javascript object this will definitely generate some headaches. - - - But otherwise, I think Vue is definitely the way to go. `v-model` can be seen as syntactic sugar while you have to add it to react inputs and textareas manually (using onchange and setState). You can write stateless Vue code just fine and use JSX. On the other hand, React misses some of the cool features like the Vue component files (.vue files) and its templating language. And the best is: The framework doesn't say that you have to use it. It's not so opinionated but still feature-complete with the official plugins.

xiphias 8y ago

Two-way data binding and composability don't have to be exclusive. I wrote a web framework that provides the two together, though it's right now in early state. Feel free to try it out / use it though if you're interested: http://reactiverelations.org/ http://reactiverelations.org/