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

121–130 of 267 posts

Re: Why we chose Vue.js over React

#121

Post by cocktailpeanuts »

jolux wrote: post #111
inglor wrote: post #86

Earlier quoted context omitted.

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.

Except it is. I have worked on a couple of react/redux production projects and they all work well, but I still think redux is way too convoluted for most use cases. Too many abstract concepts.

Also their naming of the features could have been better. For example "reducer" makes sense ONLY after you understand what's going on. It should be the other way around--the naming should be intuitive enough to actually help me understand the concept easier.

A lot of physics theories are distilled down to a single equation, but that doesn't mean it's simple concept to understand. I personally think a library with 10000 lines of code that operate using setters and getters is much more simple to understand than a library with 100 lines of code that has all these esoteric concepts.

Re: Why we chose Vue.js over React

#122

Post by aikah »

fnordsensei wrote: post #80

I'm a designer and not a coder, so I feel obliged to provide my comments with salt added up front. That being said, JSX vs. wrapping HTML in if-statements seems like the same kind of trouble to me. I've done a few simple prototypes in Clojure/Script, so my reasoning is heavily influenced by the fact that I know very little about other languages, and only have moderate amount of knowledge about Clojure. The solution I…

> I've done a few simple prototypes in Clojure/Script

> I'm a designer and not a coder, so I feel obliged to provide my comments with salt added up front.

If you are good enough to be able to pick clojure/script which requires a JVM and a specific approach to programming, then you are a programmer.

Re: Why we chose Vue.js over React

#123

Post by vectorpush »

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?

Who cares? Fashion is not an engineering criteria, you shouldn't be factoring fashion into the question of whether or not a given tool is the right one for the job.

> A lot of the talk about it was "React is here to stay"

Unless Facebook has announced that they are abandoning React, this statement is as true as it ever was at any point in time.

Re: Why we chose Vue.js over React

#124

Post by irrational »

aikah wrote: post #117
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…

Is that true? I mentioned somewhere else that being able to use vue.js without a compile step was a breath of fresh air, but I was informed that you can also use React as a drop in library without any kind of compile/transpile/task runner. I assumed the person knew what they were talking about, but I never to research it. So now I wonder what is true. Can react be used as a drop in library like vue.js?

Re: Why we chose Vue.js over React

#125

Post by irrational »

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.

Wait, do people use React for non-SPA websites?

Re: Why we chose Vue.js over React

#126

Post by fnordsensei »

aikah wrote: post #122
fnordsensei wrote: post #80

I'm a designer and not a coder, so I feel obliged to provide my comments with salt added up front. That being said, JSX vs. wrapping HTML in if-statements seems like the same kind of trouble to me. I've done a few simple prototypes in Clojure/Script, so my reasoning is heavily influenced by the fact that I know very little about other languages, and only have moderate amount of knowledge about Clojure. The solution I…

> I've done a few simple prototypes in Clojure/Script > I'm a designer and not a coder, so I feel obliged to provide my comments with salt added up front. If you are good enough to be able to pick clojure/script which requires a JVM and a specific approach to programming, then you are a programmer.

Fair enough, thank you for the kind words.

I feel that a certain amount of humility is due when commenting on a field of study that's not my own. I know that there are many—particularly here, most likely—who have thought far longer and harder about these problems than I have.

Edit: by the way, the reason I picked up Clojure is because I (for some reason) watched Rich Hickey's talk Simple Made Easy and thought to myself, "hey, that person is thinking of programming in the same way that I think about design." I felt that the design principles he described that guided the development of Clojure were very similar to a lot of things I've come to consider when designing for human interaction. So I thought that by learning Clojure I might become a better designer, even though I don't write code professionally.

Re: Why we chose Vue.js over React

#127

Post by dismantlethesun »

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

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

I wondered what the issue was myself, so I actually implemented that pattern in a codepen, then looked at the compiled form of the JSX to Javascript.

The essential issue is that the value of a prop is always evaluated at runtime, regardless of if the prop is actually used. In the case of props.children this means that and are both evaluated, and thus rendered, and only one of them is actually used.

Thus you can't have conditionally rendering children, unless you've written them to be okay with failing at a render, with a blanket state---which is what most people are trying to avoid writing into their components, and simply want to conditionally render in a higher level component.

Re: Why we chose Vue.js over React

#128

Post by dismantlethesun »

SonicSoul wrote: post #113
lpa22 wrote: post #112

Earlier quoted context omitted.

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.

I think what he means is that control statements don't exist in JSX. You have to write Javascript to do if-statements, looping, etc.

In React, there is no 'direction' of binding---its all one way, just like in vanilla Javascript, and in fact no binding on anything except low level elements' like divs. Components only receive props, which do not do anything at all until you write code that reads them and runs operations based on their values.

Thus components are simply function calls (it's what they compile to anyways), and JSX is just a syntax to write functional code.

Re: Why we chose Vue.js over React

#129

Post by amenod »

mcudich wrote: post #84
jonaf wrote: post #69

Earlier quoted context omitted.

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.

Check out https://github.com/mcudich/TemplateKit

Not Vue based though, if I understand correcty?

Re: Why we chose Vue.js over React

#130

Post by amenod »

jeffjose wrote: post #73
jonaf wrote: post #69

Earlier quoted context omitted.

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.

Check out Weex

Also not Vue based, right?

Link for lazy & curious: https://alibaba.github.io/weex/

Post reply on HN