
Love letter to Vue - abalashov
http://www.evaristesys.com/blog/love-letter-to-vue/
======
mieseratte
Having used vanilla JS, jQuery, Backbone, AngularJS, React (with and without
Redux), and Vue (with and without Vuex) I really don't see eye to eye with the
folks who love Vue so much.

To me, it looks like Backbone, AngularJS, and React had an orgy and out came
Vue. The "opinionated" claim strikes me as marketing BS, templating vs. JSX,
attributes vs. components (assuming you're using their templating language),
etc. There really isn't a performance benefit over React. You're wading into a
new ecosystem without all the build-up React benefits from. The templating
language itself is yet another thing to learn, and frankly I just don't think
embedding control flow into the templates themselves is a sane approach.

The documentation folks love to talk about is alright, I've definitely seen
worse, but it is too much "Go do X" and not a lot of "Why we do X." The latter
is a particular strength of React, in my opinion, as they describe very well
the underlying logic behind why something is the way it is.

About the best argument for it is the batteries-included nature of the
projects, but even then I've not truly had _that_ much trouble upgrading
something like React Router such that it would make me question using it in
the future.

~~~
rpeden
I think it's okay that you don't see eye to eye with people who love Vue.

And I think it's also important to note that most of the things you point out
are matters of preference. I've seen Vue fans and React fans argue about these
things until they're blue in the face, when all it really boils down to is
that some people like the way Vue does things, and some people like the way
React does things.

Healthy debate is good. But the downside is that I've noticed these debates
devolving into what I call identity politics for programmers - instead of
seeing the other group as front-end developers who just like doing things
differently, I see people breaking the world down into two groups: people who
agree with them, and idiots. And I don't think this approach is very good for
us as a community.

So I don't mean to single you out here, but the author didn't really criticize
React in any way, so I don't think coming to the defense of React vs Vue here
really added to the conversation.

Why not just say, "hey, I prefer React, but it's good Vue exists for folks who
prefer a different approach.". Vue's existence isn't a threat to React. It's
okay to have multiple approaches to the same problem.

I prefer React too, but I don't think a front end framework monoculture is a
good thing so I hope that Vue, React, Aurelia, Ember, and others continue to
grow.

~~~
flabbergast
It's just annoying that when I look for a new front-end job I see more and
more Vue.. I really don't want to write all that markup, for me it feels like
a step back from React, so I skip those jobs. Maybe I'm just afraid for non
interesting technologies becoming a standard I have to concede to eventually.

~~~
bigtunacan
And on the flip-side; I can't stand React so I'm glad to see that Vue is
growing. I hate the JSX "everything is JavaScript" mentality where you shove
all of your HTML into a render function.

Vue's component separation of HTML/JavaScript/CSS just clicks better for me.

~~~
jimmy1
> I hate the JSX "everything is JavaScript" mentality

Would you object to things like unobtrusive javascript?

Things like unobtrusive javascript came to be because people recognized early
on that HTML was not enoug for writing applications -- that you needed
something more. Since basically the entire world has come to embrace
unobtrusive javascript, it isn't a logical leap to embrace JSX.

[https://medium.freecodecamp.org/react-s-jsx-the-other-
side-o...](https://medium.freecodecamp.org/react-s-jsx-the-other-side-of-the-
coin-2ace7ab62b98)

~~~
about_help
Some people don't appreciate being required to run arbitrary code just to view
an HTML page and the eye candy of JS is just not worth it.

Sure there are cases where JS is incredibly useful and beneficial, but your
website should be able to display the majority of content with JS disabled.

~~~
SiVal
Saying that "your website" should be able to "display" its "content" without
JS seems to assume (as so many do) that the web is fundamentally a collection
of articles (read them, look at the pictures, link to other articles) with a
few exceptions, and keeping it that way is every developer's responsibility.

That's not what it is anymore. It has evolved into a general, distributed
computing and communications platform. More and more uses of this platform
require doing things that involve customized behaviors, not just the built-in
features for displaying articles, so more and more people leave JS enabled.
Kids who couldn't have afforded a family PC and MS Office now have a
Chromebook at school (and maybe at home) and free Google Docs. And how many
people whose only internet access device is a phone turn JS off in their
phone?

I think it makes more sense now to treat the JS-disabled, article-browsing
case as the exception. If I were trying to distribute public health articles
as widely as possible, I would try to limit them to simple text, small photos,
no JS, nothing that wouldn't have worked 20 years ago. And even for less-
critical articles, if they were just simple articles, I'm still inclined to
leave out the JavaScript in most cases for the sake of simplicity,
reliability, reach, and archival robustness.

But for general purpose today, most developers in the developed world can
assume JS is going to be enabled by the market they want to target.

------
deweller
I learned React before I learned Vue. After I wrote an application in React, I
decided to try Vue for the next one. It was like a breath of fresh air. The
templating language is more intuitive to me and the lack of boilerplate makes
it great for the small projects I've used it for.

To each their own. But there is nothing I miss about React after switching to
Vue.

~~~
geist
I'm in the exact same boat. React never really felt comfortable for me, but
Vue clicked immediately. Admittedly, I'm coming from an AngularJS background.

~~~
k__
To me it was the other way around.

Vue felt like a subset of Ember. React did something completly new.

------
constantlm
After a few years in the Ember ecosystem, I started using Vue a few months ago
and damn it's amazing. Of course you can't compare the two at all. I've found
Vue and the structures it imposes on your application a bit easier to reason
about than what I've found with Ember. It could also very well be that having
learnt Ember, I picked up Vue very easily. Either way, I love Vue, and outside
of Ember I can't say I've loved any other front-end framework.

~~~
k__
Yes, Vue is basically the components of Ember, without the MVC stuff.

------
duhi88
Vue has all the stuff that made AngularJS so great, and none of the baggage.
I've made a few small to medium-sized projects with it, and I see no reason to
use Angular[JS] or React anymore. I love how well it plays with regular JS
modules, allowing you to share your HTTP code and service libraries across
multiple apps (Vue or React, or vanilla JS).

Vue hits a nice balance between opinionated code and flexibility. Throw in
their ESLint plugin and I think you will end up with very maintainable code.

------
tflanitzer
I find such euphoric praises of tech ridiculous. Especially when at the same
time its alternatives are declared unusable (or in this particular case
"obsolete" or a "trainwreck"). I have not used Vue yet and heard some good
things about it. But despite this lack of experience I'm confident to say it
is not the solution for everything and everyone.

------
diminish
I love Vue.

After Angular 1/2, React, Riot I ended up there. It conforms to my principle
of least surprise, and principle of least new ontologies. In the world of
transient JS world, it's the best thing that happened.

Hope every other front end framework disappears and the whole world settles on
Vue.

~~~
Fifer82
I actually don't use projects that aren't authored in TypeScript these days, I
am looking forward to their rewrite.

Any particular reason that you prefer Vue over Angular seeing as you have had
experience of both?

------
MattyRad
We've been using Vue in production since Vue 0.12. It was a joy to use way
back when, and it's only gotten better and better.

That's not to say that I haven't shot myself in the foot dozens of times in
the process though. We've had to solve a lot of pain points from our original
0.12 code (two-way binding, too many props in components, some jquery dotted
in, lots and lots of pre es6 code). But even sitting on code I wrote that
looking back makes me cringe, Vue is always enjoyable.

It has truly improved my daily quality of life and I owe Evan You a lot of
gratitude.

~~~
entropie
I started looking into Vue just because I looked cool and its good to learn
new stuff.

A few month later I got myself a smartwatch besides most of the work was
getting around the tizen framework I made my own watchface in Vue - and this
was/is a pure joy.
[http://wecoso.org/~mit/stuff/myClaw/](http://wecoso.org/~mit/stuff/myClaw/)

------
mockingbirdy
I'm using Vue for 2 years professionally. Before that, I've used Backbone and
Ember (back in the days those were the popular ones) and Angular and React.

React lacked crucial functionality and it felt like I had to rebuild basic
functions everytime e.g. a simple input field which communicates its value
through setState. In Vue, you just use v-model, but in React you have to add
an onchange handler which just feels very low-level - I just don't want to
operate on this low level, the framework is allowed to make assumptions e.g.
for checkboxes to make my life easier (i.e. grouping all checked inputs with
the same v-model name into an array). Another thing I don't like is that JSX
is not very good-looking e.g. if I want to add an "if", I need to use the
ternary operator in complex components. This is just a hacky way and not very
descriptive IMO.

And Angular was awful with its $scope and felt so dirty (it used dirty
checking, that's probably why). The new version is ok, but Vue has all the
same concepts but wrapped up in a nicer interface. I don't even understand
what the ng team tried to achieve with their difficult to read templating
language. Looks awful and feels complicated compared to Vue's simple
constructs (mainly v-model, v-for, v-if and v-show and v-on, v-bind and ref) -
you can learn to write Vue templates in 20 minutes.

The core concepts are reduced to their essentials and it really shines. React
is too basic IMO and Angular tried too much with all that controller, service,
... stuff. It was too complicated.

Vue is basically what Web components (using .vue files) should be: Small
modules with HTML, style and JS code. And a very nice API and a great
developer behind it (so it has all the nice things: vdom, custom rendering
e.g. for JSX support, a webpack loader, ...).

Overall, it's the greatest thing I've seen since Ember (and it's much better
and more flexible than that).

------
RpFLCL
I couldn't be more thrilled with vue.

Having learned with react, I think the component structure and updating are
wonderful. But the baggage of the React ecosystem made it tedious to add to
projects. What if I don't want to use webpack and npm and babel?

As this author notes, Vue just drops in and works.

I can use it in existing projects. I can use it in experiments. I can use it
with my PHP projects. I can use it without a server to compile anything.

It's been a pleasant experience and the tools I've built with it have been
refreshingly stable.

~~~
crooked-v
> What if I don't want to use webpack and npm and babel?

You may want to look at Parcel, which gets you most of the Babel/Webpack
benefits (minification, ES6 syntax, using image files as imports in JS, etc)
in a way that "just works".

    
    
        npm i --save-dev parcel-bundler
        npx parcel src/index.html    # where index.html has <script src="whatever.js"></script>
    

...and that's it, if you're not doing anything really weird.

~~~
woah
I’ve found parcel to be very buggy

------
mvolkmann
If you like templates and framework-specific syntax for conditional logic and
iteration sprinkled into your HTML then you will love Vue. If you prefer the
JSX approach and relying on JavaScript for conditional logic and iteration
then you will love React. Vue does support JSX, but it is not the idiomatic
way to use Vue.

~~~
boubiyeah
The other huge difference is how much React beneficiates from static typing
(typescript for instance) whereas just like angular, vue templates and all the
glue code cannot possibly benefit from it. A vue or angular app is almost as
typed checked as a JS app.

I feel most vue lovers don't care about static typing.

~~~
joshschreuder
Vue 3.x (future) is targeting first class Typescript support

[https://github.com/vuejs/roadmap/blob/master/README.md](https://github.com/vuejs/roadmap/blob/master/README.md)

------
vikingcaffiene
> Angular 2/4 is a completely over-engineered trainwreck.

I can appreciate that the author loves Vue.js but I don't think its very
constructive have such a binary view of something they clearly haven't spent
much time with. Angular is not "over-engineered". Its complete. Its got
everything you need and an established, well documented pattern to do it. Its
far from perfect but then what is? I've used it, React, Angular 1.x etc and
all of them have their strengths and weaknesses. It depends on your team and
what you are trying to do.

Its important to remember all these frameworks are built by people just like
us who try very hard to make them the best they can be. It would be nice if we
spent more time celebrating all the wonderful FREE tools they build for us
rather than tearing down the ones that we didn't pick.

~~~
paulddraper
I'm not in love with the way the MVC framework takes over and wraps the TS
compiler (and a very specific version of the TS compiler) to compile
templates. Seems an obvious layering violation.

I'll take composition over inheritance in my tooling.

~~~
vikingcaffiene
I suppose I'd need to know what specifically you've run up against to justify
your distaste for the approach. I too prefer composition but I'm not against
another way if it works.

~~~
paulddraper
It's a really bad architecture. Couple of examples

(1) The angular compiler doesn't have the same JS or CLI interface as the
TypeScript compiler. I have to know very specifically which I am using when;
my build tooling must always know whether it's compiling TS the Angular way,
or the vanilla way, and there isn't much commonality.

(2) What if I want to use an alternative TS compiler? Or someone writes a
faster one in Go? Or I want to use tsickle [1], which is Closure Compiler-
compatible?

Now it turns out there isn't a TS compiler in Go, and the Angular team are the
authors of tsickle, and so ngc happens to work with it. But it's an
architectural smell to couple that closely for my MVC framework (and IMO with
little necessity).

[1] [https://github.com/angular/tsickle](https://github.com/angular/tsickle)

------
wruza
Long-time desktop developer’s who didn’t touch react and even web fe/be until
last year opinion here.

While Vue is obviously a kick-starter to frontend programming that makes
templating easy and unix-y light, I still have few complaints. First, it is
not obvious or easy to start with components. Separate files, build ecosystem,
props handling, all this. What I want is to reference ‘that last place’ in
html and have a copy of that template right here that would capture props like
un-hygienic macros of C would do. Iow, my style of small apps doesn’t map well
to heavy isolated-component based style of thinking. I don’t want to wash my
hands every five minutes when I’m at home.

Second, vue forces you to be fully contained in .data and .methods. I would
like to bind to any data and function roots, including _window_ itself, but
it’s obviously a bad idea to pass window to vue vm for now. But still, it
would be nice to forget that vue exists at all at the source level and have
just a bunch of vars, functions and [3rd-party] modules at global level and
that’s it. Now I have to export methods to vue by hand and to have all the
state pre-defined, as if it wasn’t clear how my state is structured from
{{these expressions}} alone. I often find that something doesn’t show because
I forgot to init data.key = { k2: “” }.

Third, you cannot ‘chroot’ without making a component. Would be nice to write
something like <template v-with=‘client.contacts’> and then reference ‘phone’,
‘address’, etc without a prefix. With copy-style described above it would
replace the need for components for me for ages, even if I meet that need.

Still my jquery experiments can’t beat vue in simplicity, though I hope some
day I’ll get rid of vue too (due to points I listed, not because it’s bad).
But de wae still has to be found yet.

------
vinceguidry
After reading the comments, I must be the only person in the world who misses
good, old-fashioned Rails templates / views. With someone who knew the
internals well, they were a productivity gold mine.

~~~
meowface
That's still a valid way of doing development, but it doesn't really work for
a SPA. You may not want a SPA, but if you do, you pretty much need something
like Angular/React/Vue.

~~~
vinceguidry
It would still be a valid way of doing development, if teams weren't cargo
culting frameworks for tasks that really don't need them. I can't begin to
tell you just how annoying React is for making a CMS.

------
gravity_123
Huge fan of the framework and been using it for an year now. My biggest
complaint though is the speed at which things move. See for example this PR[1]
: it has been reviewed and approved since early January of this year. That's 7
months without it being merged.

1:[https://github.com/vuejs/vuex/pull/1121](https://github.com/vuejs/vuex/pull/1121)

------
krat0sprakhar
One thing I really like about Angular is Angular Material[0]. For me, it
solved the same problem Bootstrap first solved - get a decent looking & usable
app ready even if you suck at design. With the library of components[1], it's
super easy to prototype and build stuff with Angular. Is there an equivalent
of this in the Vue land?

[0] - [https://material.angular.io/](https://material.angular.io/)

[1] -
[https://material.angular.io/components/categories](https://material.angular.io/components/categories)

~~~
noir_lord
Vuetify possibly thought unlike material.angular.io it's not supported
directly by the framework creators.

Not sure if that's a negative or not.

~~~
Tade0
I spent a year working with Angular Material, currently I'm in a project that
uses Vue + Vuetify and to me Vuetify has much more to offer than Angular
Material.

~~~
noir_lord
Interesting, I mostly just use Bootstrap 4 (internal enterprise application so
the massive adoption and long release cycles help there).

~~~
abalashov
I tried doing Bootstrap 4 with Webpack and finally switched to UIkit about 30
milliseconds before committing seppuku.

~~~
smnplk
i love bulma css

------
zmmmmm
It is interesting how personal the Vue / React divide seems to be. Nobody on
either side seems to have very good objective reasons to use their preferred
framework, at least for greenfield development. In the end people mostly just
"like" one approach or the other - and this is for two frameworks that at a
high level share basically an identical design philosophy. I feel like this
must go to something very deep about how people think about software
development - what it is, what is important about how it is done, etc.

~~~
balfirevic
Isn't that kind of expected, since both frameworks are so similar? Only thing
that remains is what you like, or rather how you prefer your ideas to be
expressed in code. And it's great that there are two (or more) solid options.

What is weird to me is that lot of people seem to insist that there are major
(sometimes deal-breaking) differences between them, when even core developers
of both frameworks agree that they are more similar than different.

------
NathanCH
I wonder if there has ever been an article on Vue where both the article and
comments aren't a direct comparison to React.

Look no further than these comments. As always it's a mix of, "I tried React
and hated it, then I tried Vue and loved it!" or visa versa.

Metrics such as "I understood it immediately" or "it didn't feel right to me"
are shallow and meaningless.

Fact is, React and Vue are increasingly similar. So why these types of
articles make the front-page once a week is beyond me.

~~~
balfirevic
> I wonder if there has ever been an article on Vue where both the article and
> comments aren't a direct comparison to React.

This one? The article barely makes a comparison with React, and when it does
it emphasizes their similarities.

------
shadykiller
I've never worked with Vue on a full scale project but I loved the simplicity
and the great documentation. would love to use it soon.

------
lowry
This is exactly my experience. I used AngularJS, then studied many options
including the latest AngularJS, Angular 2 and 4, ReactJS... in order to
finally settle on Vue. Doing Vue front ends for over a year already.

------
luord
Pretty similar to my experience. Agree on everything.

Now to read the many mentions of react in the comments even though the article
has _nothing to do with it_.

------
flabbergast
This makes me think of the Apple marketing campaign in 2004. With Apple
everything is better, hmmm not really. Apple has the fastest pc's in the
world, hmmm not really.. With an Apple pc you'll get your work faster done,
sure? Especially the non-technical designers, writers, musicians etc..
believed that shit. In a way Vue gives me that same feeling.

------
dylanhassinger
I love Vue! :) best framework ever

------
papito
Knockout JS FOR LIFE!

~~~
kapv89
Have you seen MobX
[https://mobx.js.org/index.html](https://mobx.js.org/index.html)

------
rhengles
Evan, if you are reading, I would like to say that I also fell in love with
Vue, but I am frustrated that my feature request (
[https://github.com/vuejs/vue/issues/8106#issuecomment-385367...](https://github.com/vuejs/vue/issues/8106#issuecomment-385367128)
) was a little too quickly shot down, without much discussion or
understanding. I understand that not every proposal can be accepted, but I
think that the merit of the change wasn't even considered. I specifically
designed the change to change as little as possible, and have as much power as
possible.

I think that specifically in the case of Vue, this hurts more because of the
philosophy highlighted in the article- to not stand in the way of experienced
developers who know what they're doing.

(Edit: oh no, please don't come with the downvote train. This is a real issue,
when you have something that solves 99% of your problems but you can't get it
to 100%.)

~~~
ricardobeat
This piqued my curiosity, so I read through the issue and here is my take: you
are proposing a change that implements a _second_ way of loading async
components, in addition to what's already supported [1]. This is unlikely to
go through.

What you want is achievable with the existing async feature, except you either
need to 1) keep a list of component names up to date, or 2) use a special
component like `<dynamic-loader>` instead of the component tag directly.
Neither is a deal breaker, nor enough to warrant introducing a duplicate API;
it's rare that you'd be using advanced features like async components while
lacking a build process.

Evan's first answer wasn't the most friendly but you also come out as very
combative in those messages - as reinforced by your suggestion here that the
'merit of the change wasn't even considered'. Maybe there is some middle
ground to be found, an alternate proposal, but I find it extremely unlikely
anything will come out of this discussion using this tone. Humility is a must
even for experienced developers.

[1] [https://vuejs.org/v2/guide/components-dynamic-
async.html#Asy...](https://vuejs.org/v2/guide/components-dynamic-
async.html#Async-Components)

~~~
rhengles
Thank you for the reply. I hope I am not combative in this reply, I just want
you to understand from my point of view.

It's not exactly a second way of loading async components - because the
standard async components must be pre-registered in a list (your point #1) -
It's a way of _lazily_ resolving components, i.e., only when they are needed.
In fact, my change also works for synchronous components, that's why it's not
duplicating functionality. But normally, if you already have the component
definition loaded, you might as well register it, there's no point in lazily
loading synchronous components.

But your #2 point, imho it's not a viable solution because it uglifies the
application source code. The way components are loaded should be an
implementation detail - for example, I could lazily load components during
development and then compile those components before deploying to production
into an bundle that automatically registers them all with Vue.

I fully agree with the need to be polite and humble when dealing with people,
but maybe because I am not a native speaker, I never thought I was being
aggressive, I simply saw(think?) that the people I communicate with didn't
undestand what I was proposing, and as such I am trying to convince them of
the very real need that I have.

