Live data from Hacker News

Why we chose Vue.js over React

pixeljets.com

71–80 of 267 posts

Re: Why we chose Vue.js over React

#71
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?

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.

Ember should be used more often. It saves a ton of time with large apps and has really neat plugins like FastBoot. It's underrated.

Re: Why we chose Vue.js over React

#72
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?

I think React will be around for a long time. Vue.js may also be an indication that React was on to something, fundamentally. So I wouldn't think of it as heartbreaking that Vue.js is making an impression using some of the same design patterns as React. Javascript framework design may just be converging on an overall theme, with competitive variations. Last I heard, Vue was even working on JSX support.

Re: Why we chose Vue.js over React

#73
post #69
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.

Check out Weex

Re: Why we chose Vue.js over React

#75
I am still unsure if there is a legit use case for Vue or React over plain HTML+CSS+JS.

I can understand the use case for React native. To build native applications on multiple platforms.

But what is the use case for React, Angular, Vue etc? Can somebody give a minimal example?

Re: Why we chose Vue.js over React

#76
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?

[deleted]

Re: Why we chose Vue.js over React

#77
While this is a good overview of why _they_ chose Vue over React, I wouldn't risk deriving that you should do the same too.

To balance the scale a bit, this is what they gave up, in favor of "shit that just works" (because this is the tone I'm getting from the article):

1. They decided they want off the enormous driving force for developer experience that is Facebook, and more importantly the Facebook codebase that shapes decisions in React, see [1] and [2].

2. They opted out of major innovation that directly stem from (1), see [3].

3. Parting with Redux, they also decided to part with a community that thinks functionally. This is a big deal not because of writing "pure functional code", but because these group of people can reason about the implications of bad citizenship on the browser - which really, is something the Javascript community really needs.

4. Moving away from functional-esque (for lack of a better term), they also move away from predictable testing. Forget purity and sideeffects. A good litmus test - think about how easy it is to test any given framework at scale, and if a framework is "built with testing in mind" (read: angular) how many hacks would be involved. When you have good foundations for testing, you can do this [6] and be sure everything can be covered [7] .

The only thing I see as a down side with React is the bundle size. The physical size. However I'm not worried one bit because of (1) and (2).

For Redux, I take the liberty to use MobX for small-medium projects (which probably is the overwhelming majority of projects), and Redux for large projects, or projects that I want great testing story in (in many ways these correlate, but some times they don't).

Redux is "boilerplatey" because it is highly granular. This is why the ecosystem around it exploded. But because of (3) the ecosystem around it has a sharp focus around the patterns and practices it applies, which makes choosing the "wrong" library not such a big deal; in a sense its ecosystem is predictable, because it is simple.

JSX or templates, I don't think this deserve a major part of the discussion. Both ideas exists for a long while, and even their predecessors exist for more than a few decades [4] and [5]. I don't think anyone is tilting the scales any where in a major way. I personally am convinced JSX is a new thing because you have first-class IDE support across the board (which you don't have for a given data-properties backed templating language unless it becomes ginormous like Angular). JSX is also simple to hack and you can opt-out or implement your own dumb-templating solution-to-JSX.

Having said that, I see Vue coupled with PHP quite a bit, like, it's an informal standard stack, so it may make sense if you're coming from PHP (but then again so did Facebook, right?). Maybe someone can explain that (is it the Laravel backing?).

[1] https://facebook.github.io/react/contributing/design-princip...

[2] https://facebook.github.io/react/contributing/implementation...

[3] http://isfiberreadyyet.com/

[4] http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...

[5] https://en.wikipedia.org/wiki/XSLT

[6] https://facebook.github.io/jest/

[7] https://medium.com/@jondot/how-to-snapshot-test-everything-i...

Re: Why we chose Vue.js over React

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

4. This won't work if one of the branches errors, because they are both evaluated. You can, however, pass a callback. But a simple ternary operator does look better.

Re: Why we chose Vue.js over React

#79
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 making some simple , etc custom components.... I've wondered why they don't exist in react by default, or arent the common pattern.

They are very readable... maybe people just dont like the "logic" in a tag... i guess... whatever, made for some really readable code...

Re: Why we chose Vue.js over React

#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've encountered in Clojure is to represent the entire page as a data structure. Conditionals and transformations are applied directly to this data structure, which is then sent as-is into the rendering pipeline (which commonly seems to be React). The HTML is never really written by hand, it's just a final "coat of paint" on top of the data.

To me, this seems far easier to wrap my head around than splicing two languages together in the same file and potentially finding that the interaction between the two is not as harmonious as one may wish.

Rendering to HTML, rather than rendering within HTML (so to speak), seems like it would remove the entire decision point where you have to pick between one library or the other based on the quirks of how it looks when it's spliced into HTML.

Post reply on HN