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

221–230 of 267 posts

Re: Why we chose Vue.js over React

#221

Post by tnjm »

irrational wrote: post #125
danabramov wrote: post #92

Earlier quoted context omitted.

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?

I use React all the time for individual components on server-rendered pages. It feels like a natural extension to formerly monolithic Rails/Node/etc apps.

That said, when an SPA is called for I'd far rather use Ember and get routing, state and a hundred other things for free, without needing to bolt together an entire front-end framework from parts each time.

Re: Why we chose Vue.js over React

#223

Post by vectorpush »

lilactown wrote: post #164
vectorpush wrote: post #123

Earlier quoted context omitted.

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.

I think fashion does come into the equation if only because it will be easier to find people who can grok the code base faster since they understand the framework and common idioms associated with it. Where I work, we just had a bunch of new hires and they're being productive within the first couple weeks because they know React, and our app uses React Native. React-knowledgeable devs are in high demand right now, wh…

I disagree. The cost of onboarding a new developer is negligible compared to the cost of picking the wrong stack for a project just because it might be the hippest tool at the time. An experienced programmer can pick up a new framework in a week or two tops and their ability to pick up the application code will have more to do with the quality and documentation of said code than anything else, but if you pick the wrong framework you'll be paying for it for the life of the project (or until you refactor with a new framework and write a blog post about why you decided to switch).

If the tools you're using cause your code to be inherently difficult to grok, then that is an engineering problem, but that has nothing to do with how fashionable the tool might be.

Re: Why we chose Vue.js over React

#224

Post by mastazi »

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 sound like "we couldn't figure out how to make it work for us so it must be impossible".

It sounded more just like "we couldn't figure out how to make it work for us", which is a perfectly plausible position.

The author just stated that React didn't work for them, not that it's "impossible to use React" as you are implying.

From the article:

> I guess this level of strictness and purity is something that may be useful when you have 1000 devs in your company [...] But most of companies have far smaller dev teams and other goals than Facebook.

Re: Why we chose Vue.js over React

#225

Post by abritinthebay »

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" […

To be fair - the reason Angular 2 moved away from that is largely due to the influence of React

That's not a bad thing of course.

Re: Why we chose Vue.js over React

#226

Post by Roboprog »

adamnemecek wrote: post #4

It's been a while since I've needed a front end framework but if react doesn't scratch your itch, you should check out cycle.js. https://cycle.js.org

I stumbled across Cycle.js a few weeks ago. I like the idea, but the examples still seemed a little clumsy.

I would like something similar, but a little more opinionated, with some shortcuts for booting up a simple project that sprinkles some "magic markup" in an existing page to drive a backend event handler / mapper-reducer function.

Re: Why we chose Vue.js over React

#227

Post by nobleach »

akhilcacharya wrote: post #205
ggregoire wrote: post #88

Earlier quoted context omitted.

Thank you for fixing the misleading information from this article. I would add: 1."now you have to create 10 functions to get input from 10 inputs". Or you can learn JavaScript: handleChange(event) { this.setState({ [event.target.name]: event.target.value }) } 2. "Redux sounds like a synonym of verbosity, as well." Nobody forces you to use Redux. https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

> [event.target.name]: event.target.value Dumb question but I've never seen this syntax before. What does it do or what is it called? (The brackets)

It's not a dumb question at all. It's relatively new, and I would implore the originator of that comment to take a different tone. It requires a newer browser or some sort of transpilation step. (You're probably already using one if you're using React)

Most of the React community has forged forward with ES6/ES2015, so learning that is definitely a part of the process.

Re: Why we chose Vue.js over React

#228

Post by nobleach »

SonicSoul wrote: post #139
dismantlethesun wrote: post #128

Earlier quoted context omitted.

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 operatio…

i don't see how sprinkling if-statements in your html is cleaner than "magical attributes" but thats just me :)

It's not just you...this has been a pretty big toss-up with MVC style frameworks and view libs. Does business logic belong in the template? Or does it belong in some sort of view controller? Mustache.js insists that all decisions should be made before data is sent to the template. Most other libs allow the template to make decisions. I don't think there's a definitive answer. I kinda lean on making easy decisions in Handlebars templates... or, since our new app is in React, JSX.

Re: Why we chose Vue.js over React

#229

Post by eyko »

dismantlethesun wrote: post #127
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 ev…

since then and else are going to be used inside an if component, you can use context to read condition, then not render at all if you don't need to (return null).

Re: Why we chose Vue.js over React

#230

Post by johntran »

"I expect Vue to become a primary JS framework in 16-24 months if Evan You makes right steps, at least around backenders and smaller teams of frontenders."

When Vue.js gets a big enough community passionate enough to host their own conference, we'll be able to consider this as a possibility. :)

Post reply on HN