I feel like the design is heavily influenced by Angular (which is good, since Angular makes many good decisions). Is the intention of Vue to be a lighter-weight alternative? Are there features and design decisions that Vue makes differently? (E.g. the model concept seems simpler in Vue)
The biggest technical difference is probably the model observation mechanism - Vue.js observes model objects by converting their properties into ES5 getter/setters and make them implicitly emit events instead of dirty checking.
Design decision wise, it's mostly about simplicity, so no dependency injection, no pre-compiling jsx, no $digest/$apply, no services/factories etc... it's mostly up to you how to structure your app.
It also does not include routing/ajax/REST resource parts and focuses on the interface only. It is designed to be module ecosystem friendly (e.g. Component/Browserify) so you can easily leverage other libraries to fill in the missing pieces.
It became obvious how influenced by Angular it is through the use of its terminology in the source code.
I think it would be a cool idea to take pieces of Angular and try to create a custom framework, although it's probably worth waiting until Angular 2.0 before an effort is made to do that, when Angular becomes more modular.
Since first toying with Ember early on, I've decided that a good test of many of these MVVM libraries is to see how we can easily share data across multiple views.
I'm not entirely sure how that would work Vue.js. I suppose at some point you could have
var parent = new Vue(options);
parent.$data = [object,object,object];
var child = new Vue(options);
child.$data = parent.$data[i];
seems simple enough, what's your scratch test before trying a new library?
$data has to be an object, but yes you can share data between multiple ViewModels simply by assigning them. Note however this won't create nested scope between the two. To allow the child to get full access to the parent's data you need to compose them with v-component.
Vue.js removes all the directives during compilation, so your compiled markup would be completely clean. If you are still worried, you can change the prefix using `Vue.config({prefix: 'data-v'})`.
This could be a bit easier to integrate into existing pages. With KO it's possible to scope it to one element, but I experienced some troubles when I tried to ko.applyBindings dynamically in a multiple places on the page independently.
It would be great if I could use this as a library, even more light-weight in terms of API than KO and to extend already existing app.
After reading the documentation, I have to say this seems to be a nice medium b/w angular and knockout. I love how the api is really small and you just use plain js objects just like in knockout.js.
It makes heavy use of Object.defineProperty to achieve the plain object syntax instead of dirty checking. Unfortunately in IE8 Object.defineProperty only works on DOM objects and there's no way to shim it for plain JavaScript objects.
Every time I see a project that says "requires jQuery" I read it as "I don't know how to write forEach without typing a dollar sign". Why do I need a selector engine included if I'm already using something like Dojo?
I feel like the design is heavily influenced by Angular (which is good, since Angular makes many good decisions). Is the intention of Vue to be a lighter-weight alternative? Are there features and design decisions that Vue makes differently? (E.g. the model concept seems simpler in Vue)
The biggest technical difference is probably the model observation mechanism - Vue.js observes model objects by converting their properties into ES5 getter/setters and make them implicitly emit events instead of dirty checking.
Design decision wise, it's mostly about simplicity, so no dependency injection, no pre-compiling jsx, no $digest/$apply, no services/factories etc... it's mostly up to you how to structure your app.
It also does not include routing/ajax/REST resource parts and focuses on the interface only. It is designed to be module ecosystem friendly (e.g. Component/Browserify) so you can easily leverage other libraries to fill in the missing pieces.
Indeed, you would be correct: http://vuejs.org/guide/index.html
It became obvious how influenced by Angular it is through the use of its terminology in the source code.
I think it would be a cool idea to take pieces of Angular and try to create a custom framework, although it's probably worth waiting until Angular 2.0 before an effort is made to do that, when Angular becomes more modular.
Since first toying with Ember early on, I've decided that a good test of many of these MVVM libraries is to see how we can easily share data across multiple views.
I'm not entirely sure how that would work Vue.js. I suppose at some point you could have
var parent = new Vue(options); parent.$data = [object,object,object];
var child = new Vue(options); child.$data = parent.$data[i];
seems simple enough, what's your scratch test before trying a new library?
$data has to be an object, but yes you can share data between multiple ViewModels simply by assigning them. Note however this won't create nested scope between the two. To allow the child to get full access to the parent's data you need to compose them with v-component.
also look at http://vuejs.org/guide/composition.html
Is the use of of custom attributes a good practice? (example: <div v-text="message"></div>)?
I thought the data-* attributes were the recommended way (https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Usin...).
Vue.js removes all the directives during compilation, so your compiled markup would be completely clean. If you are still worried, you can change the prefix using `Vue.config({prefix: 'data-v'})`.
I believe Angular supports older versions of IE by utilizing their attributes through data.
Great performance. Would sacrifice some code clarity and readability to get theses numbers (http://vuejs.org/perf/).
My only concern with all these new libraries is how long they will be around.
Looking at those performance tests makes me wonder why knockout isn't more popular.
This could be a bit easier to integrate into existing pages. With KO it's possible to scope it to one element, but I experienced some troubles when I tried to ko.applyBindings dynamically in a multiple places on the page independently.
It would be great if I could use this as a library, even more light-weight in terms of API than KO and to extend already existing app.
After reading the documentation, I have to say this seems to be a nice medium b/w angular and knockout. I love how the api is really small and you just use plain js objects just like in knockout.js.
I put the quick example in getting started section into jsfiddle (loading vue.js.min). The completed tasks are not strike through...any idea?
Because the strike through is applied with a CSS class (done).
ok i put
in css part of jsfiddler, it's working as intended now.
I do very little frontend development but I really like this. Seems much more lightweight than angular or ember but similarly powerful.
What would it take to add IE8 support?
It makes heavy use of Object.defineProperty to achieve the plain object syntax instead of dirty checking. Unfortunately in IE8 Object.defineProperty only works on DOM objects and there's no way to shim it for plain JavaScript objects.
Why would a new JS framework bother to support a browser that's 3 major revs out of date?
Edit: Possibly you are being sarcastic....
No not sarcastic. Just wondering.
1 reply →
Every time I see a project declare "NO DEPENDENCIES!" I read it as "NOW WITH MOAR REINVENTED WHEELS!". Yup.
Every time I see a project that says "requires jQuery" I read it as "I don't know how to write forEach without typing a dollar sign". Why do I need a selector engine included if I'm already using something like Dojo?
A little short-sighted.
Remember back when Prototype was the dependency, and jQuery was young?
— or they've been stripped, and you can pick and choose between your own preferred dependencies, which some of us do prefer.
I wrote front and backend of a JIT/AOT compiler.
HOLYC: http://www.templeos.org/Wb/Doc/HolyC.html
20,000 LOC Compiler: http://www.templeos.org/Wb/Compiler