Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue.js vs. React

vuejs.org

Post reply on HN
Print view View original

351–360 of 486 posts

Re: Vue.js vs. React

#351

Post by coding123 »

Actually my major complaint of React is the state of state. There seems to be no common knowledge about how to do this right. I just joined a team that has two React projects that development started about two months ago (I just joined like a week ago). There is a a large component that I am working on that is completely bound to Redux. There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it. On top of all that, the application is completely unable to handle 2 instances of any component they wrote. I am trying to re-write some of it to encapsulate the state in at the component level. It's pretty awful compared to the Angular (not AngularJS) app I recently rolled off of.

Edit : Also wanted to add, while I think a lot of people really don't like JSX, I actually do like it but I think someone could take that aspect and come up with a better state management system outside of redux and friends. I think something along the lines of Angular (not AngularJS) with JSX would be great.

Re: Vue.js vs. React

#352

Post by gcoda »

Rusky wrote: post #204
thomasDE wrote: post #196

Earlier quoted context omitted.

> It's like writing shitty PHP code without templates. For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript. From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so…

You can use JSX with Vue, and still get its other benefits. :)

Also you can do with just JavaScript. With render-function.

h('ul', [ h('li', 'one'), h('li', 'two') ])

And use native array methods instead of v-for v-if and filtering data with component methods

Re: Vue.js vs. React

#353

Post by bastawhiz »

yunyu wrote: post #66
bastawhiz wrote: post #63

Earlier quoted context omitted.

A very large number of people use React in the same way, linking to a cdn.

Could you explain your rationale? I highly doubt that a very large number of people are hand-writing render functions... I personally gave up on React and only picked it up several months later after finding out that using it with just a script embed was exceedingly painful.

A lot of people will have a bundle that they've transpiled, but use the global React object from pulling in React and ReactDOM from a CDN. Other folks will use a library that offers syntax like:

  elem.div(elem(Component, {prop: 'value'}), {className: 'foo'})
It's surprisingly common, and it's listed not too far down on the React installation page:

https://facebook.github.io/react/docs/installation.html

Re: Vue.js vs. React

#354

Post by PrunJuice »

jaequery wrote: post #260
sergiotapia wrote: post #239

Earlier quoted context omitted.

I find the JSX loop infinitely easier to understand what's going on. It's a javascript map. With your Vue example, what is listItem? An array? Can it be an object? Does listItem need a special decorator for v-for to be able to loop through it? So many initial questions that just aren't there if you just use Javascript.

it's just plain for(x in list){ .. } v-for="item in list" if you need idx: v-for="(item, i) in list" pretty standard stuffs

I thought the whole point was that you didn't have to write loops in Vue.js and yet here is a loop in Vue.js.

Re: Vue.js vs. React

#355

Post by zero_shift »

chrisco255 wrote: post #309
zero_shift wrote: post #219

Earlier quoted context omitted.

I've been in this gig for years upon years and I still don't see what's terrible about two way binding. Can someone actually justify it without handwaving statements like "you'll notice at scale", or red herrings like "Angular is slow"?

Side effects and testability. Two way binding is great for simple forms, if you have like a dozen or so variables on a page? Two way binding is awesome and allows you to write very terse code and logic. If you start adding dynamic forms, multiple developers, unit tests, and advanced interactive application logic, then you are left with a spaghetti code mess (with 2-way binding). The problems really creep up when you…

> If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element.

I've heard this argument before, and I really don't get it.

Let's say I have an input bound to a model variable. What does that mean? Well, the model is the single source of truth of state. And the user can change it. Sometimes we have derived state, like computeds in Knockout. These are read-only and are not ultimately sources of truth (though they will never contradict non-derived values).

In this model, I cannot see what is wrong. Why do you need to reason about the side effects your input triggered? Your input should be bound to something that is a fundamental, atomic, irreducible element of the app state. When it changes, the app changes. You never need to reason about this happening because there should never be a moment where a model changes and the app does not.

Excuse me for my naïveté, but it looks to me like two way binding can only cause problems if you are binding inputs to derived values, or if your model is not truly irreducible. In which case, you are knackered before you start: how is your app ever supposed to guarantee consistency of state?

If you are writing Angular or Knockout code properly, in my opinion, the data flow should be unidirectional just by dint of using an irreducible model and never manually overwriting a derived value.

Just because the template has a two way binding to a model does not mean the data flow is pandirectional. Likewise, one way binding does not guarantee unidrectionality: I am fairly sure you could write a React-Flux app where components emit arbitrary actions in response to state changes. Perhaps this is banned in Redux, though.

Re: Vue.js vs. React

#356

Post by kccqzy »

madmax108 wrote: post #209
yunyu wrote: post #57

Earlier quoted context omitted.

Something worth noting is that both Angular and Vue are far more script-embed-directly-into-page friendly (mostly due to templating) compared to React. Almost all React users get it from NPM, while I would expect that the proportion of Angular or Vue users who get them from NPM is lower. I've seen a lot of projects for those two run without any build system (and anecdotally, I'm pretty sure I'm not the only one who's…

Perfectly said. I've used Vue for a couple of months now (a couple personal projects, experiments and some dashboards) and used Angular for ~2 years before (admittedly, mostly Angular 1), and have literally never had to start off from 'npm install', unlike react (which I used for a year or so before), where everything needed a lot of boilerplate setup. Most devs I know start a react application by cloning some standa…

I've used react without npm at all. Just download the react and reactdom scripts from its official site, put two tags in your HTML and that's it.

Re: Vue.js vs. React

#357

Post by blumomo »

In this thread people are fighting about their _opinions_ why they use Vue.js or React. And why X is really better than Y.

In reality these programmers don't want to have the feeling they might have made the wrong choice when they used X instead of Y. The idea that they might have taken the poorer choice hurts so much that they need to defend their decision so heavily while in reality taking ReactJS or Vue.js is like ordering pizza or pasta. You usually don't want to have both at the same time. So you need to explain why pizza is better than pasta tonight. Only that you usually have to stick longer around with Vue.js or ReactJS once chosen. Enjoy your choice and solve real problems, but stop fighting about it, programmers. Pasta and pizza will always both win.

Re: Vue.js vs. React

#358

Post by beefsack »

djur wrote: post #330
luke3butler wrote: post #323

Earlier quoted context omitted.

But you can use JSX with Vue if that's what you prefer. Vue passes everything down to render functions in the end anyways. React forces JSX use, so a lot of times the battle between Vue vs React seems to be Vue Templates vs JSX which never makes sense to me.

React does not force JSX use. JSX just compiles down to React.createElement.

I feel React.createElement is so unergonomic it's not really an option to use directly. A lot of React supporters mention it when people criticise JSX, but I don't think it's a pragmatic alternative.

Re: Vue.js vs. React

#359

Post by vladimir-y »

gcoda wrote: post #352
Rusky wrote: post #204

Earlier quoted context omitted.

You can use JSX with Vue, and still get its other benefits. :)

Also you can do with just JavaScript. With render-function. h('ul', [ h('li', 'one'), h('li', 'two') ]) And use native array methods instead of v-for v-if and filtering data with component methods

> With render-function.

This is even worse as for me. Generally the JSX/React.createElement approach itself and the fact that many people like the idea make me cry. Do people like it just because it's given by FB?

Re: Vue.js vs. React

#360

Post by stephenhuey »

pier25 wrote: post #132

We moved away from React to Vue about 8 months ago and everyone on the team is a lot happier. First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates. It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc. Another problem with React is that it only really solves o…

Aurelia has a great router and many other things going for it as well.
Post reply on HN