The State of Vue
medium.com
medium.com
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.
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 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.
reminds me of https://xkcd.com/1102/
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.
Code can be great documentation if you already understand how to get there. Sometimes maps are better for people new to the tech.
An example: https://cdn.rawgit.com/krausest/js-framework-benchmark/956b0...
While i might say that riot's speed won't be an issue in 80℅ cases, what about the 20% cases? And its not like difference in speed is small.
As the benchmark(i linked in first post) shows, riot is very slow compared to the competition.
On the other hand, vue (especially vue 2) is among the fastest.
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.
BTW GitLab looked for a long time at what framework to use and we're happy after switching to Vue
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.
Please take note @angular team.
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.
Or are you suggesting that people are giving for some other reason than they benefit from the work?
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.
The MIT license is the permission.
http://programmers.stackexchange.com/questions/253925/how-to...
> 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'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]: https://github.com/facebookincubator/create-react-app [2]: https://github.com/vuejs/vue-cli [3]: https://vuejs.org/guide/reactivity.html [4]: https://vuejs.org/guide/application.html#Single-File-Compone... [5]: https://www.patreon.com/evanyou
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.
>Template syntax wise it's mostly subjective preference: Ractive uses mustache templates, Vue uses attribute bindings.
>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.
[1](http://forum.vuejs.org/topic/849/differences-between-vue-and...)