
Why Choose Vue.js - jgalvez
http://hire.jonasgalvez.com.br/2017/Jun/23/Why-Choose-Vue
======
linkmotif
I really don't get how separating templates is a good thing. Been there, done
that. Not going back. Not going back to separate CSS either. Because having
everything together is great. Not to mention using JS for render logic. That's
great too. It's what I always wanted. People kept pushing "best practices" on
me—like not using the style attribute, separating templates—and I am so
grateful for the people at Facebook for ending that.

Like most articles about Vue.js—and I keep looking because I keep wanting to
understand the appeal—there's never a clear explanation regarding why
separating templates and not using JS for render logic is good. Maybe it's a
matter of taste. For me, having everything about a component in one place is
very convenient and simplifies abstraction and composability.

Maybe I just need to try Vue.js to understand the draw. That was true for me
with React. But React was a totally new paradigm for me. Vue.js seems like a
combination of several familiar paradigms in a way that doesn't really make
sense having gone React.

~~~
outsidetheparty
Vue components have the html template, the javascript code, and the
component's scoped CSS all in one file. You can define the template in a
string, or even in JSX if for some reason you wanted to do that, or you can
just use regular old HTML which is stored alongside the javascript that
controls it and the css that styles it.

~~~
pdfernhout
But a template is not "regular old HTML". HTML is a standard for declaring
marked up text. What Vue and similar libraries do is make adhoc variants of
HTML (all different) with extra looping constructs and if/then constructs and
so on. The templates also require embedding snippets of JavaScript code in
them -- code which standard JavaScript/TypeScript IDE tools don't know about
and so can't refactor, validate, or navigate.

These templates may look declarative because the look HTML-ish but they are
not -- because of the embedded code that can call arbitrary functions in your
application. The result is hard to debug and reason about. Where do you put a
breakpoint in such a template? How do you abstract part of a template into a
function? How do you add logging to such templates? How do you know what
object is having its data accessed for templating languages like with Angular
that do complex contextual lookups behind the scenes? How do you get code
coverage reports? How do you get code completion? How do you get precise error
reports? And so on. For more on why templates are a bad idea, see:
[https://blog.dantup.com/2014/08/you-have-ruined-
html/](https://blog.dantup.com/2014/08/you-have-ruined-html/)

That is why I feel these sorts of template-based approaches will eventually be
discarded as obsolete for writing single page applications as web programming
continues to progress (in favor of generating UIs directly from code). HTML-
ish templates feel familiar to people with experience building progressively
enhanced web apps by sprinkling a bit of CSS and JavaScript on top of HTML
generated from a server -- but for single-page apps that spend most of their
time converting JSON from a server into HTML (or just doing stand-alone
activities), a templating HTML-first approach make little sense. You just
don't need extra templating machinery that you need to learn and maintain and
that just gets in the way of development.

By contrast, consider the HyperScript API for generating HTML from
JavaScript/TypeScript (as used in Mithril, Maquette, and optionally in Inferno
and some other vdom libraries).

For example:

    
    
        h("div", 
            h("ul",
                h("li", "one"),
                h("li", "two"),
                h("li", "three"),
                someExtraListItems(),
                otherItems.map((item) => h("li", item.name))
            ),
            isListEditable ? 
                h("button", { onclick: editList }, "Edit extra list items") : 
                []
        )
    

If you use the HyperScript approach (especially with Tachyons.css or similar),
you are just writing JavaScript/TypeScript/whatever and can leverage all of
the language's features. JavaScript-first for modern SPAs!

~~~
linkmotif
> These templates may look declarative because the look HTML-ish but they are
> not

Yes! Precisely. How many of these "regular old HTML"s I've seen and even used.
Each with their own looping constructs, their own if/then constructs. The
benefit, honestly, was lost on me then and is still lost on me.

React is not perfect. JavaScript is horrible. But pretend "HTML" templates are
so much worse for all the reasons you describe.

I still suspect there must be something to Vue, though. So many people like
it. Many of them have tried React, so I'm sure it's not like they're all
ignorant to the glory of JS-based rendering. I wonder what it is.

------
graysonk
Love the article! But wow this site hurts my eyes. Yellow and red font on a
black background aligned very far right?

~~~
jgalvez
Thank you! It looks great here but I'll keep that in mind.

~~~
apocalyptic0n3
Just to add my voice to this, I read about 3 sentences before closing the tab.
That is extremely difficult to read.

Also seeing issues with the right column overlapping the left

~~~
jgalvez
Jeez, CSS is hard :) Thanks guys, I'll get on fixing this.

~~~
Marinlemaignan
If i may..? The equally symetrical layout is hard to read, you should rather
use an one third - two thirds layout, or about. Then i'd try something like
#FFF1CA for the left hand column, so it looks like the text (i know they right
now are the exact same color but one being surrounded by black making it look
lighter). Also, maybe increasing the padding up of the right col up to a 100px
would prevent eyes from being lost between both columns when jumping lines.
Overall contrast is way too high. Hope that helps.

------
sjroot
I embraced Vue after making multiple attempts to digest the React platform
with little success. I have found that Vue's templating system and APIs have
brought so much clarity to the complex projects that I set out to build, and
would highly recommend it to anyone. It is my hope that React may learn from
some of Vue's triumphs.

------
nkg
I initiated the adoption of Vue.js in our agency about a year ago and we never
had to regret it. One positive aspect that I didn't expect is that the
architecture of Vuejs apps kind of forces you to write cleaner code: methods,
states, mutations, every piece has its own place.

------
murukesh_s
Remarkable that Vue.js (Single dev) is holding up well against React. I was
recommending Vue.js to others while react was the craze. It somehow felt more
cleaner to me and the performance, if I am not wrong was on par or better than
React.

~~~
desdiv
Vue.js is heavily backed by Alibaba, the 7th biggest tech company in the world
by market cap.

~~~
lightblade
I like to see some evidence of this claim. Certainly Alibaba.com is not built
with Vue.

~~~
bdcravens
[https://medium.com/the-vue-point/the-state-of-
vue-1655e10a34...](https://medium.com/the-vue-point/the-state-of-
vue-1655e10a340a)

Doesn't say anything about being sponsored by Alibaba, but Evan does indicate
adoption there.

~~~
lightblade
That's the thing. All claims of Alibaba's adoption of Vue comes from the
author himself. I think it's reasonable to have doubt. I'm sure they use it.
But to claim that they heavily invest in it may be exaggerated.

~~~
murukesh_s
Yes, he has openly said he is funded through patreon. Now that the framework
is super popular, he may have other sources of income, but it's not built
by/for/in Alibaba afaik.

------
vyrotek
We love Vue at our company. I'm personally a fan of how Vue separates and
handles templates.

That said, it was a bit difficult to read this article on a fullscreen monitor
since it's aligned to the far right.

~~~
dugmartin
Agreed. Just run this in the console for a little better experience.

    
    
        document.getElementsByClassName("left")[0].style.right = "55%";
        document.getElementsByClassName("articles")[0].style.width = "50%";

~~~
jgalvez
Thanks, I fixed it with something close to this.

------
ausjke
So, I was told to separate html, css and js into different files and such, now
web components, vuejs are saying no let us mix three into one component
instead. IMHO, too much abstraction kills productivity, I am choosing vuejs
and polymer for future projects, yes I like to mix html/css/js together and
make them components for reuse.

------
invalid_
"specialising in UI/UX work with both React and Vue".. "rare occasions I
needed to write javascript in the past 5 years"..

Hmmm

~~~
jgalvez
Well, that's not entirely accurate if you're going to be nitpicky about it. I
did work on a multitude of frontend projects in the same period
([http://linkedin.com/in/jonasgalvez](http://linkedin.com/in/jonasgalvez)),
just took me a while to consider updating my toolset (which was my point).

------
Exuma
This color scheme gives me extreme anxiety... good article though.

------
ajoy
Previously used Vue and switched back to React. I have a few gripes about Vue
for larger projects. Most have to do with a lack of 'namespacing' or ability
to isolate functions.

1\. Plugins - Eg. Recently VueResource plugin was deprecated, but i had a hard
time finding out where all the plugin was being used. The dependencies were
hard to figure out.

2\. Functions introduced in Plugins added to a parent component are inherited
in all the child components' 'namespace'. It was hard for me to determine if a
function that I am writing has a naming conflict with a plugin function, until
runtime.

3\. Since this dependency is not obvious, a new dev looking at a piece of code
that is using some functionality inserted by a plugin, needs to be aware of
all plugins that have been interjected at any of it’s parent level components
and the functions they introduce.

4\. Mixins help with re-use code, but can lead to potential function naming
conflicts.

Maybe I was doing things wrongly w/ Vue. If so, any recommendations are
welcome.

------
StreamBright
Is this a CSS joke that backend people won't get? Or why does this site look
like a 90s parody of web standards? I am not sure if I can take him seriously
over which JS framework to use just by judging on his site.

~~~
Brockenstein
Since when does expertise in javascript have anything to do with design? The
site is simple, why does it need to be more complex or flashy for you to take
it seriously?

------
sebringj
"no need to bind methods", that's true but just letting you know its not a
thing if you use es6 arrow functions.

class SomeClass extends React {

    
    
      someMethod = () => {
    
       // already bound
    
      }
    
    }

~~~
acemarke
To be clear, that's not just an ES6 arrow function. That example relies on the
Stage 2 Class Properties syntax, which currently requires a Babel plugin. Now,
the React team does recommend using that syntax as a viable option, but it's
not yet implemented in browsers, and _might_ still change down the road.

~~~
sebringj
interesting point. that reminds me of the "..." syntax on object properties
that isn't supported on es6 for objects but still is a pretty sweet feature.

~~~
acemarke
That one's a lot closer to being finalized. Object Rest/Spread is currently at
Stage 3, and is already implemented in Chrome/V8.

For reference on proposal status and details, see
[https://github.com/tc39/proposals](https://github.com/tc39/proposals) .

------
nickthemagicman
I think Front End development is so insane because Front End dev is chained to
the browser and javascript/css implementation by the browser makers. With web
assembly, hopefully browser developers can separate from making languages and
instead make language targets. Then the separately developed language can stay
stable while its underlying implementation can adapt to the dumb browser
madness. Then we can have some sanity in web development. It's what we are
trying to do now with all the maddening layers of transpilation.

------
mpalmer
> In React, you need to use the setState() to trigger rendering updates as you
> modify the state. In Vue, you simply assign things to this and, if
> necessary, the component's automatically rerendered. You do need to provide
> an initial state (data) for safety.

Hoo boy. "Simply" assign directly to `this`! This may come down to preference
for/against functional tools, but on this point Vue loses big for me. Seems
way less testable...

~~~
Can_Not
You can still use vuex for the flux experience.

------
wintorez
I was very interested in Vue.js initially, but I had to pass once I realized
it uses two-way data-binding. I prefer React.js since it has less behind the
scene magic than Vue.js or Angular. Although I like certain aspects of Vue.js
which I think React could learn from.

~~~
badthingfactory
I'm not sure I understand rejecting a library because it allows two-way
binding. If two-way binding doesn't work for some control, nothing is stopping
you from falling back to one-way binding.

~~~
Klathmon
There's something to be said about staying as close to the "intended" way of
doing things as possible with libraries.

Yeah, you might be able to stick with one way binding, but anything that
interacts with vue will most likely expect 2 way binding, as well as most
learning resources. Updates and improvements will be made with 2 way binding
in mind, and you won't have nearly as many "coded with vue in mind" tools or
libraries to use.

It's possible, and it might actually work out just fine. But in my experience
going "against the grain" with libraries only leads to pain.

~~~
outsidetheparty
I really haven't found this to be the case.

One-way data binding is the default for just about everything in Vue; the only
exception is v-model which is generally used only for form fields or similar
elements where two-way binding makes sense -- two-way binding is definitely
not pervasive throughout the framework as in Angular.

Apps of any complexity tend to use vuex (which is a sort-of-flux-like data
store) for state management.

~~~
Klathmon
Well then it seems I'm horribly wrong here! I haven't really used Vue (only
angular) and I made a bad assumption, but my point still stands in a more
general form.

~~~
outsidetheparty
Oh, I totally agree with you -- I'm an Angular refugee myself. I'm genuinely
surprised by how many people in this discussion seem to have such wildly
incorrect impressions of what Vue is like.

------
QuotesDante
This guy really ought to read [Practical
Typography]([http://practicaltypography.com/](http://practicaltypography.com/)).

~~~
lytedev
Why is this site's content off-center...? 1920x1080 desktop on Chrome. Is that
slightly ironic?

------
luketheobscure
Almost all of his arguments are also true for Ember.js, with the notable
exception of compatibility with "web components" (but there's Glimmer for
that).

------
attrezzarturo
JSX being transformed into JS allows you to test your logic (minus
brower/acceptance testing) in node, even if you load css and do weird stuff
with webpack. I am not looking at anything else until that is true for <put
your backbone/angular evolution here>.

~~~
ramses0
Take a look at this example of relatively complicated component-tests w/
markojs. It is an example of testing a transcluded component's variation
(arguably very valuable and complicated to test) and all the code, setup,
tests, etc. are very straightforward to understand.

[https://github.com/marko-
js/marko/blob/master/test/autotests...](https://github.com/marko-
js/marko/blob/master/test/autotests/components-browser/transclusion-body-slot-
tag/test.js)

------
dmix
This site doesn't render properly for me on latest Chrome (dev) on Linux.

[http://imgur.com/a/umXXB](http://imgur.com/a/umXXB)

~~~
jgalvez
Okay, I think I fixed that.

~~~
dmix
Looks good now, thanks!

[http://imgur.com/a/mbLoI](http://imgur.com/a/mbLoI)

------
scyclow
The two tabs on your website overlap on my 15" screen. I think you might need
to do .left { left: 100px } instead of .left { right: 740px }

~~~
jgalvez
Fixed that with right: 55%, thanks.

------
terenceng2010
Using vue without webpack or any build process becomes a maintenance issue
when you got dozens of x-template in a single html file.

~~~
jgalvez
I thought it was implied that using Webpack eliminates the need for said
inline templates. Should have made it clearer.

------
yavi
I've used Vue.js in projects for the better part of a year now and have
enjoyed it, for the most part. It's easier to grasp, is very usable right out
of the box without any build tools, and the documentation is solid. I've
mostly used vanilla Vue without Vuex or other dedicated state management (so I
can't speak well to how that would improve the experience), but my gripes with
it so far have mostly been:

\- Less explicit behavior leads to more magic. There are few if any 'gotchas'
with the React component lifecycle. If state changes in the component or in
its ancestry, React will re-render unless you explicitly tell it not to, every
time. There's a performance trade-off to this, but for most applications it's
not a problem, and you can handle it explicitly. By contrast, Vue decides when
to update components, and its algorithm works perfectly 95% of the time. The
other 5% of the time I find myself writing workarounds with watchers, and it's
a frustrating experience. Additionally, while Vue 2 got rid of many magic
variables, there are still a few that can lead to confusing behavior. For
example, the magic variable '$event' for emitted event data is needed only
when the event handler uses other variables too - otherwise it's included for
you automatically. It's convenient, sure, but I've seen more than a few
developers get tripped up by the ergonomics of Vue's magic. There are also a
number of gotchas around handling reactivity in arrays.

\- Size of community. While the community is certainly existent and growing,
you're still far more likely to find what you're looking for in the React
community. Additionally, much of what exists for Vue is written for the
Chinese community, which sometimes means less-than-ideal English
documentation. This should change over time but it's something to consider in
the present.

\- _Everything_ in Vue is reactive, which has added some real performance
overhead for us in some pathological cases.

\- This is purely personal preference, but I've never been quite sold on
extensions to HTML for templating. It might be a bias from working with React
but I prefer HTML-in-JS to JS-in-HTML.

As for the points the article brought up: \- Explicitly bound methods: Sure,
but this isn't a React thing, that's how ES6 classes work. If the extra line
or two per method is that troubling React.createClass() inserts all that
magical binding for you. \- State management: I don't really find setState all
that difficult to use. By contrast, Vue requires that all class properties for
the component be setup initially. If you decide to add one later, Vue will
simply ignore it unless you use Vue.$set() to register the property as a
reactive one. \- Mixins: This is certainly a controversial topic, but I tend
to agree with the React team, at least when it comes to larger codebases:
[https://facebook.github.io/react/blog/2016/07/13/mixins-
cons...](https://facebook.github.io/react/blog/2016/07/13/mixins-considered-
harmful.html) . Mixin-like functionality is possible with either library,
regardless. \- Templating: I don't find the overhead of either JSX or Vue
templates to be problematic after spending a day or two with either. My
experience has been that developers with a background in Angular gravitate
towards Vue templates as they have a similar DSL. The biggest differences to
me seem to be that Vue templates are slightly easier to read while React
templates offer the full flexibility of JS.

Don't let any of this detract you from Vue - I've enjoyed using it and would
recommend giving it a shot. Despite the caveats I've encountered with it
there's certainly good reason for its recent popularity!

------
isaac739
"if the main application code is under 1000 lines, keep it in a single file"

NOPE. I like .vue because you can easily avoid large files.

------
jgalvez
Alright guys, updated stylesheet and color scheme due to popular demand :)

------
pyedpiper
taking frontend framework advice from a website that is arguably uglier and
more poorly laid out than the bulk of geocities pages is a tough pill to
swallow.

~~~
jgalvez
Aside from the Jakob Nielsen-y vibe to the color scheme (intentional), it's
not that much different than any other developer blog out there -- but if
that's the angle you want to take to discredit what I am saying, fine.

~~~
devmunchies
> _if that 's the angle you want to take_

I don't think its some _" angle"_ out of left field. Its a valid point.

~~~
jgalvez
Well, to be frank, I honestly don't know what to think. I've had people
telling me it looks great, people telling me it looks awful -- it does look
amazing to me: [http://imgur.com/a/yMTz8](http://imgur.com/a/yMTz8)

Having said that, I'll definitely work out a update that's readable to wider
audience.

~~~
nickthemagicman
It's not that ugly. The layout is ok, the typography is fine. It's just that
yellow color that's not the best. As far as the rest it's fine.

------
lapsock
web development is such a retarded mess

its really amazing how much effort is spent on building the same CRUD apps
over and over again

~~~
LeoNatan25
Their constant jump from one framework to another is simply hilarious. PHP!
Yuck; jQuery! Eww, Ruby on Rails! Yawza; Angular! Err, React! Nope; Vue. And
all that (and much more), in, what, 10 years? Meanwhile, proper software
development has had frameworks that last for decades.

~~~
cat199
Had a similar opinion until dusting off my browser for some front end work
recently..

Browsers being roughly standards compliant, and those standards congealing is
a relatively new thing (last 10 years), having this happens facillitates alot
of browser-side dev (e.g. JS) which simply wasn't possible before, throw in
the growth of mobile/tablet UI's, and server side javascript, and the shift
from 'CGI extensions' into web-native applications where the browser is the
GUI and the 'web server' is really the 'application server', and the
appropriate paradigms to deal with this change rapidly.. the frameworks have
changed because the underlying platform and its use is rapidly evolving.

I think if you look at GUI toolkits early on as the desktop evolved and you'll
find a similarly chaotic and changing picture (e.g. Cocoa is not MacOS v1;
WinNT is not Windows 1.0, and neither are dosshell, etc)

~~~
LeoNatan25
Uhm, huh? The DOM model has not really changed at all. All those framework
just purport to make some improvements on how nodes are configured and
accessed.

On the other hand, you are very much wrong on the technologies you mention.
Cocoa was developed in Next, and a huge amount has remained as was at the time
of creation. NT is a kernel, not API. Assuming you mean Win32, which debuted
with Windows NT 3.1, it was very compatible in concepts and source with the
Windows API (retrofitted as "Win16").

