
Vue.js 1.0.0 - uptown
http://vuejs.org/2015/10/26/1.0.0-release/
======
EvanYou
Author here - thanks for the submission, I was actually planning to do it
tomorrow :)

Anyway, for those of you who are not familiar with Vue, here's a blog post
explaining why it's worth taking a look at:
[http://blog.evanyou.me/2015/10/25/vuejs-re-
introduction/](http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/)

~~~
lemevi
> More importantly, there’s no need to worry about calling $apply in a
> timeout, or calling setState(), or listening to store events

Calling `setState` is not a big deal and neither is dealing with stores. It's
very simple and you keep your state separate from your HTML.

At this point I probably can't do web development without JSX and not be
miserable. The days of separate templates are hopefully forever behind me. Not
trying to dismiss your very hard work I'm sure, but React has taken us into
the future. Maybe with esperanto you could add templates into your own JS or
make it work with JSX and react-dom.

~~~
hhsnopek
I disagree, I've never used jsx and I can still build web apps. There are
plenty of templating languages to choose from, my choice is Jade. I actually
have never touched React because I've never had so much DOM manipulation to
make use of it. If anything I can smoothly update my DOM with
marionette/backbone and a little css animation.

~~~
Kiro
What are you disagreeing with exactly? They're not saying you can't build web
apps without React and if you haven't even used React I don't see how you can
make any judgement on that part.

------
swsieber
I haven't used a ton of javascript frameworks, but here are noteable things
from my point of view (my own tl;dr):

* Doesn't support IE8 and below because it probably uses ES5.1 getters and setters - no more manually watching an object

* Supports component based programming - css/js/html in one file. But it supports any preprocessor, so it could be sass, coffeescript and jade

* The components are easily composable

* Excellent module support / support for browserify or webpack

* Clean upgrade path: adds new features without breaking the api, but does through deprecation warnings to guide the upgrading user

* 100% code test coverage

* Has a nice, simple built in router

* Has a very nice release page / layout

I haven't been this excited about a framework in a long time. I'll probably
use this in my own personal project.

Edit: Wow, the docs look great. For being 99% a one man job this is
incredible. I'm very impressed. If I was a employer I'd hire you.

Second Edit: Here's a comparison page for Angular, React, Ember, Polymer and
Riot.
[http://vuejs.org/guide/comparison.html](http://vuejs.org/guide/comparison.html)
. Of course it's in support of Vue, but it was an interesting read.

~~~
cheapsteak
His response time for resolving Github issues is also remarkable

I usually make a reproduction in the evening and find out by next morning if
there's been a fix or if I've been doing something wrong

Has made using Vue in production feel very safe

------
duebbert
Not commenting here often but I'm a big fan of VueJS! Really hope this will
give it more traction now. It has such a small learning curve with then more
and more powerful features (self contained components FTW!). Evan is fantastic
and bugs are fixed within hours.

Been using Vue for over a year and it replaced an ambitious Angular project
for internal operations management which was getting out of control. Migrating
to and using VueJS was like a breath of fresh air.

For me it's the best compromise between React and full frameworks like
Angular/Ember. Can't believe this isn't backed by a megacorp yet and just a
personal project. Congrats, Evan, and thank you!

~~~
rdsubhas
I normally hate +1s, but same here! We ran a VueJS workshop last year for
budding web developers, since it is infinitely more easier to teach basic
concepts like data binding, templating, filters, scopes, etc. with VueJS than
Angular.

[https://twchennai.github.io/geeknight/aug2014.html](https://twchennai.github.io/geeknight/aug2014.html)

And here are all the codepen exercise books

[http://codepen.io/collection/zvnFi/](http://codepen.io/collection/zvnFi/)

------
twsted
I like it. In fact I like it more than React, which I am not using (still a
happy Backbone user).

A thought that I share, from the guide:

"API-wise, one issue with React (or JSX) is that the render function often
involves a lot of logic, and ends up looking more like a piece of program
(which in fact it is) rather than a visual representation of the interface.
For some developers this is a bonus, but for designer/developer hybrids like
me, having a template makes it much easier to think visually about the design
and CSS. JSX mixed with JavaScript logic breaks that visual model I need to
map the code to the design. In contrast, Vue.js pays the cost of a lightweight
data-binding DSL so that we have a visually scannable template and with logic
encapsulated into directives and filters."

What do you think?

~~~
seivan
Massive render() sounds like those massive viewControllers from Cocoa. With
experience it slowly goes away. But yeah it can be daunting to look at sample
codes and see 300 lines of render(). It helps if it's broken down in named
function calls, but still makes you jump around.

~~~
k__
You can always decompose the components, if your render() gets to big.

------
andrewray
I've always heard good things about Vue from its users. I have to compare all
Javascript frameworks to React, because to me React feels like the first
framework that got it "right." The API of React is surprisingly thin. Looking
at Vue templates, the syntax seems quite alien, halfway between Django and
Angular:

    
    
        <th v-for="key in columns" @click="sortBy(key)" :class="{active: sortKey == key}">
    

And the API seems to needlessly separate HTML and Javascript, with some
strange (to a newcomer) API calls:

    
    
        Vue.component('demo-grid', {     // moving away from JS classes
            template: '#grid-template',  // Why separate view code from view code?
            replace: true,               // what is this?
    

Has anyone heavily used React and Vue and have an argument for what this
thicker API affords?

~~~
girvo
I've written large apps in both; interestingly, I've built the same app twice
as well: once in Vue.js and once in React. I'm also in the process of building
another very large front-end in Vue.js at the moment.

The big thing is that while I personally adore React, it does require ceremony
to get stock-standard behaviour. We recently onboarded a new developer (a
friend of mine), and teaching him React + Flux (Alt.js) was infinitely more
difficult than teaching him Vue.js -- the "thicker" API (which is still an
order of magnitude thinner than Angular or Ember) means you don't need to
either reach out to other libraries to achieve tasks that you otherwise would
need to in React.

Now, that's not a bad thing on React's side; it's a view-layer, not much more.
That's okay, and a good thing! For building components rapidly in a regular
"client -> designer -> cut-up -> development" workflow, Vue.js is streets
ahead of React in terms of code required. But for building very large
applications, React's smaller API means that you can guarantee behaviour _,
and things are consistent.

Basically, they are both brilliant libraries. I highly recommend both. React
and Vue.js are similar in a lot of ways: they're both tiny little view layers
that are component focused and have modern, ecosystem aware build tooling.
They differ in that Vue.js is "classical" (though not really, it's far nicer
than the older systems) MVVM which has been proven time and time again to be a
good architectural choice, whereas React.js takes a more functional (as in
programming) approach to the problem -- though I'd argue not far enough down
the functional side, which is why I've been enjoying Cycle.js so much!

_ unless you get bitten by event pooling...

~~~
RobertoG
"and teaching him React + Flux (Alt.js) "

Can I ask what do you use for routing and if you have good results with that
mix?

~~~
girvo
Interestingly, we're using our "own" router that I wrote in a fit of
frustration; it's tiny, not particularly well documented and has the
interesting design choice of handing the route matching on to the user of the
library; give each <Route /> component a name and have your route matcher
callback return that name and you're good to go.

The reason why I went down that route (pun intended) was that we built a
rather large, isomorphic/universal web application that for SEO reasons had to
act like a website vs a web app most of the time; until it started up the
client side JS anyway. "react-router-component" was so close to what we
wanted, but because it used React's somewhat undocumented "context" feature,
it didn't play nicely with our Flux implementation at the time (Flummox).

For that reason, my tiny router came into being, and for some reason it keeps
sticking around despite my best efforts...

[https://github.com/studionone/react-
isorouter](https://github.com/studionone/react-isorouter)

Ps. I just found out that the README links to non-existent documentation, I
really should fix that...

~~~
RobertoG
Thanks.

I'm trying to find my way around flux but until now has been a little
frustrating experience.

I wish something like Elm was mature enough.

~~~
girvo
> I wish something like Elm was mature enough.

So do I :)

If you're not 100% up on Flux, I recommend having a play with Hoverboard[0] --
it's a tiny implementation of the Flux architecture, with some interesting
choices itself. It's a single function, too, which is pretty neat!

I've been using it to implement the "Flux Challenge" in combination with
domChanger[1] instead of React: [https://github.com/girvo/domchanger-
hoverboard-flux-challeng...](https://github.com/girvo/domchanger-hoverboard-
flux-challenge)

And here's a partial TodoMVC implementation I wrote in Hoverboard and
domChanger: [https://github.com/studionone/todomvc-domchanger-
hoverboard](https://github.com/studionone/todomvc-domchanger-hoverboard)

\---

[0]
[https://github.com/jesseskinner/hoverboard](https://github.com/jesseskinner/hoverboard)

[1]
[https://github.com/creationix/domchanger](https://github.com/creationix/domchanger)

------
mikeemisme
Vue is a breath of fresh air. Easy to understand and get running with, while
having some really sweet features (and supporting libraries) if you wish to
dig deeper.

Another thing I take into consideration: Aesthetics and the give a shit
factor. The website and syntax (imo) are beautiful and succinct, and Evan's
work ethic and responsiveness is incredible.

------
jtwebman
Sorry I can't get past the two way data binding. I have seen the issue it
causes and how one way makes things so much easier to reason with. I do wish
the project the best of luck though as all these frameworks do a great job at
borrowing from what others do well.

~~~
EvanYou
In Vue two way data binding is just syntax sugar for handling form input
events. If you are talking about component state, the default mode of passing
data in Vue is in fact one way.

------
oweiler
This one looks very similar to Ractive

[http://www.ractivejs.org/](http://www.ractivejs.org/)

Which isn't a bad thing :).

~~~
mercer
Could someone tell me a bit about how the two differ? I've built a decently-
sized app with Ractive.js and really like it, and I might be working on an app
soon where either Ractive.js or Vue.js seem like a good option.

From what I've gathered so far, Vue seems like it is basically a better
Ractive, and it makes more sense to use it for my next project. But perhaps
I'm missing some important differences between the two?

~~~
nailer
Ractive uses mustache templates, which I prefer as

\- nearly every web developer already knows mustache

\- mustache distinguishes what's HTML and what's not

I also like ractive because it has two way bindings, and promises for when DOM
changes, but maybe Vue also has those.

~~~
mercer
From what I gather it's quite possible to use mustache for Vue as well, and it
also does two-way binding. I'm mostly interested in the differences between
the two.

That said, the reason I used Ractive in an earlier project instead of React is
exactly what you point out. Mustache is much easier for other developers to
start using.

------
piotrkaminski
I'd love to see a comparison of Vue.js with Aurelia
([http://aurelia.io/](http://aurelia.io/)). In my mind, Vue.js and Aurelia are
the two front-runners for the next "right-weight" framework (whereas React is
the lightweight champion, and Angular 2 likely to be the heavyweight winner by
default).

~~~
fuzionmonkey
React 0.14 is 132KB minified [1].

I wouldn't exactly consider React "lightweight," especially compared to other
frameworks like Mercury [2], Mithril [3], and Riot [4], which are a fraction
of the size of React but still have their own virtual DOM implementations.

[1] [https://fb.me/react-0.14.0.min.js](https://fb.me/react-0.14.0.min.js)

[2] [https://github.com/Raynos/mercury](https://github.com/Raynos/mercury)

[3] [http://mithril.js.org](http://mithril.js.org)

[4] [http://riotjs.com/](http://riotjs.com/)

~~~
k__
Is there any statement from the React team about the size?

~~~
grayrest
I don't have a reference for this, but when it's come up in the past they've
said size is not a primary goal for the project. A lot of the size comes from
their internal event system that normalizes events cross-browser along with
the extra abstraction for pluggable renderers (i.e. support React Native) and
the component-local state handling. None of these are necessary to get the
virutal dom model working. Finally, 132k minified is 40k after gzip. It's not
THAT large but it's not a lightweight framework either.

------
ausjke
how is this compared to mithril?
[https://lhorie.github.io/mithril/](https://lhorie.github.io/mithril/) ,
trying to find a front-end js framework/library these days for an embedded
product (use browser to configure it), angular seems a bit heavy for me, have
not learned react yet.

~~~
cheapsteak
That's a neat idea

What OS and browser will it run?

~~~
girvo
Mithril runs in IE8+, currently, though that will be changing in the future.

~~~
lhorie
Huh, where did you hear that? I wasn't planning on dropping support for IE8 in
Mithril, if possible.

~~~
girvo
Oh apologies, I read in the Bucket List that it was happening but I just
checked and it's only mooted at this point!

[https://github.com/lhorie/mithril.js/issues/802](https://github.com/lhorie/mithril.js/issues/802)

------
djyde
I'd used Vue from it 0.11.x to 1.0.0, not only in my personal project, but
also in my company producton.

Vue.js was impressed me when I first visited it offical guid and document
site. I did not believe it made by a Chinese developer( no offense :P ).

Lots of people like to have a comparison between Vue.js and other
framework/library. I need to say after using Vue.js, I 'd never use Angular
again. Using Angular is painful for me, it has too many opinionated solution.
That make me difficult to use my own toolchain.

Everyone said that there are too little components for Vue. It's right, so I
begin to do something. I created a vue-component organization. I'll make more
and more Vue component. At the same time, requesting a component you want to
be achieved is welcome: [https://github.com/vue-
component/request](https://github.com/vue-component/request)

------
taylorzane
So glad to see this hit 1.0. VueJS has, by far, exceeded my expectations in a
JS framework. Certainly faster, and lighter, than any other framework that I
could find. Great job Evan!

------
systemz
If anyone want to see Vue.js 0.12 real world app as example, you can look at
my projects:
[https://github.com/aimpanel/frontend](https://github.com/aimpanel/frontend)
[https://github.com/lvlup-pro/labtech](https://github.com/lvlup-pro/labtech)

------
tasnimreza
Can someone make it clear how two way data binding works here ? I didn't get
it :(

------
wampler
I am about to start a project in Vue and I am so glad 1.0 is out

------
oldboyFX
I loved Vue.js from the first day I saw it a couple of months ago. Congratz on
1.0.0 :-)

------
teen
how does it track data changes without an angular-style digest cycle?

~~~
cheapsteak
I think it makes use of ES5.1 getters and setters (hence no IE8 support, if
that's a thing you care about)

------
yutingzhao1991
nice!`

