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/

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

See http://vuejs.org/guide/application.html#Single_File_Componen.... While it is certainly not JSX, Evan has written a Webpack loader, Browserify transform, and even a Sublime syntax highlighter to let you write JS, CSS, and HTML for a component in a single file.

I personally like this approach as it lets me mix and match my favorite languages (Coffeescript, SASS, etc), and it makes plugging Vue into existing code a straightforward process.

Just yesterday I was looking for a solution to mix HTML, *Script and CSS preprocessors in one single file. So happy I found this project! There's hope.

Having to call `setState` kinda becomes a big deal when you want to separate state manipulation and make your components dumb. Both dirty checking and Virtual DOM are pull-based mechanisms - i.e. nothing happens when the state itself changes, you have to give the system a signal to pull and apply. This means when manipulating externalized state you need to hold a reference to all the components that are interested in it, or do it by registering events - which is why the original Flux is unnecessarily complex. It becomes less awkward when you have a single state atom, and that's why Redux is an improvement over vanilla Flux.

After using React with Redux i can't even go back to plain Flux stores.

I'm not disagreeing, but when I hear "..., but React has taken us into the future." - is it just me or does this sound a bit too pompous?

It would be neat if Facebook had implemented JSX as a framework-independent transform rather than a React-only one, that way other frameworks could use the pretty XMLish syntax rather than strings or JS objects.

It has: https://facebook.github.io/jsx/

Emphasis on "implemented" haha. At least this makes it more open since someone can come in and make their own implementation. As it currently stands I don't think you can use Facebook's implementation to transform JSX to a framework-agnostic object.

You can use babel. Look at the custom example here: http://babeljs.io/docs/advanced/transformers/other/react/

Well, you could fork it:

https://github.com/insin/msx

There are alternatives though, like JSX implemented in sweet.js: http://jlongster.com/Compiling-JSX-with-Sweet.js-using-Readt...

There are babel transforms for it: https://github.com/openjsx In fact I've seen a user use JSX-to-HTML for his Vue templates.

Evan:

I'd love to know your response to lemevi here. In particular, what you consider the strengths and weaknesses to be in both your approaches, and why you prefer yours.

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.

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.

I'm a fan of HAML / Slim / Jade too. You might want to check out React w/ CoffeeScript as it gets you pretty close (and has some benefits).

It's not as pretty, but still better than JSX imo. I posted some examples here: http://rapin.com/blog/2015/02/03/reactjs-with-coffeescript/

Funny thing is, I switch away from React if I have much DOM manipulation and only use it for the "normal" stuff, like forms.

I actually don't understand how vue is different from react since the data flows the same way (besides different syntax and less jsx sugar, but preprocessable templates). More details on this from the author would be nice ! :) Good job anyway !

Also Laracasts has a great series on VueJS - mentioning it since it got me excited about VueJS and front-end JS frameworks in general.

https://laracasts.com/series/learning-vuejs

I think Jeffrey Way does a pretty great job of explaining things with Vue (among many other things); I think its also really great of him to put most of that series up for free.

Jeffrey Way is the best! really!

Excellent blog post to introduce the vue.js concepts (http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/). I was able to get up and running pretty quickly with a good understanding of the tool. Thank you for putting this together.

Nice work!

Please tell me the meaning of `Evangelion`... Is the japanese anime?

Yes, the releases are anime themed.

Very cool, Evan. Scoped style tags are a very cool feature. Could I ask you to describe how you implemented this, how you made it work?

Great work!

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 . Of course it's in support of Vue, but it was an interesting read.

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

VueJS is great. I am impressed with the amount of work that Evan put into this release in the last couple of weeks. One RC after another. Thanks Evan.

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!

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

And here are all the codepen exercise books

http://codepen.io/collection/zvnFi/

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?

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.

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

It sounds like the sort of mistake newbie React developers make, you quickly learn to decompose your render into smaller components.

It is a trade off. It is easy to implement any logic with React. Simple databinding works well until you need that logic.

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?

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

"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?

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

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

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.

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

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

---

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

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

Apologies for the formatting, I forgot about the rather greedy behaviour of italics on HN!

The `@click` and `:class` are in fact shorthands for `v-on:click` and `v-bind:class`. All directives start with `v-` by default. Shorthands are provided because these are two most often used directives.

Re moving away from JS classes: ES2015 class is inadequate due to the lack of static property initializers, and I don't want to force users to use stage 0 transforms. A Vue component definition is essentially an object of options, which is in fact easier than having to extend a base class. Also see https://medium.com/@dan_abramov/how-to-use-classes-and-sleep...

For the template, that's just because it's a one-pager demo and I don't want to use an inline string template. The proper experience is using single file Vue components: http://vuejs.org/guide/application.html#Single_File_Componen...

`replace: true` is a legacy option I forgot to remove in the demo :P

If I read the documentation correctly, you can also pass it a string to be used as template. If the string starts with a '#' it will act as a querySelector.

http://vuejs.org/api/#template

I love this feature. Putting html fragments in string literals in javascript seems pretty awkward to me.

What you are referring to is just syntactic sugar. @click is the same as v-on:click and :class is the same as v-bind:class. So you can write this line "less alien" like this:

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

> I have to compare all Javascript frameworks to React, because to me React feels like the first framework that got it "right."

Have you looked at riot.js?

[r] http://riotjs.com/

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.

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.

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.

This one looks very similar to Ractive

http://www.ractivejs.org/

Which isn't a bad thing :).

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?

I've wondered the same, as I really like Ractive. Briefly what I found is:

Vue seems using "magic mode" vs the Ractive.get/Ractive.set. Ractive uses virtual DOM, Vue does not.

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.

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.

I'd love to see a comparison of Vue.js with Aurelia (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).

I agree with you about React being the lightweight (perhaps even overall) champion - although there's undoubtedly some confirmation bias going on on my behalf (e.g. most of the JS people I follow on Twitter are React fans, so I mostly read about React).

I think the combination of simple API, good performance, big company backing (proven at scale), rich dev ecosystem (e.g. good dev tools, related ideas such as Flux/Redux) and, of course, React Native is going to be hard to beat. As a freelance developer, it's the front end framework I've chosen to go "all in" with for this round - but still it's great to see all the innovation going on in this space (once you get over the fear that your skills will be outdated in six months time that is!)

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

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

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

[4] http://riotjs.com/

People usually compare the 'size over the wire', eg. gzipped size. In these terms:

- React 0.14 is 55kb

- jQuery 1.11 is 38kb

- Backbone + Underscore (dependency) are 15kb

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

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.

I'd also like to see this comparison. Last year I came close to using React, but picked Knockout because React was fairly immature at the time. I'd like something a bit more "right-weight" and am interested to see what Aurelia's author has done (he made a larger framework based on Knockout). I really like that Aurelia is embracing upcoming standards like web components, and it looks like Vue is also doing the same. Aurelia also seems to be designed with TypeScript in mind, which is a big draw for me as sometimes some common Javascript patterns are awkward to deal with in TS.

Also, by "right-weight" I think this is meant in terms of API and features, not file size. Sorry, but I don't think that bringing up the file size of various other frameworks is that productive of an addition to this thread.

Vue's got a much longer track record, correct? Aurelia was only recently spawned (at least it feels like yesterday), and they still do not have a production release out.

Also, I would crown knockout the light-weight champion (both in function, and concept), and ember the heavy-weight champion

Rivets[1] is an even lighter light-weight champion.

[1] http://rivetsjs.com/

Wow, thanks for posting this! At first I tried to find reasons why knockout was still the light-weight champion, but ended up taking a look through Rivet's usage and info, it looks pretty amazing, and crazy lightweight.

Only thing missing is a capable router, and I think you'd be off to the races with this thing, awesome.

You're right, Vue's been around longer, but Aurelia's release appears to be just around the corner and they have a team behind it, so I'd call it even. I'm mostly interested a comparison of the technical approaches since I think it's too early as yet to properly assess their communities.

While I don't have any experience with Vuze, I do have high hopes for Aurelia. I've worked with the beta versions, and found the API to be pretty workable/clean.

I personally like the background of the main dev(s?) behind Aurelia. IIRC, they worked on knockout->durandal->angular->aurelia, and I think the apps they stopped-by in before conceiving Aurelia have just the right concepts and features to make for a really compelling large-ish framework.

A little dissapointed about how hard it is to bootstrap it though, I really like to start projects from scratch (empty folder), and found it a little difficult to just pull together easily (without downloading their starter-zip or whatever).

how is this compared to 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.

I'm still using Mithril quite extensively, really worth it for the projects I've used it for. Felt like React without all the extra features (slimmed down).

That's a neat idea

What OS and browser will it run?

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

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

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

I meant what browser will the embedded system run?

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

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!

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/lvlup-pro/labtech

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

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

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

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

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

nice!`