
The State of Vue - dsego
https://medium.com/the-vue-point/the-state-of-vue-1655e10a340a#.sygdkj502
======
throwaway284534
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.

~~~
elithrar
> 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);](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.

------
huskyr
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!

------
rukenshia
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!

------
merb
> fastest growing libraries in the past few months

reminds me of [https://xkcd.com/1102/](https://xkcd.com/1102/)

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

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

~~~
jaequery
What got me started in a jiffy was just looking at their live demo,
[http://riotjs.com/play/](http://riotjs.com/play/). Sometimes code is it's
best documentation.

~~~
yawn
I don't think that link points to what you intended: it links to a simple html
file with a blank script file.

Code can be great documentation if you already understand how to get there.
Sometimes maps are better for people new to the tech.

------
rawnlq
I really hope the patreon model catches on with open source.

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

~~~
bdcravens
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)

------
locusm
Evan gave a recent talk at Laracon about Vue.js
[https://streamacon.com/video/laracon-us/evan-you-vuejs-
works...](https://streamacon.com/video/laracon-us/evan-you-vuejs-workshop)

------
Kezako
"2.0 is now in RC [...] From this stage on we will be in API freeze and there
will be no more breaking changes before official release"

Please take note @angular team.

------
ahacker15
Here the changelog:
[https://github.com/vuejs/vue/issues/2873](https://github.com/vuejs/vue/issues/2873)

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.

------
ivoras
I find this fascinating:

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

~~~
sbuttgereit
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?

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

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

~~~
ceejayoz
You don't need the owner's permission to fork it. It's MIT licensed.

[https://github.com/vuejs/vue/blob/dev/LICENSE](https://github.com/vuejs/vue/blob/dev/LICENSE)

~~~
sbuttgereit
Oh come on guys... think a bit... just a little.

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.

~~~
ceejayoz
> You do need the owner's permission to fork the project.

The MIT license is the permission.

[http://programmers.stackexchange.com/questions/253925/how-
to...](http://programmers.stackexchange.com/questions/253925/how-to-avoid-
being-forked-into-oblivion-by-a-more-powerful-contributor)

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

------
elithrar
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]: [https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app) [2]:
[https://github.com/vuejs/vue-cli](https://github.com/vuejs/vue-cli) [3]:
[https://vuejs.org/guide/reactivity.html](https://vuejs.org/guide/reactivity.html)
[4]: [https://vuejs.org/guide/application.html#Single-File-
Compone...](https://vuejs.org/guide/application.html#Single-File-Components)
[5]: [https://www.patreon.com/evanyou](https://www.patreon.com/evanyou)

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

~~~
throwaway284534
NPM modules only download when explicitly fetched with `npm install`

~~~
ceejayoz
Which, if you're running CI, might be every time you push a build to it.

------
masterofmisc
Does anyone know how this compares to
[http://www.ractivejs.org](http://www.ractivejs.org) ? Ractive looks like a
simple no fluff framework

~~~
rk06
When I looked into it some months back, I arrived at following :

>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...](http://forum.vuejs.org/topic/849/differences-between-vue-and-
ractive/2))

~~~
masterofmisc
Thanks for your insight and reply.

