Vue has a lot of great ideas. I originally found it to have just enough power over Backbone, without the heft of Angular. Despite a great premise, my time with Vue was turbulent.
Vue version updates are tremendous time sinks. API thrashing was common from the original 0.x.x releases to 1.0.0
This was justified as all versions under 1.0.0 being "under development". That's fine, but call it what is, "non-production-ready software". A public beta that should have a prominent disclaimer.
The removal of the built in event system was also handled poorly. There was no migration path other than build-your-own shim using the Vue constructor.
My beef with Vue these days is the growing Vue-specific tooling. I'm not fond of the single file .vue approach as it doesn't make it easy to separate components into different contexts.
The standard rebuttal for this complaint is "but JavaScript, CSS, and templates are the same context." I agree that the approach of scoping CSS and template to a component is great. Not being able to use separate files leads to a lot of noise. I don't need to see the CSS when I'm working on the component JavaScript. The best solution I've had in the meantime is using my editor's "block folding" feature.
Combine this with a .vue specific syntax highlighting, and a .vue eslint configuration.
It's really not what I signed up for in the beginning. I sense I'm coming off as entitled. Evan's countless hours of work is commendable and I'm grateful for his vision.
I hope Vue will find that illusive balance of configuration and opinion in its lifetime.
> Vue version updates are tremendous time sinks. API thrashing was common from the original 0.x.x releases to 1.0.0
I didn't have to endure this, although pre-1.0 API breakage goes with the territory (of pre-1.0 software...).
The 2.0 API changes look pretty sane (https://github.com/vuejs/vue/issues/2873); once it is official and the vue-cli webpack template is updated, it looks like only a little work to upgrade. Vue's documentation (in the present) is really good, and was a motivating factor for me choosing it over React.
I didn't get in to Vue until 1.0, after I hopped into a project that had it. Being a backend guy first, I bristled at having to get my head around Vue to make fixes to this project- it was a mere half a day later that I felt quite comfortable with Vue and the different hierarchies, events, and propagations. Maybe because I walked into a half decent already written project or because I have experience with Angular, React, and Backbone I was almost there already on Vue.
It's to the point that I pretty much have started my last dozen projects with Vue, whereas it would've just been HTML5 + whatever as I needed and it would've been a hodgepodge.
I had been trying Vue for a couple weeks, with at least two different approaches to file organization (first setting up bash scripts to build release and dev channels, later switching to minifying and compiling using gulp with things like Closure) before I discovered vue-cli and its webpack template.
Cool. Vue is such a godsend in the ever more complicated world of Javascript frameworks. It combines the simplicity of jQuery with the power of Angular. The documentation is excellent as well. I hope Evan can keep up the good work for a long time!
I really like Vue and wouldn't want to use anything else right now. it feels much more natural to use for me than for example React. it is however quite a struggle when first using vuex for storing. I haven't looked into 2.0 much yet but vuex is said to get easier to use then. keep up the good work!
If you guys liked vue, you will absolutely love riot.js. It's so simple and minimal that I only had to look at their docs for a couple minutes and I was on my way. In this day and age where client side frameworks are overly obese , riot was afresh air. I like it more than any other frameworks out there.
I switched from Riot to Vue, and am glad I made the change.
Biggest things I noticed:
1) Getting stared with the basics is about equally easy in both frameworks. Both have a very simple and clean API and component system.
2) Vue has more advanced features -- dynamic components, easy two-way binding, watching variables, custom events, routing, etc, all of which I have used at some point as my app has gotten bigger
3) Riot seems to have more open bugs, including one major issue where even when an "if" statement evaluates as false in a template, the component still gets processed. This is supposed to be fixed in the next big release, but who knows when that will be.
4) Vue seems to be much more active -- more users, more commits, so I think it is a better long term bet.
Really? I couldn't even figure out how to get started with Riot. Vue's Guide walks you step-by-step from scratch how to get up and running. It also has a section on how to structure larger apps once you understand the basics. Riot's Guide is a topic overview. I had to find tutorials outside the main site.
I think it's fast, fast enough to not have to worry about. OTOH, Angular with it's 2-way bindings gave me ton of performance problems in the past, so if anything, I would say that 1-way binding frameworks (riot/react) will be much more performant on a real world project.
The way Angular 1 and Vue.js 1 implement 2-way binding is very different (dirty checking vs getters-setters), which is why Vue.js 1 implementation doesn't have performance issues.
I'd say that if Vue.js is like Rails, then Riot.js is like Sinatra. It's an even more simplified version. For one, Riot doesn't include 2-way binding, which is how I like it, since I like having more control over the DOM of when and how to update it. Also the syntaxes are cleaner and less verbose. I also appreciate it's style of creating and mounting components.
Vue.js 2 doesn't include 2-way binding. As for syntax, I don't see what you're seeing by looking at the docs. And in Vue you can also create and mount components.
EDIT: I realized after posting this comment that 2-way binding has only partially gone away, v-model still works, it was prop syncing that was deprecated.
Me too. It is awesome people ensure he can get $8k per month to work on Vue. We tried donations with GitLab years ago and the highest we got was $1200, but this was a one time think. I think the Patreon model of 'subscribing' to sponsor is really fitting.
I do think that it is easier to get a handful of people funded with this model than a large group. GitLab Inc. now has 25 developers working 80% of their time on open source. Getting 20 people funded with Patreon seems like a stretch.
Worth noting that most of the money comes from big donors. In Vue's case, there are 79 donors, but 9 donate $500/mo, and 1 donates $2000/mo. (and those are essentially ad placements)
I love VueJS. I found it very easy, specially when you aren't building a SPA, but want something more powerful than jQuery without being overkill like React.
"Patreon Campaign Going Strong
The Vue.js patreon campign now has over $8,000 monthly pledge from the community and sponsors."
It's only a bit tongue in cheek to say this is a shining example of socialism. The biggest, and collosal difference is that now it's voluntary, and it's awesome.
I'm not sure I understand how... people are paying for something that they use (or otherwise benefit from) and the producers are asking for that payment and reap the benefit: it's a trade, a win-win transaction. To me this sounds much closer to capitalism than socialism where the exchange requires no such win-win proposition for the parties directly involved. That such voluntary payment is voluntary, again, is closer to capitalism where transactions are entered into voluntarily by the parties which is a fundamental feature of capitalism and not socialism. Just because the producer is accepting that payment is not required doesn't mean that it's socialism (the false alternative)... they are after all asking for compensation albeit on a voluntary basis.
Or are you suggesting that people are giving for some other reason than they benefit from the work?
But one could say that he does not own the "means of production" but instead it is owned by community, which has democratic control (for example a fork might become more popular). I'd say that is a trait of socialism and perhaps anti-capitalist.
No. "Copyright (c) 2013-2016 Evan You" ... he clearly owns the product or at least makes claim to do so. Such a claim of ownership, and likely valid claim at that, immediately refutes your position. While others are entitled to create derivative works, it is only by the good graces of the property holder.
But more importantly, there is a fallacy that the material goods or machinery that are used in the creation of a product (the "means of production") are somehow responsible for that product coming to be. That's nonsense. It was nonsense in the industrial era and it's even more apparently nonsense in software development. Sure, factories were hard come by back in the day, but having a factory didn't mean you'd be successful: you had to think and if anything is an individual endeavor, it's thinking. Now that the means of production can simply be owning a computer... something open to a wide variety of people of all backgrounds... one sees the relative individual contributions to success or failure more dramatically.
As for someone going off and, with the owner's permission, forking the project: they will only be more successful due to the individual contributions of those making the fork. Some vague abstract notion of "community" will not suffice.
You do need the owner's permission to fork the project. The owner has granted that permission in advance by distributing it under the MIT license, provided you agree to terms of that license as imposed by the owner. That you do not need express written consent doesn't change the fact that you can only use the code by permission of the copyright holder. Note that the permission to use/modify the software is not unconditional. If you fork it, you cannot change the license terms, the owner hasn't granted anyone permission to change the terms of his license for his property and the license itself is explicit on this point.
Really, the first line of the license starts, "Permission is hereby granted...," and ends with, "...subject to the following conditions:,". Don't agree to that stuff and you don't have permission from the owner and you can't use the software.
> That you do not need express written consent doesn't change the fact that you can only use the code by permission of the copyright holder.
Which is granted by the MIT license.
> If you fork it, you cannot change the license terms, the owner hasn't granted anyone permission to change the terms of his license for his property and the license itself is explicit on this point.
No one's suggesting changing the license terms. You must retain attribution, as required by the MIT license. A fork would need to carry the required attribution to Evan You.
The OSI's definition of Open Source includes "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."
I picked up Vue a couple of weeks ago for a small dashboard project where client-side makes total sense: consuming JSON from HTTP APIs. I'd previously played with Ember (good, but not using Ember Data feels punishing), looked at Riot (neat, but very small community), and of course React.
I'd dabbled with React before, but there's a huge gap between 'dabbling' and 'building something reasonably production-worthy'. Webpack (and its contemporaries) are neither accessible nor straightforward to modify, and create-react-app[1] is still maturing.
Vue's fantastic documentation[3], ready-made project templates[2], well-sized community, sane-looking 2.0 API changes, and lifecycle methods that are similar to React (but a little less verbose) were all pluses for me. Making HTTP calls, populating a simple central store and passing that down to components was easy, and for a less-often-a-frontend-dev like me, writing Handlebars templates with helpers for looping, binding form inputs to state (v-model), and adding classes to CSS based on helper methods (e.g. :readonly="isReadOnly(key)") was easy to pick up.
I can see the advantages of React's JSX approach (limiting template-logic, as templates don't exist), although Vue 2.0 will have JSX support as well.
Like with most tools, your decision is part-requirements and part-subjective ("I'm familiar with X, Y & Z approaches"), but Vue made sense and I'd definitely build something else with it again. That Evan has such a huge amount of support on Patreon[5] is impressive as well.
I hope Dan Abramov can keep create-react-app focused: there are an incredible amount of feature-requests, and if create-react-app grows flags to accomodate even half of them, it'll be a monster. Thus far the dam seems to be holding!
1 million+ downloads on NPM at 125k~150k per month
But doesn't Node download from NPM every time it runs? Hence the left-pad debacle. So this "downloads" figure doesn't necessarily mean what someone used to a more conventional language might think it means.
With CI for running tests and building docker images, I have seen a lot of places where npm install happens everytime. So don't know why you are getting down voted.
>Vue has a more intricate reactivity system - plain Objects made reactive, and can be externalized and managed elsewhere if necessary.
>Vue has more support libs/tooling (vue-router, vueify, vue-loader etc.)
>I actually know Rich who is the author of Ractive. AFAIK he's not that actively maintaining Ractive now (just look at the issue count) and is focusing on some other projects.
-Evan You(Author of Vue) [1]
But, that's 8 months ago. As of now, Vue has gone way high up in terms of popularity and features.
Vue version updates are tremendous time sinks. API thrashing was common from the original 0.x.x releases to 1.0.0
This was justified as all versions under 1.0.0 being "under development". That's fine, but call it what is, "non-production-ready software". A public beta that should have a prominent disclaimer.
The removal of the built in event system was also handled poorly. There was no migration path other than build-your-own shim using the Vue constructor.
My beef with Vue these days is the growing Vue-specific tooling. I'm not fond of the single file .vue approach as it doesn't make it easy to separate components into different contexts.
The standard rebuttal for this complaint is "but JavaScript, CSS, and templates are the same context." I agree that the approach of scoping CSS and template to a component is great. Not being able to use separate files leads to a lot of noise. I don't need to see the CSS when I'm working on the component JavaScript. The best solution I've had in the meantime is using my editor's "block folding" feature.
Combine this with a .vue specific syntax highlighting, and a .vue eslint configuration.
It's really not what I signed up for in the beginning. I sense I'm coming off as entitled. Evan's countless hours of work is commendable and I'm grateful for his vision.
I hope Vue will find that illusive balance of configuration and opinion in its lifetime.