Live data from Hacker News

Why we chose Vue.js

about.gitlab.com

181–190 of 282 posts

Re: Why we chose Vue.js

#181
post #56

Ok, so I've built stuff in Vue.js, React and Angular and I need to understand all the rage. I mean, Vue.js is just like Angular but with less features? I like that it's slimmer, don't get me wrong, but I just don't understand the "woah, Vue.js is the shit!" when we've had Angular for so long. I put this in contrast to React where it's a completely new concept.

React is not a new concept, it is moving back to tried and true basics, honestly it's one of the few JS frameworks that has been built by people that learned from past mistakes, from former implementations:

https://bitquabit.com/post/the-more-things-change/

Re: Why we chose Vue.js

#182

There's something that irks me about incorporating logic into templates. UI development is hard enough without having to bounce between js and templates to figure out how a component is actually going to behave. I haven't used Vue or React, so this is all just my gut speaking, but at least with React all the logic is there in front of you. In my mind, if there's a loop or a conditional or whatever piece of logic that…

I just don't like the bidirectional data binding that vue seems to bring with it... I've had enough experience with this in Angular at this point to know that it's painful... then the easiest way around those issues is to use classes, and computed property getters and setters. In the end, it's just painful. React is much clearer here, but there is more of a cognitive load in getting used to it, there's less magic at…

> I just don't like the bidirectional data binding that vue seems to bring with it...

Vue 2 ditches it entirely, in favor of Vuex, which is inspired by Redux in part. http://vuex.vuejs.org/en/intro.html

Re: Why we chose Vue.js

#183
post #11

I do very little web these days, mostly working on backend data processing, network I/O and distributed comms. A bit over a year ago, I wanted a real-time web UI to visualize some of the data I had on server-side, which I was trying to do using SignalR. I went back through some of the popular frameworks, with a pretty simple mindset of "Can I read the 'getting started', and get something basic working in about 15 min…

Thanks for sharing your experience. As someone at a place with both ember and Mithril it's relevant to me. Can I trouble you for a couple more details? Did you use MSX with Mithril? We found Mithril to be usable without MSX but clicked more for people with MSX. What thoughts do you hear from people who work on the ember app regularly?

> Did you use MSX with Mithril?

No, because it was green-field and I was trying to keep it as simple as possible; having to have a build step to run the MSX tooling was not really worth the complexity.

> What thoughts do you hear from people who work on the ember app regularly?

Mostly frustration, honestly. The main developer (who spends most of his time in Ember, though wasn't part of the team when it was originally built) has more background in Angular, and a number of times has lamented how much easier things are there. Although he's still reasonably productive now, it took months to get to that stage. Everyone else comes and goes, depending on what we're working on, and the general feelings seem to be somewhere in the spectrum between mild frustration and hate.

Maybe another interesting point.. We used to get new hires to start with fixing small UI bugs to help them learn the systems and do something with immediate highly-visible impact. We really can't do that with Ember.

I think if your style/mindset perfectly meshes with that of Ember, and you specifically decide to devote a considerable amount of time (months) to becoming an Ember expert then you can certainly master it and make good use. I'm not sure you'd produce anything better than someone who had the same time and level of mastery of React or Angular or Vue, however.

Re: Why we chose Vue.js

#184
Is there a normalized performance suite that compares the popular front-end frameworks?

I understand if performance is of utter most importance, you may not want to use a framework layer. However there are tons of other benefits associated with using a framework.

Re: Why we chose Vue.js

#185

Earlier quoted context omitted.

I started reading through the docs and found it very similar to Knockout.js. Is here anyone who used both to tell the advantages of Vue? FYI, I'm thinking about dropping Knockout because some performance problems I'm having with a very specific use-case.

React with MobX, Vue and Knockout all seem very similar. I am wondering if TypeScript is a first class citizen in either MobX or Vue - in my experience seeing TypeScript everywhere in Angular 2 has been one of that platform's biggest wins.

yep, Vue has an official support for TypeScript as well: https://github.com/vuejs/vue/tree/dev/types

Re: Why we chose Vue.js

#186
post #11

I do very little web these days, mostly working on backend data processing, network I/O and distributed comms. A bit over a year ago, I wanted a real-time web UI to visualize some of the data I had on server-side, which I was trying to do using SignalR. I went back through some of the popular frameworks, with a pretty simple mindset of "Can I read the 'getting started', and get something basic working in about 15 min…

hmm I used signalR with angular 1.x and can't speak for your 15 min requirement but I definitely didn't have any need for proxies or model mapping. I suppose if you're using knockout you'd need that (at least call a utility function to translate plain objects into KO objects) but did you find that with Angular?

I actually didn't get to Angular. I put it down on the list because it was while Angular 2 was in alpha, and there was a lot of controversy and uncertainty around it at the time, and it was very unclear from my perspective of which version I should even look at.

Angular 2 was alpha, still changing, and had the potential the community would fork and I'd be stuck on the wrong side. At the same time, Angular 1 was of course 'old', and there wasn't any real migration path yet, so I didn't want to be stuck on the old version and have to re-do everything anyway.

I was happy enough with Vue before I got to actually building anything in Angular, and from reading docs I didn't see anything compelling enough over Vue (in either 1 or 2) to warrant going further with it.

Re: Why we chose Vue.js

#187
post #32

After using React, I am firmly in the #nevertemplates camp. I don't ever want to learn a template DSL again when I could be using the full power of javascript.

Jsx is horrible is mixing markup and code all over again A DSL like Elm does is much better

JSX is simply unobtrusive javascript realized at it's logical conclusion. I don't understand why people complain about it so much.

https://medium.com/@housecor/react-s-jsx-the-other-side-of-t...

Re: Why we chose Vue.js

#188
post #17

Earlier quoted context omitted.

If you pair React with something sane like MobX, the React API surface that devs will need to use will be tiny.

I get that you can do some cool things with Redux but I'm not sure it really should be the go-to state management tool for React apps. It requires so much ceremony to even do simple things and the async story is pretty complex. I haven't tried Mobx yet but it looks like a saner solution that don't need Redux's more advanced state management tricks.

Redux never really gelled with me and I couldn’t really understand why until I settled with MobX: all the boilerplate and some idiosyncratic names you need to know to really understand and use Redux was too much friction for me.

Re: Why we chose Vue.js

#189
post #145

Same here, using Vuejs, glad more people are using it. It's amazing that a one-person-project(well, it's more than one person now but the core part is really just one guy) can develop such a beautiful system that actually feel better than angular2 and reactjs and who knows how many are behind those two projects.

Honest question: How large are the teams that back(ed) Angular, React, jQuery, etc?

Re: Why we chose Vue.js

#190
post #154

I actually interviewed with Jacob Schatz when he was trying to figure out which frontend framework to use for GitLab. I had been working in React for the last year or so which was apparent on my resume. He prefaced our interview with something to the effect of "I know you do a lot of React but we are not going to ever use React at GitLab" It was weird. I tried to ascertain his reasoning and pretty much all I got was…

Hi @49531. Sorry you felt that our conversation was weird. Regardless of my opinion of React, Vue or any Frontend Framework, I never want anyone to have a weird interview.

My main feeling with Vue vs. React (maybe this should be a different post, as this post was meant to explain why Vue, and focus on the positives):

1. Vue is minimal to add in with existing code. React, is also not bad, but Vue is much simpler to mix in when you can't do a complete refactor.

2. React has a higher learning curve for large scale. I did not want a DSL. That's more stuff to learn and more things to debug.

3. GitLab's modus operandi has always been to keep things as simple as possible, Vue fits that. React does not.

4. React isn't just React it's many other things that you probably want to include.

I've written very large Vue, Angular and React projects in the past. I never had to think twice about which was the easiest to write a large scale project with. Vue scales well. It's never confusing. That doesn't mean that React is bad, or Angular is bad, it just means that the next time I have a choice I'll just choose Vue.

Post reply on HN