Live data from Hacker News

Why we chose Vue.js over React

pixeljets.com

101–110 of 267 posts

Re: Why we chose Vue.js over React

#101
Can't comment on vue much other than I think it would be the one I would go with if I had to pick one of these js frameworks due to some of the nice projects I've seen in little code. But yii2 for admin panels seems like another great selection for generating quick ugly forms only 5 people might see a month.

Re: Why we chose Vue.js over React

#102
post #34
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…

The reason for its success is good documentation and simplicity. Anything like this aims to empower users, and get the fuck out of the way and let them do their work has a space no matter how crowded the market. Angular and React want you to do things their way and therefore get in the way, and then make you do a bunch of work to make things work their way. I have a PHP app that I rigged up using Vue.js. Took two day…

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.

Re: Why we chose Vue.js over React

#103
If you prefer html templates you're going to choose a framework like Vue, Angular or Svelte. If you prefer Javascript driving the show you'll be more comfortable with something like React. The two approaches are duals of each other.

Personally I prefer an all JS solution because it's better suited to handle conditions and loops as compared to using custom SGML markup with framework-specific tags and attributes. In my opinion SGML/XML should only be used for markup, not program logic.

There are a few things I think React got wrong though - handling of children being one. Having different code paths to handle a single child versus multiple children was a design mistake. The Children convenience module is awkward to use. The state life cycle and immutability in React takes a while to get used to. It does seem more complicated than it needs to be and has spawned a plethora of React state management add ons.

Re: Why we chose Vue.js over React

#104
post #90

Earlier quoted context omitted.

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

Regarding component - here is the guy that suggested this and then admitted that this is a bad approach in a long run: http://stackoverflow.com/a/26152067/1132016

Using combines the worst aspects of custom SGML template markup languages and the complexity of React but with additional runtime overhead.

Re: Why we chose Vue.js over React

#105
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" [hidden]="x" (click)="myfunc()". Can't imagine it being more intuitive than this.

Re: Why we chose Vue.js over React

#107
post #102
post #34

Earlier quoted context omitted.

The reason for its success is good documentation and simplicity. Anything like this aims to empower users, and get the fuck out of the way and let them do their work has a space no matter how crowded the market. Angular and React want you to do things their way and therefore get in the way, and then make you do a bunch of work to make things work their way. I have a PHP app that I rigged up using Vue.js. Took two day…

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 past 5 years.

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.

To even get started in React, you need a babel, npm, gulp or webpack, node and a data-store of your choice. On top of this, any of the tutorials you can find from a full-stack perspective get made obsolete within months. This is javascript fatigue, all you have to do is look at this recent article.

https://www.fullstackreact.com/articles/react-tutorial-cloni...

It makes me wonder how many 'npm install' developers actually understand what is happening under the hood. This is not worse than the DOM ignorance that jQuery causes IMHO.

Re: Why we chose Vue.js over React

#108

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.

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.

That was my impression too.

Re: Why we chose Vue.js over React

#109
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…

I think that, similar to how everyone realized that jQuery wasn't the right tool for certain problems, people are coming to the conclusion that Angular and React+[Flux/Redux/MobX/etc.] isn't always the right tool for certain problems as well. And I think that Vue.js fills the needs for those problems very well.

The truth is, the majority of the work I've done in React for my job on the web would have been much better off written in Vue. React gives plenty of rope to hang yourself with if code quality isn't kept, especially when working with developers who've done nothing but jQuery for the past 10 years.

Vue.js (which, TBH, I haven't used yet - I'm still on the React hype train) looks great when you're working on a project that is complex enough to warrant looking for something more than jQuery, but not big enough to warrant the abstractions presented by React.

I've also found that the paradigm shift from jQuery apps to React is difficult for a lot of people at first, and Vue.js looks like a nice middle ground of "still looks like plain javascript-in-the-browser" while also nurturing some of the same ideas: components, event-driven model, one way data flow.

It also requires no transpilation and has a small footprint.

All of these are IMO a great plus when working in a team environment on sites that require lots of interactivity but don't quite fit into the "SPA" bucket.

Re: Why we chose Vue.js over React

#110

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…

Can you tell me what clojure libraries/frameworks work the way you describe? I'm learning clojure and would like to build some toy web apps because I've never done webdev before.

Sounds like they're referring to hiccup.
Post reply on HN