Why we chose Vue.js over React • Hacker News Board

Re: Why we chose Vue.js over React

#61

Post by k__ » Sun, Dec 11, 2016, 5:25 PM UTC

Bahamut wrote: post #44

k__ wrote: post #15

Earlier quoted context omitted.

Yes, I think the main selling point of React is it's tiny and intuitive API. I don't know how these frameworks compare in bigger sized applications, but if you just do a POC in Angular2, React and Vue.js, then React beats all of them. This probably leads to many people considering React for their new applications. If you go for bigger stuff, I don't know which would be better. I like React, but I also found it a bit…

Do you have numbers? Angular 2 is quite small if you're using treeshaking.

I mean API size and concepts, not size on disk.

React is quite big, I think about 50kb.

Re: Why we chose Vue.js over React

#62

Post by iLoch » Sun, Dec 11, 2016, 5:25 PM UTC

jolux wrote: post #49

heysunshine123 wrote: post #46

Earlier quoted context omitted.

Well, there's a difference between going out of fashion and being revealed as something that shouldn't be used (like Angular and Ember). Maybe Vue is just becoming the new shiny.

So React showed that Angular and Ember shouldn't be used, but Vue is just shinier than React right now?

No one gets fired for using React. Vue isn't even shinier in my opinion. It makes the same templating mistakes that Angular and Backbone did.

Re: Why we chose Vue.js over React

#63

Post by jaequery » Sun, Dec 11, 2016, 5:28 PM UTC

welanes wrote: post #11

One of the most impressive thing about Vue.js was the ability of the framework to enter a field saturated with dozens of options, that was becoming dominated by a well-resourced oligopoly (Angular, React), and still win over developers jaded from Javascript-fatigue. The give-a-shit factor from Evan (the creator) is extremely high and was key to its success. Inspiration for anyone building a product in an established…

Basically React seemed immature, as if it wasn't thought out fully but just hacked together.

Vuejs seems like what React could've been if it was thought out a Bit more. It just feels a lot more polished.

Honestly I think Vue is so far ahead of the curve it isn't a surprise to see more people switch away from React.

Re: Why we chose Vue.js over React

#64

Post by exception_e » Sun, Dec 11, 2016, 5:31 PM UTC

caub wrote: post #39

I wonder why people need Redux, Using simply React is great and enough if you understand it well

React is just the UI piece of the puzzle. Here's a nice description of when to use Redux:

"[Redux is justified when] you have a piece of data that needs to be used in multiple places in your app, and passing it via props makes your components break the single-responsibility principle (i.e. makes their interface make less sense)" (https://github.com/petehunt/react-howto/issues/12#issuecomme...)

This comment was written for Flux, but it is completely applicable for Redux.

When building something non-trivial, there are other pieces you'll want to pull in with React such as routing, messaging, etc.

Re: Why we chose Vue.js over React

#65

Post by guntars » Sun, Dec 11, 2016, 5:32 PM UTC

The arguments against JSX and React requiring many small components are very surface level and sound like "we couldn't figure out how to make it work for us so it must be impossible".

1. This was mentioned already, but, yes, you can use ternaries and boolean logic for simple conditionals (loggedIn && Logout || Login)

2. When you need more markup, put them in an if-else statement in the same render function.

  render()
    if (loggedIn) {
      var login = Logout
    else
      var login = 
    

    return 
      { login }

3. With SFC it's trivial to split these out into new components. You can even use bound methods to reuse the component state and props.

  class Navbar {
    LoginForm = () => {
      if (this.state.loggedIn) { ... } else { ... }
    }

    render() {
      const {LoginForm} = this
      return 
        
      
    }
  }

4. And finally, what stops you from creating a custom component that works like this?

  render() {
    return 
      Hello { this.state.userName }
      Please log in
    
  }

There's a continuum of ways you can structure your code, it just takes some experimentation to find what works for you.

After working with Angular templates for a long time and then switching to JSX, I'm never going back to having my markup in a string blob with magical attributes that make it do stuff.

Re: Why we chose Vue.js over React

#66

Post by doingmyting » Sun, Dec 11, 2016, 5:33 PM UTC

sergiotapia wrote: post #7

My man, a lot of the pain described in this article can be solved by Mobx: https://stackshare.io/mobx One of our engineers at StackShare[0] suggested it and it's fantastic. Mobx is very simple to understand and will make writing a "React" page a real joy again. Redux was way too complicated for what it gave, and just shot term after term after term at me that left me with a headache. I still don't understand Redux pr…

Any technology that toots its own horn by calling itself "simple", I don't use. This is a rule I made especially for the JS world.

Re: Why we chose Vue.js over React

#67

Post by snurycombinator » Sun, Dec 11, 2016, 5:37 PM UTC

tyingq wrote: post #19

fabian2k wrote: post #16

Earlier quoted context omitted.

Drupal is a bit overkill for a blog-like site, my impression is that it is usually used for more complex sites than e.g. Wordpress. With the latest version Drupal 8 there also was a push to make headless Drupal easier, which is pretty much just the Drupal data exposed as an API so that you can create SPAs for it.

More complex, sure. But it's still very centered around taxonomy with dates/sections, end user editing of nodes with WYSIWYG, page centric tags, etc. Very blog like. Seems like a big hammer for use as a datastore for an SPA.

That was true back in Drupal 6 in 2008.

Drupal 7 and 8 use entities, which are arbitrary combinations of fields that can be composed through the UI and accessed through APIs via JS or other methods.

One thing we use it for is its user management which is good enough out of the box.

Re: Why we chose Vue.js over React

#68

Post by eiriklv » Sun, Dec 11, 2016, 5:46 PM UTC

inglor wrote: post #27

Kiro wrote: post #21

Earlier quoted context omitted.

> Simple, scalable state management https://github.com/mobxjs/mobx It says "simple" but looks complicated. Any pointers? Is it because I don't know how decorators work it looks complicated?

MobX is _incredibly_ simple. If you have a property you need observed - add a `@observable`. If you have a react component you want to update automatically, add `@observer`. Derive as much as you can using `@computed`. You can but shouldn't use `autorun` which monitors side effects. If you're already used to Vue it's very similar except it works with React. That's pretty much it - just clone a boilerplate - the API s…

I get the feeling that the terms "easy" and "simple" are being mixed up here. MobX is a lot more complex than Redux (core), as it tries to do a lot more things that are braided together as a package. In Redux you choose to bring in that complexity (reselect, redux-saga, etc) if necessary. "Easy" is subjective, "simple" is not.

Re: Why we chose Vue.js over React

#69

Post by jonaf » Sun, Dec 11, 2016, 5:46 PM UTC

welanes wrote: post #11

One of the most impressive thing about Vue.js was the ability of the framework to enter a field saturated with dozens of options, that was becoming dominated by a well-resourced oligopoly (Angular, React), and still win over developers jaded from Javascript-fatigue. The give-a-shit factor from Evan (the creator) is extremely high and was key to its success. Inspiration for anyone building a product in an established…

Is there a Vue Native project of some sort? Currently planning on using React for a new project strictly because I can use the same components for a native app on multiple platforms.

Re: Why we chose Vue.js over React

#70

Post by faitswulff » Sun, Dec 11, 2016, 5:48 PM UTC

caleblloyd wrote: post #53

> Fun fact: Yii was created by a Chinese speaking guy - Qiang Xue. So, you might call Yii+Vue stack not just very difficult to pronounce, but also a Chinese stack :) Fun fact: Qiang Xue got his PhD at Duke University and developed Yii2 while living in the D.C. Area by leading a multi-national team of core contributors, the top 3 being from Germany, Russia, and Ukraine. He also moved on from the project mid-2015 and t…

I think it's disingenuous to claim so stridently that it isn't a Chinese stack (not to mention the implicit assumption that Chinese code is not composed of high quality contributions). They're not saying that it was solely Chinese contributors who made it, just that the originators of Yii and Vue are Chinese. Yii and Vue can be considered "Chinese" in the same sense that American founders that come out of HAX Accelerator[0] in Shenzhen and operate primarily in China could still be considered to have created "American" products and companies.

[0]: https://hax.co/