Live data from Hacker News

Why we chose Vue.js over React

pixeljets.com

191–200 of 267 posts

Re: Why we chose Vue.js over React

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

This, a thousand times this. I strongly considered Vue for a recent project but needed a bit more and went with Aureli, and now that it's out of beta I hope they keep up their rapid improvements to the docs to win over people with simplicity in getting up and running with Aurelia.

Re: Why we chose Vue.js over React

#192

Earlier quoted context omitted.

I don't deny it. What surprised me was that Vue, a framework, was easier to learn than jQuery, a library. In my experience elsewhere it's usually the other way around. Like learning how to use Python's Requests vs. learning how to use Python's Flask.

Once again: apples and oranges

[deleted]

Re: Why we chose Vue.js over React

#193
This is a great article, thanks for sharing.

"Not being able to put plain old IF condition to some block of HTML code sucks"

In my usage of React, I found that this limitation forces me to use functions to break down my code, a skill which is simply required when working on large projects. Of course, that's what everyone else says, too.

"JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each."

Truth to this -- React can make things slower when your project is inherently monolithic, but you're tempted to abstract things into ugly Listwrappers, ListViews, ListViewData, ListViewDataContainers, etc. It gets ugly if you aren't good at abstracting things very well.

React should approached with caution. I think this guy has the right idea, don't put all your eggs into the React basket. Don't underestimate the cunning of Mark Zuckerberg. If possible, don't rely on React, because if you create something groundbreaking, you will be in for a legal situation with Facebook.

Re: Why we chose Vue.js over React

#194
post #130

Earlier quoted context omitted.

Check out Weex

Also not Vue based, right? Link for lazy & curious: https://alibaba.github.io/weex/

The Vue-based version is already in good progress and we plan to ship a beta early 2017: https://github.com/weexteam/weex-vue-framework/issues/9

Re: Why we chose Vue.js over React

#195

My man, a lot of the pain described in this article can be solved by Mobx: https://stackshare.io/mobx One of our engineers at StackShare[0] suggested it and it's fantastic. Mobx is very simple to understand and will make writing a "React" page a real joy again. Redux was way too complicated for what it gave, and just shot term after term after term at me that left me with a headache. I still don't understand Redux pr…

Why not use Pouchdb then? Pouchdb even can synchronize itself with server DB.

Re: Why we chose Vue.js over React

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

Wrapping them in methods is an easy way to fix that... but not sure if it is any cleaner.

    render() {
      return  `Hello ${ this.state.userName }`}
        else={() => `Please log in` }
      />
    }

Re: Why we chose Vue.js over React

#197
post #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…

I agree about conditionals and other kind of programming language constructs not belonging in markup. But the point of markup for content-driven web sites is that its a text format and can be contributed by persons other than web developers (authors, site users, syndicated content providers, etc).

You can see a modern approach for this is at work here: http://sgmljs.net/docs/sgmlweb.html ("isomorphic" rendering to HTML in the browser and server-side using full SGML, no less).

Disclaimer: my project

Re: Why we chose Vue.js over React

#198
post #189

Earlier quoted context omitted.

Wow. Do people consider this kind of coding acceptable now? We spent decades trying to separate templates, business logic, and inlined JS, and you managed to cram all three into a short snippet.

Yes and this is a tired argument by now. The talk by Pete Hunt aptly titled "React: Rethinking best practices"[0] given in 2013 points out how separating templates and logic is merely a separation of technologies, not concerns. [0]: https://www.youtube.com/watch?v=x7cQ3mrcKaY

Thanks for posting this, it was really interesting. Everyone who criticizes JSX should have watched it before doing so.

Re: Why we chose Vue.js over React

#199
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 as it is now isn't going to be React as it is at some future date, it will evolve. Any framework you use has an inherent risk of going stale and being replaced by the next new new thing. Luckily, to get stuff done, you don't need to be using the new new thing, so choose your frameworks based on whether it makes sense for your scenario. Jquery / UI was the rage at one stage, and it still chugs along.

React isn't the only game in town... some other popular ones are :-

Vue

Angular

Elm

All of them have a certain amount of momentum which means, for the short to mid term they are going to be hanging around. But they all have inherent tech risks going forward. It only takes a few innovations browser front end wise to be mainstream to make newer frameworks become the new new thing. For instance things like webassembly / more GUI / vector based GPU accelerated capabilities opens up new ways of putting together apps using all kinds of languages.

Re: Why we chose Vue.js over React

#200
post #162

Earlier quoted context omitted.

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.

All you need is re-frame. It is well documented and the philosophy is explained as well.

Thanks for the tip, I enjoyed their comprehensive readme. I might give this a go next time around.

https://github.com/Day8/re-frame

Post reply on HN