
Why we chose Vue.js - rmason
https://about.gitlab.com/2016/10/20/why-we-chose-vue/
======
gregmac
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
minutes?".

I ended up choosing Vue, mainly because it used simple objects for models and
I could literally just pass stuff I got from SignalR directly into it and have
it show up. Almost everything else I tried had some type of wrapper/proxy
around the data, which meant you had to run through some mapping exercise to
get models working. I was close to deciding on Mithril, but when I found vue
it just clicked with me way more. I actually really wanted to do React, but
Vue was just so much more approachable that I couldn't justify spending the
extra time learning React.

The real test however came months later, when I went to modify and add more
functionality to my simple debug UI. I was able to pick it up nearly
instantly, and even made some fairly substantial changes.

Contrast to my experience with say, Ember. We have a big app written in Ember,
and every time I try to do even what I think should be a simple change (after
not touching it for months), it takes me 5 times longer than I thought, and I
end up spending most of the time fighting with it before realizing I forgot
one of the 5 places you have to modify to reference an additional dependency,
or some other equally trivial but infuriating detail.

You can learn the basics of Vue in minutes, and be quite adept within hours of
it. That's something not a lot of frameworks can claim, and it's a seriously
underrated benefit.

~~~
lossolo
I have almost the same experience as you. I am maintaining big Ember app and
have exactly the same problems as you described with it.I am interested in Vue
lately also because it's so lightweight, easy, well structured, documentation
is excellent, ecosystem around it is excellent and i have so much more freedom
than in Ember. Author really cares about it, issues on github shows that, only
50 open and 3000 closed.

~~~
PDX_bro
Interestingly enough, maintaining and developing Vue.js is now the author's
full time job! Check out his patreon here:
[https://www.patreon.com/evanyou](https://www.patreon.com/evanyou)

~~~
riskable
Holy cow this is impressive. How do you think he came to this achievement? Was
he marketing himself really well? I honestly would love to know what it takes!

Context: I'm currently developing a new web-based remote desktop tool in Rust
and I'm still on the fence as to whether or not to release it open source.

It's a port of some work I did on Gate One that ultimately couldn't be
released due to the limitations of X11 permissions in multi-user environments
(too insecure).

What's funny is that I'm looking at using Vue for the client!

------
anonyfox
As someone who went through the complete frontend hype-trains (jquery,
backbone, angular, ember, react, all in production): Vue.js 2.0 with single
file components is exactly what everyone looks for desperately.

\- performance: faster than react now

\- learning curve: a few hours from scratch

\- getting started: cli-tool for initial scaffold & configuration

\- components: simple .vue files with a <template/>, <script/> and <style/>.
Super easy to get going, no need for JSX

\- "official" packages for routing, ajax and state management. No wasting of
days for choosing every tiny package for days

\- vuex 2.0 is one of the cleanest flux implementation i've seen in the last
year

... and much more. Give it a try with the full webpack template of the cli
tool!

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

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

~~~
kamkha
MobX is written in TypeScript:
[https://github.com/mobxjs/mobx](https://github.com/mobxjs/mobx)

------
49531
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
"just because it's popular doesn't mean it's good".

Regardless I think GitLab is an awesome company, I just got the feeling Jacob
wanted to use Vue.js because it wasn't the most popular choice. ¯\\_(ツ)_/¯

~~~
marpstar
Is there a name for this "feeling"? I feel this way about a lot of things that
get "popular". I feel this way about React, in fact. React is "good" but I
don't see it as our end-all be-all front-end savior. Vue.js is a lot more
interesting to me because it's not popular...because it's the underdog.

This Cracked article gave me a bit of consolation:
[http://www.cracked.com/blog/6-reasons-it-sucks-to-hate-
popul...](http://www.cracked.com/blog/6-reasons-it-sucks-to-hate-popular-
things/)

~~~
linkmotif
Sure popularity ruins many things. Music, movies, books, software libraries.

However, you don't have to use React. React is a set of concepts. I personally
really enjoy programming with those concepts (I just wish it wasn't JS). If
you don't want to use Facebook's implementation, there are many other
implementations.

~~~
iLemming
> I just wish it wasn't JS.

Try Clojurescript. It is truly amazing.

~~~
mixedCase
As long as you can stand Lisps.

~~~
dragandj
If somebody can stand JavaScript, that somebody can stand anything :)

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

~~~
Yaggo
So what is JSX if not DSL? (Yeah, you can use React without JSX, but still.)

~~~
kentor
You can think of it as sugar for `React.createElement()`, and some other stuff
(like spread) but that's it. It's really easy to translate into javascript in
your head.

Why is this good?

1\. Let's say I want to stick a debugger in my template or render function.
How would you do it in Vue? Angular? I don't know, gotta look it up, not even
sure if possible. How would you do it in React? I don't have to look anything
up, I just have to think (use an iife):

    
    
       <div>
         <SomeComponent
           debug={(() => { this.state; debugger; })()}
           someProp="prop"
         />
       </div>
    

2\. Let's say I want to use Immutable.JS instead of plain js arrays. How would
I iterate over an immutable list in Vue. In Angular? I don't know, probably
have to download some third party directive. React:

    
    
        <ul>
          {immutable.toSeq().map(x => <li>x</li>)}
        </ul>

~~~
randomnumber314
>How would you do it in Vue?

    
    
         {{ data | json }}
    

will give you formatted json output of the data object (i.e. state/props) In
reality you can put anything that's in the Vue object's scope between curly
braces, pipe it through the json filter.

>immutable list in Vue

    
    
        <li class="for-example" v-repeat="item in list">{{item}}</li>

~~~
masklinn
> {{ data | json }}

So neither debugger support nor printf-debugging, you just have to hope you'll
be dumping garbage in a place where it can be seen and doesn't break the page
entirely?

> <li class="for-example" v-repeat="item in list">{{item}}</li>

Ignoring that vue changed the name of the directive a while ago[0] that
doesn't even remotely work, according to its documentation v-for (née
v-repeat) works on native arrays, it's not going to work in any sensible
manner on immutable.js structures.

[0]
[https://github.com/vuejs/vue/issues/1200](https://github.com/vuejs/vue/issues/1200)

------
linkmotif
The thing I like about React is that I don't have to think about the DOM. As
soon as I see "el: #id" it's basically over for me. I don't want to think
about DOM elements, or at least minimize my exposure to them.

And it's not just that I don't like to think about the browser DOM. It's that
I don't want my UI coupled to the DOM. Obviously your UI will be coupled to
the DOM to some extent, but React minimizes that. What I love about React is
not just `react-dom` but also, say, `react-canvas`, or that you can apply the
same principles and work with React Native.

But hey, the more software libs to play with and choose from, the merrier!
Cheers!

PS. Relay/GraphQL...

~~~
ceejayoz
> As soon as I see "el: #id" it's basically over for me.

There's literally only one of those, to tell what element in the HTML to bind
the root Vue instance to. Vue doesn't require thinking about the DOM.

It's the same sort of thing as React's basic tutorial
([https://facebook.github.io/react/docs/getting-
started.html](https://facebook.github.io/react/docs/getting-started.html))

    
    
        ReactDOM.render(
          <h1>Hello, world!</h1>,
          document.getElementById('example')
        );

~~~
linkmotif
PS. What if you're the kind of person who likes coupling presentation and
logic? I really like JSX and inline styles. From my skimming, it appears Vue
separates templates and logic. Is that correct?

~~~
nogridbag
On the contrary, for most larger apps you'll want to use single file
components + webpack. I'm also a big fan of keeping markup, styles, and logic
close together and Vue's single file components are one of my favorite
features compared to React components:

[http://vuejs.org/guide/single-file-
components.html](http://vuejs.org/guide/single-file-components.html)

The only downside is that while .vue files do have editor support in most
editors, it's still not 100%. For example there are two plugins for VS Code
but neither of them are really usable at this time.

------
y0ghur7_xxx
I am more and more of the opinion that you should NOT use a js framework for
long term projects (that span more than a few years), but just use vanilla js
with some libraries that you can easily switch when something better comes
out. Vue.js is here today, and it is nice, but tomorrow gintzx.js comes out,
and the community will be flabbergasted and everyone will use it and vue.js
will slowly die. Making big complex webapps with just some libs is absolutely
possible. Just choose them wisely and make a good directory structure.

~~~
Cthulhu_
I'd like to see more standardization efforts, easier way to separate your
business logic from the UI layer. It should be possible already, but there's
often still too much interference from the framework of the week.

One thing I've been working on lately is writing unit tests (and test runner)
that have nothing to do with the underlying framework - no Angular references,
no Angular DI, nothing of the sort. Much cleaner and faster, plus it's a more
pure unit test because it doesn't test the framework or DI system.

~~~
hajile
We need the W3C to make a `node.replaceWithJsNode(obj)` or similar that takes
a uniform vdom object style and updates the DOM accordingly. It would bring
together all the different vdom implementations, reduce library size (given
time), and would be much faster because of native implementation.

------
megalomanu
As a primarly backend dev, I'm very comfortable with React and I don't
particularly want to switch to Vue.js. React says me : learn the HTML basics
and then deal with abstractions (proof: React Native !). Vue.js says me : deal
with HTML templates, everytime, everywhere. Although we even end to deal with
HTML in React, I think it's easier for a backend dev with no front experience
at all to grasp it. I showed React to a old java dev and he said that React
reminded him some java web frameworks like Wicket or JSF. I guess Vue.js would
have scared him.

~~~
pvorb
I keep hearing React reminds Java devs of JSF. But I've never heard it as a
compliment.

~~~
naranha
I am a Java developer who used to work with JSF 2 and I enjoyed it a lot. Now
I'm writing a Vue2 app and I finally feel like JS frameworks have reached a
stage where I'm nearly as productive with them as I was with JSF, while
requiring probably just one tenth of the server resources.

JSF basically provides you with a server side component tree.

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

~~~
losvedir
Agreed, I feel like I'm missing something here. I had thought that react "won"
over angular because people generally preferred one-way data flow vs.
angular's two-way data bindings.

At least for me, that's one of the biggest reasons why I feel like I
understand react better than angular. It's a little verbose at times, but it
does make it pretty easy to follow.

And it looks like Vue.js is a two-way data binding framework? I won't write it
off without trying it, but that's a point against it for me.

~~~
YCode
In React the idea that the state controls the app and as long as you maintain
control of your state your app becomes nearly deterministic is powerful.

In this way Vue or more specifically two-way data binding struck me as a step
back.

Or am I misrepresenting Vue?

------
greyskull
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
decides what will actually show up, that should happen where the underlying
data/models is actually built, and whatever acts as the view just spits it
into place.

I'm still a scrub when it comes to web and UI development, so I may be
speaking out of inexperience.

Am I missing something?

~~~
tracker1
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 the surface. Even combining with something
like Redux, or even MobX has another layer of understanding... routing and
server-side rendering more still.. but they are layers you learn and add, not
everything in one neat package.

I'm also not a fan of the custom DSLs that tend to come with templating
engines.

~~~
vladimir-y
> and computed property getters and setters

It's the exact way how it's implemented in Vue, with old fashion
getters/setters and some "magic" for already defined object fields, see for
details
[https://vuejs.org/guide/reactivity.html](https://vuejs.org/guide/reactivity.html)
Vue has no digest cycle (no dirty checking), so you there is no Angular's
performance issues.

------
agentgt
A long time ago (7-10 years ago) Web 2.0 was the craze. It was the beginning
of making interactive web applications.

There were few major players that were even backed by companies: Dojo,
Prototype, GWT, (and like 4 more that I can't remember).

These libraries were complicated and were generally component based with their
own flair of inheritance. You could not iteratively enhance your existing web
1.0 app. You had to throw it out and start over again (the markup and all).

Then along came jQuery and I remember distinctly saying to myself this is the
library because I can progressively/iteratively add it to our existing crap
(circa 2006-10). I still pat myself on the back on being right about that
library being successful (I actually forced a previous employer to use jQuery
over GWT and Dojo).

Progressive enhancement is a great marketing point so maybe Vue.js will pull a
jQuery :)

Personally I want Elm to take off but it doesn't really reuse existing
knowledge.

~~~
ChemicalWarfare
>>There were few major players that were even backed by companies: Dojo,
Prototype, GWT, (and like 4 more that I can't remember).

Vaadin comes to mind :)

+1 on Elm, also don't think the learning curve for someone with any
"functional" (even if JS) exposure is that steep.

------
octref
To me Vue is a great tool for side projects. In React I found myself
struggling to figure out what libs to use and keep myself up to date with
them. I also hated configuring webpack. With Vue, I have officially supported
libraries like vuex and vue-router which work great with Vue out of the box.
vue-cli also allows me to scaffold projects with these libraries very easily.

But the thing I like most about Vue is it allows me, who identifies as a
front-end dev or design-coding hybrid, to quickly iterate and build
prototypes. Look at the single file component:

    
    
      <template>
        <div id="list">
          <li></li>
          <li></li>
        </div>
      </template>
      <script>
        export default {
          // Define your component
        }
      </script>
      <style scoped>
        #list { list-style: none }
      </style>
    

I can quickly edit the template to alter my component's DOM structure, style
it with scoped css, and change its dynamic behavior in the script tag. Like
the suite of Jade/Coffee/Stylus? Adding a lang attribute to each tag and you
are good to go. Awesome stuff.

~~~
shriek
Wait, Vue doesn't need to be transpiled to JS like JSX? I'm equally hating
configuring webpack. It's lack of documentation isn't helping either.

~~~
sotojuan
Why aren't you using create-react-app?

~~~
Aldo_MX
Why should you?

I mean, it is really handy to have a tool to save you from the initial setup
and all that boilerplate code _when you already know how it works_.

But not knowing how the different pieces fit together will bite you when
things start to fail.

------
wadetandy
I know that Gitlab is written in pretty traditional Rails' style and takes
advantage of turbolinks. Did you run into any difficulties adding a framework
that likes to "own the page" like most single page app frameworks do? I've
found these can often end up fighting with turbolinks and similar libraries.

~~~
jakecodes
@wadentandy, Yes that is still something we are figuring out the best way. For
a major feature (like issue boards), because we won't use Vue for everything,
we load those files on a per page basis.

------
teniutza
The company I work for has an app built with Angular 1.x (the backend is
.NET). We started sensing that Angular was not best choice, especially when
working with 3rd party components. There are other factors to, but they have
been already mentioned in other comments. Long story short, we had enough of
wrapping everything in _$timeout_ and started looking at alternatives.

After some consideration, we were left with choosing between Vue.js and React.
Coming from Angular the biggest plus was two-way-binding, Vue.js had a slight
advantage. We then converted a "module" (not in JS jargon) using both
frameworks.

In our experience, when switching from Angular 1.x to Vue.js, there's a sense
of not changing much (we were still "declaring" logic in the templates) but
nonetheless doing things better, simpler and faster. The React version needed
a bit more time investment (we had no prior experience in our team; a
colleague from another project helped us a bit by showing us how he
implemented a project using React). In the end we chose React due to the
wonderful combination between it and TypeScript. We suddenly had no more
string templates and refactoring was a breeze (there are, of course other
benefits as well).

What I'm trying to say is that, if you have Angular 1.x experience it's easier
to switch Vue. I had fun porting the "module" to Vue and would have happily
worked with it if the team had not chosen React. I consider "mixins" to be one
of its killer features (would have made a lot of things easier with our app).
Having said that, I don't consider React that hard to grasp and don't regret
that the team picket it over Vue. As long as you remember the lifecycle,
programming with it can be fun and easy. The React/TypeScript combination
compensates for the lack of mixins and two-way-binding (I know, MobX, but I'm
talking about the "vanilla" versions).

~~~
mmusc
We had a similar experience in our office. We chose Vue.js and we are all very
pleased with the results. Vue is simple enough to understand and be productive
in in a reasonable amount of time.

------
skc
I hate web dev.

Yet I'm loving the experience of working with VueJS. I think alot of people
feel this way. The library is just that simple and straightforward.

~~~
jsjsjsjsjsjs
Exactly how i feel. They maintain project perfectly as well. Issues are
tackled with utmost urgency. This is what angularjs was supposed to be. VueJS
is perfect (as much as software can be perfect).

------
antarrah
> He pointed out that when a major software company releases a their secret
> sauce, there is going to be hype. Devs think to themselves,'That company
> writes JS differently than me, and they are prominent and successful. Is
> their way of writing JS better than mine? And therefore must I adopt it?'

Ahaha. No, believe me I'll not. That's ironic coming from GitLab. I mean I
love that company but their front-end sucks big time and it's slow as a snail.

~~~
eberkund
Honest question, how do you know that it's the frontend that's slow and not
the backend?

~~~
wldlyinaccurate
You only need to look at a DevTools timeline to see that it's the front-end
which is slow:
[https://www.webpagetest.org/result/161021_08_XZF/](https://www.webpagetest.org/result/161021_08_XZF/)

600KB of CSS, 800KB of JS... That's fine on your MBP over WiFi but on most
pages it locks up the main thread on my phone for a good 5-10 seconds.

~~~
jakecodes
Hi wldlyinaccurate, thanks for your comment. There are a lot of frontend
performance things we are focusing on for the next release.
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/23213](https://gitlab.com/gitlab-org/gitlab-ce/issues/23213).

~~~
wldlyinaccurate
Cool, I'm glad to see there's a meta issue to track this stuff now. Couple of
questions:

Is there a strategy to tackle the CSS and JS bloat?

Is performance something the front-end endboss folk consider important enough
to delay feature releases?

Are you monitoring performance with a tool like SpeedCurve?

------
nodesocket
I as well gravitate toward Vue.js for its simplicity, but I wonder if React's
mind share and community size "trump" simplicity. For example, if you're
hiring for a front-end position, you'll probably get more candidates familiar
and experts in React over Vue.js.

~~~
thaiphanvevo
The thing is that most React developers don't actually think React is that
complex at all.

~~~
kyriakos
I think react has a steep initial learning curve but once you grasp the
concepts it's not complicated. It is more verbose than vue though and requires
more setup and boilerplate to get started.

~~~
hesarenu
React is very simple. You need to understand only its basic life cycle. Rest
is just JavaScript.

~~~
askmike
I disagree as soon as you write more than a single nested child/parent
component, that requires a different way of thinking (should I use state or
props?). And that you can't "just uses react". You kind of have to use redux
(or similar) as well as a bunch of other stuff.

~~~
mambodog
People keep saying you 'have to use redux' but I think that's hugely
misleading to a large section of potential React users who don't need the
highly complex state management that redux facilitates, and could get by just
fine with setState+props.

I'd hope that people who are being exposed to this idea at least also get the
chance to read 'You Might Not Need Redux':
[https://medium.com/@dan_abramov/you-might-not-need-redux-
be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)

~~~
cageface
Amen to that. Seems like everybody is cargo culting Redux but really you can
get pretty far with just React plus some wrapper components to hold state.

------
stop1234
So true:

' I talk to a lot of JavaScript devs and I find it really interesting that the
ones who spend the most time in Angular tend to not know JavaScript nearly as
well. I don't want that to be me or our devs. Why should we write "not
JavaScript?" '

------
kimshibal
Vue.js is the most beginner friendly to write a complex web application.

~~~
ergo14
Vue is inspired and similar to polymer - this is what I like about it. If i
wouldn't be able to pick polymer i would probably go with Vue, but I picked
web standards + bigger ecosystem over vue.

------
mhd
Just pick _something_ , internet and build a good structure _on top of it_.
All this jquery-level bikeshedding is nice for your ad widgets and
minimalistic web apps, but it won't help me replace proper GUI toolkits. And
sadly, that seems to be in demand...

I'll cope with your ill-designed template language (heck, if I can cope with
HTML, I can cope with anything) or your JS async abstraction du jour
(promises, async await, that * crap), just give me something on the level of
Tk or Swing. I feel like all we got in the last decade beyond e.g. Seaside is
a bit less flicker and some more useless animations (looking at you, Material
Design buttons).

~~~
fasouto
>>> if I can cope with HTML, I can cope with anything

Just curious, what do you find so terrible about HTML?

~~~
mhd
HTML's horrors are highly context sensitive. One of its most generic sins is
the poor support for hypertext. Various predecessors did a better job at this
(Hyper-G, HyTime). Anchor- and URI-based hyperlinks are a rather insufficient
solution, and I think the web would've benefitted from a more extensive and
extensible architecture.

Speaking of extensible, HTML has the "class" attribute. Awesome. Something
better would've spared us a lot of template languages in the first place. Not
looking at you, XSLT.

And when we deviate too much from both HTML's and its ancestor SGML's original
purposes, the syntax gets really ugly. Explicit end tags make sense if the
beginning of your document's <chapter> is more than a terminal's length out of
sight, but when used in something you build UI elements out of (or where
content isn't immediately there), the verbosity hurts. Never mind the general
XML problem of sub-tags vs. attributes.

At least the amount of different standards is getting better. Parsing still is
way more complicated than it needs be.

And let's not even start with the lateness and insufficiency of CSS.

As bad as it was as a hypertext markup language, it's even worse as core
structure for this weird NeWs-like quasi-PostScript we're squeezing
HTML/CSS/JS into, for lack of a better alternative.

------
techbubble
Vue.js seems like a great fit between the DOM manipulation of jQuery and the
opinionated approach of AngularJS. Thanks for sharing. Going to experiment
with Vue.js right away.

------
Abundnce10
I'm in the process of learning React, so I don't have any strong opinions of
my own yet. I've read through the Vue.js "Getting Started" docs and it does
look very intuitive/simply. However, what motivates me to learn React is the
fact that I can build an app once and then use React Native to create an iOS
and Android app. I'm assuming this isn't a requirement for Jacob and the
Gitlab team but I'm wondering if his decision would be the same if he had to
support native apps as well?

------
pjungwir
Can anyone compare Vue with Knockout? In the early days of Angular etc I saw a
lot of people saying they chose Knockout, and were much happier than with one
of the heavier frameworks. I found its simplicity very appealing too, but it
seems clear now that it's not a mainstream choice. It feels to me like a dead
end. The last time I looked (a year ago?) the semi-official data mapping
extension had lost its maintainer. So is Vue another shot at the same
approach? What are the important differences?

~~~
thegeekpirate
[https://vuejs.org/guide/comparison.html#Knockout](https://vuejs.org/guide/comparison.html#Knockout)

------
aarpmcgee
Are any companies switching from React to Vue? I'd be interested in hearing
about that.

~~~
kimshibal
Our company migrated to vue.js, 4 months ago. Our complex app is messy with
JSX, router, and new dev can't keep up with code. Now we start every new app
with Vue.js. The gap between junior dev and senior dev comes closer. They can
collaborate with less bugs, less problems and less time to develop.

~~~
megalomanu
New React projects are today much simpler, thanks to new libraries to manage
state like Mobx, or efficient starter kits. So without denying the benefits
you encounter with the migration to Vue.js, I think that a full rewrite of you
React app in "modern React" would have been a good thing too.

~~~
j1436go
And how long until the next "modern React" will land? That's what drove me
away from React.

~~~
megalomanu
Before, React projects evolved because they have to. They became too complex,
to clumsy, etc. But now ? React is stable, the way to develop apps is well
known, etc.

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

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

------
sjnsjn
It (v2) is quite fast too
[http://www.stefankrause.net/wp/?p=316](http://www.stefankrause.net/wp/?p=316)

------
asymmetric
> I'd say Vue.js is like socialism: you are in definitely in charge, but
> Vue.js is always within reach, a sturdy, but flexible safety net ready

I think he means social democracy

------
jbrooksuk
Side-project wise, we use Vue on StyleCI
([https://styleci.io](https://styleci.io)) and over the next few months we'll
also be using it on Cachet ([https://cachethq.io](https://cachethq.io)).

My experience started at work where we used it on an internal project. The
ease of use was insane, we had something reactive and easy to work on in no
more than 10 minutes. React has always had too big of a learning curve for us,
so it'd have been a vanilla JS/jQuery mess if we hadn't found Vue.

We're now using it on almost any project we start (they're all very UI
driven).

I met Evan You at Laracon earlier in the year, he's an awesome dude and has
put a lot of thought into everything Vue. Thanks again for making Vue! :)

------
esafwan
I had a look at Vue after a long time and then weex a react native alternative
using Vue.js instead of Reactjs. Backed by Alibaba and actively developed it
looked really good. But a look at issues made me a bit afraid to use it. The
primary language used for discussion, suggestions etc is chinese.
Documentation however is available in english.

[https://alibaba.github.io/weex/](https://alibaba.github.io/weex/)

------
tribby
vue is awesome.

I wish there were an equivalent to something like ember-fastboot for out-of-
the-box server side rendering, though. (server-side rendering for those who
care about progressive enhancement in the browser, not isomorphism).

~~~
dflock
Vuejs 2.0 does server side rendering, afaik.

~~~
tribby
it does, but that isn't my complaint: there isn't an official, opinionated way
to do it - something that syncs vue-router to express and serves. it's a
common enough problem that fastboot solved it for ember, and I wish vue had
the same.

------
thex10
Fun fact: There's a Vue-based HN clone: [https://vue-
hn.now.sh/top](https://vue-hn.now.sh/top)

I just realized that it's more dynamic than I thought when I saw two stories
switch positions on the page. How cool!

------
adamnemecek
These discussions almost never mention cycle.js. I haven't done front end in a
couple of years but whenever I read something from the author of the
framework, I'm pretty impressed and the choices they made seem very promising.

------
flukus
Is there anyone that's used Vue and knockout that would like to share the
strengths/weaknesses of each? The both seem quite similar so I'd like to know
if I missing out on anything by not switching.

~~~
thegeekpirate
[https://vuejs.org/guide/comparison.html#Knockout](https://vuejs.org/guide/comparison.html#Knockout)

------
WA
I tried Vue.js a few months ago and liked it a lot. But now, I need to rewrite
my apps and I decided to go the Cordova road with Ionic 2, because Ionic 2 is,
imho, unparalleled in its quality.

Ionic 2 uses Angular 2 and I wished there was some Ionic 2 + Vue.js bindings.
However, after working with it for a bit, I found that Angular 2 is actually
quite simple with the benefit of using TypeScript out of the box.

Before you dismiss Angular 2, give it a try. It's fundamentally different from
Angular 1: easier to learn, less complex, faster results.

~~~
Svenskunganka
Have you looked at Weex[1]? It's what Ionic is to Angular, the only difference
is that Weex and Vue has an official collaboration and Weex has been embraced
by Vue's developers - something that Ionic hasn't yet been by the Angular team
as far as I'm aware.

Note though that the collaboration is still very young between these two, but
I believe we'll see some great things in 2017 from this collaboration!

[1]: [https://alibaba.github.io/weex/](https://alibaba.github.io/weex/)

~~~
WA
Yes, I did and I don't like it very much. Docs are partially in Chinese,
almost no examples. Compare this to Ionic 2, which is very close to native
elements, including animations.

------
cmpb
My team and I are considering switching from Knockout.js to Vue.js. Has anyone
here made that (or a similar) transition and do you know of some pros / cons,
battle stories, etc.?

~~~
tracker1
you'll probably see less disconnect from Knockout to Vue than pretty much any
other modern js ui approach... even ng1 to ng2 is a really big break. I happen
to like React's approach more, as it's more pure to JS (even with JSX) than
augmented DOM, or template engines are imho.

------
wasd
It would nice if they shared the 30 -> 1 line change.

~~~
M4v3R
I'm guessing those 30 lines were for manipulating the DOM or getting the data
from form elements. In Vue similarly like in Angular you don't need to write
code for that, because the data is 2-way bound. You just do something like
this.data = ... and you're done.

------
fczuardi
I like the ideas of the choo framework
[https://github.com/yoshuawuyts/choo](https://github.com/yoshuawuyts/choo)
it's very close to vanilla js, which makes it less of a lock-in, while still
bringing lessons learned and practices from redux/elm-architecture.

I am currently using it (the 4.0 branch) in a project and enjoying it.

------
BinaryIdiot
How does Vue.js handle high latency issues? With Angular 1.x I've always had
issues where the GUI will "flash" while the HTML is loading and the angular.js
has not yet finished loading on a slow connection (so you might briefly see
all of these {{message1}} {{message2}} etc on the page). I'm curious how
Vue.js handles that case or if it has the same problem.

~~~
miaumiau2
ng-cloak is your friend..

~~~
BinaryIdiot
I guess but it feels like such an anti pattern. I have to tag every thing that
uses the template system with ng-cloak and that assumes the angular css loads
before the HTML which can still not be guaranteed it's just more likely.

The worst part is many default values could be displayed but now we're hiding
sometimes large junks when for the best UX you should show as much of the page
as possible.

Ultimately just not a fan of any template engine that relies on being fast
enough to hide and replace values in the raw HTML.

~~~
really_operator
To reduce the need for ng-cloak, use ng-bind

<p ng-bind="value"></p>

instead of

<p>{{value}}</p>

It is preferable to use ngBind instead of {{ expression }} if a template is
momentarily displayed by the browser in its raw state before Angular compiles
it. Since ngBind is an element attribute, it makes the bindings invisible to
the user while the page is loading.

~~~
BinaryIdiot
Interesting, I forgot about ng-bind (honestly it's a pattern I _never_ see on
the web). That is, for sure, the superior pattern.

------
jeppebemad
We _just_ started using React, primarily for it's server side rendering
support in .NET with Reactjs.net. Works really well and the React mindset
feels great.

Coming from Angular 1 though, Vue has a lot of appeal. Is there any support
for SSR in .Net, or anything in the pipeline? I've not been able to find
anything.

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

------
haalcion3
I'd like to discuss the following comparison in:
[https://vuejs.org/guide/comparison.html#Angular-2](https://vuejs.org/guide/comparison.html#Angular-2)

> Vue 2.0 seems to be ahead of Angular 2 according to this 3rd party
> benchmark. ( [http://stefankrause.net/js-frameworks-
> benchmark4/webdriver-t...](http://stefankrause.net/js-frameworks-
> benchmark4/webdriver-ts/table.html) )

The latest benchmark provided is actually:

[https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts/table.html)

But, Angular 2 is v2.1.1 now, released 2016-10-20. Someone should update:
[https://github.com/krausest/js-framework-
benchmark](https://github.com/krausest/js-framework-benchmark)

However, as they say, "In terms of performance, both frameworks are
exceptionally fast and there isn’t enough data from real world use cases to
make a verdict."

And Angular 2 Hello World is easier than they make it seem in the comparison:

> starts out with an app that uses ES2015 JavaScript, NPM with 18
> dependencies, 4 files, and over 3,000 words to explain it all - just to say
> Hello World.

It's just the following with a lot of documentation that could be simplified:

    
    
      mkdir angular-quickstart
      (add package.json)
      npm install
      mkdir app
      (add app.component.js)
      (add app/app.module.js)
      (add app/main.js)
      cd ..
      (add index.html)
      (add styles.css - optional step)
      npm start
    

Also, it makes the case that Angular2 is "enterprise" because many use
TypeScript with it. But, TypeScript is optional in both Vue and Angular2, so
people could just as easily make the argument that Vue is "enterprise" because
it supports TypeScript.

Finally, it's true that Google uses/develops Angular2, so that's some
significant backing. If you want to see who's using Vue:

[https://github.com/vuejs/awesome-vue#projects-using-
vuejs](https://github.com/vuejs/awesome-vue#projects-using-vuejs)

That doesn't mean anything on its own, though. It could be just fine to use
and expect to continue to be hyped.

~~~
rk06
>But, TypeScript is optional in [..] Angular2,

typescript is not optional. Just look at the official docs. the js version of
docs are still incompelte even though 2.1 has been released.

>it's true that Google uses/develops Angular2

Google's major product is adwords. And adwords is built on angular2 dart
version. While devs mostly use ts version.

------
dodyg
I like Vue. I am using Ractive.js at work. They are both quite similar in
terms of their prioritization of ease of use and performance.

------
asb
Has anyone had any experience with vue.js + Dart?

------
jvanveen
Nice readup. There are fine alternatives to react. Another vdom lib that's
pretty good and not often mentioned is ractivejs.

------
breerly
Not a single link to Vue.js

------
lucaspottersky
Why? because you're a bunch of hipsters that can't stick to the mainstream
technologies =)

As an opensource project, it'd be easier to get contributors if you could just
stick with Angular.js, for example.

------
nidu
I suppose Vue.js is not very TypeScript friendly?

~~~
dyu-
It is very friendly. I've successfully migrated my gwt + vue-0.10 stack to
typescript 2.0 + vue 2.0

Shameless plug:
[https://github.com/vuets/vuets](https://github.com/vuets/vuets)

It is a micro-lib less than 100 LOC.

------
iamleppert
Why is it that the first instinct of some developers is to go out and 'choose'
a framework? Even before you know the thing you're building is going to be
around for awhile, people automatically think they need a framework to do
anything these days.

Does it feel good to let someone else make critical decisions for you, instead
of thinking for yourself? Can all projects really be distilled down into some
javascript framework?

The benefits of using a framework these days are rapidly evaporating as what
is trendy today likely won't be in a few years anyways. And the truth is after
so many months or years or commits, the benefits of structure of the framework
start to fade away as the application becomes more customized and bespoke. All
the complexity is in the actual application functionality, not the tiny little
savings and poor abstractions that a come with a framework.

I've worked for large tech companies and small alike. It all goes the same
way. Some developer who is super opinionated and passionate props up their
framework of choice, or does some kind of perfunctory analysis of the "current
best" of whatever is available at the time and the rest of the other more
submissive developers go along with him. It has more to do with group dynamics
than has to do with actual technical merit, or what is best for the product or
business.

Then, once the system has become a ball of mud, the "lead" guy leaves. Or he
proudly exclaims there's a new hotness in town, and that we need to rewrite
our application in this new thing because it's faster, or better, or you get
to type less. Or some other such bullshit. He'll then go to give demo's of how
fast you can make a simple app that has nothing to do with anything -- like a
simple TODO list -- "look how fast it renders!" he'll exclaim (of course
forgetting to tell everyone the first page load or stale cache hit is actually
worse).

I personally hate giving up the freedom of what abstractions I get to decide
on, how to structure my code, how to organize my API's, etc. for a supposed
one size fits all solution created by someone I've never even met or talked
to, and for code that I haven't reviewed.

If it's a library that's doing something useful and providing a great API,
like some 3D graphics, drawing primitives, ML, database engine, etc. that's a
different story. That is useful software that actually does stuff. But for
"rendering" (I say that lightly because the browser does the rendering and
layout, a framework merely is a middle-man) forms and buttons and keeping
state of an application? Or telling you how and where to put source files, and
name things? That's your job as a developer to come up with these conventions
and to build an application that is 1:1 with the problem domain.

------
spankalee
It's really a shame that Vue doesn't use standards like custom elements.

------
baybal2
>Why we chose Vue.js

Why?

------
thecrow1213
No comparison to React... Yawn.

------
whataretensors
Vue-cli is great too. It just works, creates a really well thought out initial
project that can build to a single static html/js/css. Or, it can be turned
into a typical express app easily. This makes Vue.js combine well with
serverless.

------
whatnotests
It's great to hear a success story. Kudos to the GitLab team.

------
smegel
Oh man, I just started learning React...
[https://vuejs.org/guide/comparison.html](https://vuejs.org/guide/comparison.html)

~~~
tracker1
I find the comparison to React there pretty biased, especially wrt the
learning curve... JSX is a cakewalk, and OMG, oh noes, you need to know the
current JS language.

~~~
danielsamuels
Well the React guys wrote a lot of it, so..

------
ilostmykeys
Building something fast is a radically different proposition than being able
to maintain it with ease. React is mostly aimed at the latter while VueJS at
the former. There is no comparison.

