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

Why we chose Vue.js over React

pixeljets.com

Post reply on HN
Print view View original

111–120 of 267 posts

Re: Why we chose Vue.js over React

#111

Post by jolux »

inglor wrote: post #86
eiriklv wrote: post #68

Earlier quoted context omitted.

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.

Save me the Rich Hickey talk. MobX is dead simple, it's a short write and here's how it works: - observables: add a getter/setter pair in place of the property - when it gets modified emit an event. - observer: when an observable getter gets called inside the `render` in React - listen to future updates and re-render. - computed: do the same thing as observer - but emit the value instead of rendering. All MobX does i…

Redux core is like less than 60 LoC. It can't possibly be more complex.

Re: Why we chose Vue.js over React

#112

Post by lpa22 »

SonicSoul wrote: post #105
guntars wrote: post #65

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()…

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. why would you do this in Angular? i thought the whole point was to use html templates in separate .html files. as for "magical" attributes, angular2 moved away from that and is using mostly native html attributes. i.e. [disabled]="x" […

JSX actually makes it more intuitive than that by having 0 reason for even needing to know when to use square brackets vs parenthses. It's simply curly braces and vanilla JS

Re: Why we chose Vue.js over React

#113

Post by SonicSoul »

lpa22 wrote: post #112
SonicSoul wrote: post #105

Earlier quoted context omitted.

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. why would you do this in Angular? i thought the whole point was to use html templates in separate .html files. as for "magical" attributes, angular2 moved away from that and is using mostly native html attributes. i.e. [disabled]="x" […

JSX actually makes it more intuitive than that by having 0 reason for even needing to know when to use square brackets vs parenthses. It's simply curly braces and vanilla JS

this is a different statement than the sentence i responded to. square or round just indicates the direction of the binding. everything in angular is also vanilla js.

Re: Why we chose Vue.js over React

#114

Post by _halgari »

jolux wrote: post #43

I hope I don't get downvoted for asking this but is React going out of fashion already? A lot of the talk about it was "React is here to stay" or "React is as permanent as JS itself" but now this is the second or third time people seem to be going for Vue instead. What happened?

React is about the only real framework in the ClojureScript community, via frameworks like Om.Next and Reframe. React in JS is rather clunky since you're dealing with a mutable language that prefers OOP primitives. In ClojureScript most UIs are data-driven and declarative and that's where the strengths of React really shine. So I would argue that ClojureScript turned React into a better React.

Re: Why we chose Vue.js over React

#115

Post by jolux »

_halgari wrote: post #114
jolux wrote: post #43

I hope I don't get downvoted for asking this but is React going out of fashion already? A lot of the talk about it was "React is here to stay" or "React is as permanent as JS itself" but now this is the second or third time people seem to be going for Vue instead. What happened?

React is about the only real framework in the ClojureScript community, via frameworks like Om.Next and Reframe. React in JS is rather clunky since you're dealing with a mutable language that prefers OOP primitives. In ClojureScript most UIs are data-driven and declarative and that's where the strengths of React really shine. So I would argue that ClojureScript turned React into a better React.

I've heard similar from some Clojure fans I know.

Re: Why we chose Vue.js over React

#116

Post by mambodog »

amelius wrote: post #100
mambodog wrote: post #97

Earlier quoted context omitted.

You seem to be mistaken. You don't need to create components if you just want to render some divs. You can just do const {render} = require('react-dom'); const {DOM} = require('react'); render( DOM.div({className="something"}, DOM.div({className="something-else"}, 'some text', ), ), document.getElementById('root'), ); Components become useful pretty quickly as your views grow in size, but even then, function componen…

Interesting, I didn't know, although I can recall searching through the documentation for answers. Does calling the "render" function multiple times perform the DOM-diffing and updating? And can I be sure that React will not perform updates behind the scenes at other moments than when calling "render"?

In answer to your first question, yes. See the documentation for `render`: https://facebook.github.io/react/docs/react-dom.html#render

In answer to your second question, yes, React currently only does anything as a consequence of calling `render`, or `.setState()`/`.forceUpdate()` in the case of a component class (not relevant if you're not using component classes).

In future, the (currently experimental) 'fiber' render will allow some rendering to be deferred until after the current call stack has finished (to avoid blocking the UI), but there should be away to tell React to do all rendering synchronously if you desire (which is necessary for eg. rendering on the server). There's no reason why the current behavior couldn't be supported on top of the new experimental renderer though.

Re: Why we chose Vue.js over React

#117

Post by aikah »

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…

> 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.

When it comes to simple solutions that do no require a build step, the field is not that crowded. A built step should be optional, not necessary to use a front-end library. With Angular you start with the CLI, with React you need to compile JSX files, ...

Angular 1 didn't succeed because it needed a build step or a third party language, it succeeded because it provided a smooth upgrade path from jQuery based apps. The Angular team forgot what made Angular popular with their "enterprise framework".

Re: Why we chose Vue.js over React

#118

Post by simonw »

danabramov wrote: post #92
jaequery wrote: post #63

Earlier quoted context omitted.

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.

I wouldn’t say React is “hacked together”. Perhaps you are referring to the React ecosystem? Facebook doesn’t build single-page apps with React, so naturally it doesn’t provide solutions for routing and similar concerns, so there is more churn as people are figuring this out together.

Could you expand more on "Facebook doesn't build single-page apps in React"? I hadn't heard that before.

Re: Why we chose Vue.js over React

#119

Post by [deleted] »

danabramov wrote: post #92
jaequery wrote: post #63

Earlier quoted context omitted.

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.

I wouldn’t say React is “hacked together”. Perhaps you are referring to the React ecosystem? Facebook doesn’t build single-page apps with React, so naturally it doesn’t provide solutions for routing and similar concerns, so there is more churn as people are figuring this out together.

[deleted]

Re: Why we chose Vue.js over React

#120

Post by joshmanders »

a-real-dinosaur wrote: post #107
kentor wrote: post #102

Earlier quoted context omitted.

What does "want you to do things their way" even mean? Aren't you doing things a certain way by virtue of using a framework? Maybe angular/react is just making you do things in a way that you prefer not to, while vue.js is making you do things in a way that you find reasonable. For other people, it's the reverse.

If you have to do things in a specific way, then you are forced to learn that at the same time as you are learning the technology. Learning just vue on the other hand, is much easier when you can retrofit your existing knowledge into it. Then worry about the 'proper way' later when you have made your first few apps. I already have boatloads of knowledge, and whilst it may not be '2016', it's been good enough for the…

> React on the other hand, whilst it gets described as 'just the view', but I haven't seen a single tutorial that uses anything other than React/Redux to drive it.

As a former Angular dev gone React, I've been able to accomplish 90% of what I could do in Angular, using React, React Router and Fetch API.

> To even get started in React, you need a babel, npm, gulp or webpack, node and a data-store of your choice.

Create React App allow you to forget about that stuff and just worry about your app. Same with Next by Zeit, and there are plenty of other things including a couple of CDN backed script tags you can throw on any html page and start using React right away to get started.

> On top of this, any of the tutorials you can find from a full-stack perspective get made obsolete within months.

That's because all these boilerplates or tutorials are pushing a style of developing React apps in which that specific person finds the best way.

> This is javascript fatigue, all you have to do is look at this recent article.

JavaScript fatigue is result of lacking knowledge of the basis of the JavaScript language and feeling you need to use the next greatest shiny framework and misunderstood boilerplate to "get up and running quickly" with said new shiny without a grasp of the tools used causing them to break and you not knowing how to fix it.

React uses JavaScript that everyone should know and be able to apply to anything else to do stuff.

You're not extending a special snowflake "class" system that requires you to do things drastically different from previous "class extending libs"

Because of this, tools like Inferno and Preact can prosper and allow users to literally swap out using React for Preact in production just by setting an alias in Webpack.

There's no special snowflake syndrome, JSX is just a syntax ontop of JavaScript to make it feel like we're writing HTML (with a couple caveats), but you don't need to use JSX. You can accomplish the same thing writing React.creatElement calls, as it's just props all the way down.

JSX is also compiled at build time, and not at runtime. You may think this is a problem, but lets be perfectly honest, most people already use tools like SASS/LESS and have a build step in their workflow already, adding another one isn't complicated.

Post reply on HN