
Comparison with Other Frameworks - wanderer42
https://vuejs.org/guide/comparison.html
======
mythz
It says they tried not to be biased, but it doesn't look like they tried at
all. Apparently every design decision made in Vue is superior. This isn't a
fair comparison and shouldn't try to masquerade as such, it would be fine if
it was positioned as an opinion piece on why we think Vue's approach is better
instead of a "perfect framework" ad it is.

But after using JSX I'm never going back to a templating system. JSX has an
intuitive direct mapping to JS that lets you use the full power of a
programming language without needing to learn another crippled DSL syntax.

If you've never used React before after reading this you could be forgiven for
thinking it's a complex monstrosity needing a week of prep to build a
HelloWorld app which is a biased gross over exaggeration. React has one core
concept, Components, which is easier to create, encapsulate and reuse better
than anything else I've seen. I also believe in React's being able to use JS
for Views, Style and Behavior making it easier to encapsulate cohesive
Components.

I consider Ecosystem, community, dev resources / backing, encapsulation and
reuse integral for adopting a framework which React wins easily on but is
quickly disregarded here.

Whislt this is a biased guide Vue has convinced me enough to evaluate it, I'm
especially interested in its performance and being able to reference it like a
jQuery script tag which I believe is the biggest shortcoming of modern JS fxs
which has succumbed to npm micro module madness inflicting complexity and
friction on all developers which is IMO the major source of complexity when
adopting a modern fx.

~~~
pluma
I like that Vue seems to be carrying Angular1's torch of "make it easy for
non-programmers to write templates" but I feel like that has been an illusory
strawman from the start.

Not only does it mask the fact that the supposed non-programmer template
designer would still have to understand HTML and CSS yet somehow not have even
the most basic knowledge of JS, but they would still have to be able to use
whatever build tools are necessary to actually render those templates,
including version control and node.js (which is the de facto platform for
client-side build tools these days). The target audience seem to be old-school
"webmasters" who FTP their PHP templates to the live server yet we're talking
about technologies requiring a workflow that already precludes them.

So we're talking about a scenario that only benefits people who already tick
all the boxes for "front-end developer" _except_ they apparently suffer from a
nervous breakdown if they have to look at an if-block or understand a for-loop
yet they'll be fine learning another template language that is typically based
on JS expressions anyway (though Angular was guiltier of this than Vue).

Maybe these people exist. Maybe there are teams where optimizing technical
decisions for these people results in a net benefit. But I strongly doubt that
this scenario is so widely applicable that this design decision makes a
framework inherently superior when the cost of JSX to a team of JS devs is
practically nil.

~~~
g00gler
How do you mean, "templates for non-programmers"?

I see Angular's directives as a pure convenience compared to most every
templating engine I've used across languages, never considered it something
that makes it accessible to non-programmers. I'd actually think someone who
only knows html/css would be more thrown off from a page with random,
unsanctioned (by W3C), tags and attributes that may or may not reveal what
they actually do.

As a programmer I don't want to write long templates, I seriously prefer
Jade/Pug for that reason. When I can't use them for a client I typically use
them to do all initial work, compile them to HTML, then make whatever minor
changes from there.

Consider ng-for:

    
    
      <div data-ng-for="y in x">
        <h1>{{y.title}}</h1>
      </div>
    

The ASP.Net solution is a pain, a function with HTML string template to
dynamically add elements to a "runat" div.

This PHP example seems more idiomatic, at least to me, yet takes more to write

    
    
      <?php foreach($x as $y){ ?>
        <h1> <? echo $y->title; ?> </h1>
      <? } ?>
    

The JSP style is kinda similar to Angular, again maybe more idiomatic at first
glance but still not as quick/simple to write

    
    
      <c:forEach items="${x}" var="y">
        <h1>${y.title}</h1>
      </c:forEach>
    
    

The jQuery/plain JS solution, especially before ES6 is not preferable by any
means, especially beyond this simple example.

    
    
      var body = document.getElementsByTagName("body")[0];
    
      [...].map(function(y){
      body.innerHTML += 
        "<div>"+
         "<h1>"+y.title+"</h1>"+
        "</div>";
      });
    
    

Unlike all the other solutions, angular has 2 way data binding so when you
programmatically add elements to the array in ng-for, they are added to the
DOM without a reload.

So, is the goal of a programmer to simply write more code? If so, then Angular
is definitely not for programmers.

Is the goal of a programmer to solve problems? If so, Angular is definitely a
tool for programmers.

~~~
raboukhalil
PHP also offers a nice way to write templates without even having to use echo
and without braces:

    
    
      <?php foreach($x as $y): ?>
      <h1><?= $y->title ?></h1>
      <?php endforeach; ?>

~~~
combatentropy
Yes, that's what I do. I also think it's fine to use omit trailing semicolons
and to use short-open tags (I already labelled the file .php --- why do I have
to keep saying "php" all over it? And I'm not usually outputting XML.)

    
    
      <? foreach($x as $y): ?>
          <h1><?= h($y->title) ?></h1>
      <? endforeach ?>
    

You just want to make sure to escape all output with htmlspecialchars, or
define a shorter function like I did ("h").

~~~
raboukhalil
I agree!

------
FrancoDiaz
_In React, everything is Just JavaScript, which sounds very simple and elegant
- until you dig deeper. The unfortunate reality is that reinventing HTML and
CSS within JavaScript can cause a lot of pain._

So what's the pain for me, as a user of React? It's just embedded HTML for me.
They never go on to explain why.

And...

 _Instead, we offer templates as a simpler alternative:_

<template> <div class="list-container"> <ul v-if="items.length"> <li
v-for="item in items"> {{ item.name }} </li> </ul> <p v-else>No items
found.</p> </div> </template>

Notice how the templates are code in strings. I don't find that simpler at
all. I find code in strings to be an anti-pattern. I already have a nice real
language (TypeScript in my case) to do "templates".

~~~
Flow
I fiddled with VueJS some weeks back and didn't use the .vue files because I
wanted to understand what I was doing and not have a build chain.

After a while it felt like I was writing strings in strings in strings. And
that was exactly was I was doing. I think JSX is a very sane way of coding
after all. I think writing things like

    
    
        <ul>
            {childItems.map(x => RenderChild(x)}
        </ul>
    

is wonderfully clear.

~~~
jadbox
no need for lambda

    
    
       <ul>
         {childItems.map(RenderChild)}
       </ul>

~~~
sedro
Maybe, but be aware those are not equivalent (your method will pass extra
arguments to RenderChild)

~~~
jadbox
If you're the one designing the map function transformer, then you know about
the extra args thing... but otherwise you're right that you have to be
careful!

------
anonyfox
I think the way vue components are composed is perfectly suited for everyone
that comes into the frontend story right now.

There is no syntax to learn, except that you can have v-if and v-for in your
html elements. A style block contains your CSS like you're used to, plus it
can be scoped to a component. A script block contains a bit of local logic and
event handlers.

Component = <template> \+ <script> \+ <style>. Give it a name with the .vue
extension. Now you can use it like a custom HTML tag.

(If you really want JSX you can use it, too. Personally I'm migrating back
from JSX to the above way of composing things)

Once you reach a certain complexity threshold in your app, you'll read how
others solve this with a "flux architecture", include vuex in a few hours, and
have these issues sorted out without hassle or nitpicking dozens of tiny
libraries.

Need more "pages"? vue-router is there. Ajax-stuff? vue-resource just works.

Basically there are just 3 common issues left for Vue to become the ideal
frontend solution IMO:

1) "official" bootstrap components that play well with vuex

2) a polished "react native" that just works, maybe soon solved by weex

3) SSR without hassle, ideally with a express.js middleware or something like
this.

~~~
iotscale
We use knockout at work but

    
    
        <p data-bind="if: foo">foo!</p>
    

quickly turns into

    
    
        <!-- ko if: foo -->
            <p>foo!</p>
            <p>
              because this also depends on foo and I should
              keep it DRY and adding a parent element just
              to contain that "if" is silly.
            </p>
        <!-- /ko -->
    

Then you start to get comments everywhere and sometimes they don't match and
you write server-side helpers to contain them then it becomes a soup of html,
your server side templating language and knockout annotations.

JSX is way cleaner.

We are still probably going to migrate to Vue.js though because it will be
easier. (We love Knockout but having performance problems on edge cases.)

~~~
ledak
You should consider using React with MobX. Similar concepts, but more powerful
and mature.

------
Ruphin
I don't think the person/people who wrote these comparisons has much
experience working with the frameworks and libraries they are comparing with.
The comparison with Polymer sounds very strange to me as a Polymer developer.

They start off saying Polymer is based on web standards, where Vue implements
it's own system. They consider this favorable for Vue, because on -some- older
browsers Polymer needs a polyfill to work. This makes no sense. The idea is
that in modern browsers Polymer leverages the browser implementation of custom
elements so it needs to do way less work. They completely ignore the fact that
the Vue implementation needs to do work to implement encapsulation on every
browser, even modern ones.

One of their points is that Polymer is stuck with plain CSS and JS, which is
clearly not true, considering TypeScript and ES6 are the most common JS
flavors in the Polymer ecosystem. You can use any CSS and JS framework or
preprocessor you want with Polymer, you just have to tweak your build pipeline
a bit.

And then at the end they claim 'It is also totally feasible to offer deeper
integration between Vue with Web Component specs', except that it hasn't been
implemented yet and they are waiting for the spec to mature (even though all
major browser vendors have committed to the Web Component v1 spec).

So if something is technically (remotely) possible to do with Vue, it's worth
mentioning as an advantage of Vue, but if something doesn't come out of the
box with Polymer it's clearly worth mentioning as a negative?

I don't have any experience with the other frameworks in this comparison, but
after reading the Polymer snippet I don't believe in the objectivity of any of
these comparisons.

~~~
rk06
Is that so? Well, feel free to raise an issue at github repo
([https://github.com/vuejs/vuejs.org/issues](https://github.com/vuejs/vuejs.org/issues)).
That will prompt them to update the comparison.

------
bikamonki
What happened with Backbone? Did I read you will try to avoid bias? I
completely understand that you'd want to benchmark against the trendiest
frameworks: after all this is Javascript and what matters is what happened in
the last 12 months. Yet, as a Backbone user, and after playing around with the
other _popular_ frameworks, I still do not see a compelling reason to move
dozens of well running projects to a new framework. Here's my bias:

Shaving milliseconds in rendering, repaints, scripting, etc? For what? Modern
devices make it almost irrelevant. If you'd be selling seconds to milliseconds
I'd say ok let's have a look.

Complex dependencies vs zero dependencies. So now I need some library to
bind/transpile/build many other libraries that in the end will...shave some
milliseconds. You just added unnecessary complexity to solve the same problem,
not to mention more KB to download.

JSX??? Don't get me started here.

Backbone _core_ library is all I need. It packs routing, binding, event
handling, rendering. Yours is useless out of the box, to be used on a real
complex app it needs...more dependencies.

Fork Backbone, add a virtual dom to shave them milliseconds, and I'd argue
that we've made progress.

~~~
michaelcampbell
I'm not saying Vue is better or worse, having never used it. And you bring up
some good points. But I had to chuckle a little internally because your post
could almost be a case study of pg's blub paradox article.

~~~
bikamonki
True...yet I am still not convinced about the _clear advantages_ ;)

------
hesarenu
Vuejs is adding it's own tags to html like if and for. Which requires another
DSL to learn when i use simple js(not advanced js) in react. Which leads me
question if they are other tags to be learn to simply display components.

I also like my components to be tightly coupled. Having a template just for a
single component is not useful I learnt that from my backbone js experience.

Declarative syntax is very good win for reactjs. Most can eaily understand the
component code. It requires few basic life cycle to be learnt rest is just
JavaScript.

~~~
papaf
_I also like my components to be tightly coupled._

Ah Javascript programmers, you are a source of constant entertainment:

    
    
         https://en.wikipedia.org/wiki/Loose_coupling

~~~
hesarenu
Not familiar with reactjs? You need to have loosely coupled tight components.

~~~
walterstucco
mixed with something looking like HTML that is NOT HTML. I love React it's the
first js framework that doesn't make me wanna puke, but Jsx it's just the
iPhone of template languages. It's fine and eveeybody understand it but it's
far from great

------
Ciantic
Problem me with Vue is it's template language. Why invent a new one and not
use JSX? Main selling point for me with JSX is it's the most type-safe
templating language I've seen when used together with TypeScript.

People have pointed out here that it's easy to use JSX with Vue, and that
could be something I might look at.

~~~
beefsack
You talk about JSX as if it is some sort of standard. A significant number of
people aren't interested in compiling to JS or language extensions for a
number of reasons.

I appreciate what Facebook were trying to achieve with JSX, but libraries like
Mithril serve as an example that native templates can be done without a syntax
extension.

~~~
maktouch
React can be used without JSX like Mithril is doing. In fact, pretty much all
the JSX compiler does is convert those to React.createElement()..

------
medeas_crypt
I feel it's probably been said before, but why are people investing time in a
Javascript server side framework? It just seems ridiculous.

Edit: I can understand shipping logic from the server to client, for
validation perhaps. But... meh.

~~~
jacquesm
Because they believe that a single language should be enough for developing
web applications.

~~~
JSDave
Also, JS is built to handle concurrency. Other languages have event loop
libraries, but in JS it comes with the language and every web dev uses it.

~~~
goatlover
What does it mean that it "comes with the language"? In what way is Javascript
the language any more asynch than Python, PHP, or Ruby? The browser and Node
environment are not JS the language. They are the environments JS
predominantly runs in, and they provide async events, which could be done with
any language running in similar environments.

~~~
paulddraper
Would your objection be appeased if he said "comes with the environment"?

IDK of any Python, Ruby, or PHP runtime that has Node's paradigm of single
threaded + concurrent I/O.

------
jgalt212
1\. If you really hate templates, maybe it's time to go full bore and make the
switch to Elm.

2\. If you are working on page/site that may or may not evolve into an SPA,
choosing Vue.js over Angular or React seems like a no-brainer.

3\. If you are working on an SPA from the the get-go, then the choice becomes
more difficult. However, if the SPA is only one part of your site Vue.js
offers you the opportunity to use it site-wide, whereas using React or Angular
site-wide would quickly become quite cumbersome and I'd guess is most cases
folks actually use React/Angular for the SPA pages and jQuery for all others.

~~~
scarlac
I strongly disagree on your 3rd point: In my experience React gives you full
control over rendering which includes where you want to use it and if you want
to use it with non-React stuff. Regardless of site being a SPA or not.

As an anecdote, I rewrote a large site from jQuery to React without
precompiling my JSX and using ES6 via Babel. It took 3 script includes and
then I could do a gradual transition and replace elements with React instead
of jQuery. jQuery components lived happily alongside React just fine. Even
though I did nothing to optimize page loads, I made massive gains for
performance, even with React in dev/debug mode.

------
taphangum
If anyone is interested in more indepth Vue examples and back and forth, check
out the VueJS subreddit here:
[https://www.reddit.com/r/vuejs/](https://www.reddit.com/r/vuejs/)

------
elcct
Why do they say their template system is simpler than JSX? You have to learn a
whole lot of new stuff and syntax is barely readable. Whereas JSX is clear and
you can use already familiar JavaScript.

~~~
Bahamut
JSX using JS for logic is both a boon and a curse. It is just as easy to shoot
yourself in the foot and write some ugly imperative construction as writing an
elegant template.

I wonder if we will ever have a satisfactory solution to the template problem
of conditional rendering. All I've seen so far solved one problem only to
bring another. To some degree, this is really a dogmatic problem, which is why
it'd be nice if we could solve this and move on with more important things.

~~~
jwdunne
In fairness that's the main point of contention with PHP templates, leading us
to 4 big templating languages including PHP itself.

It's the same old balance problem: more flexibility and less constraints opens
up potentially dangerous misuse.

We see it with languages too I.e C memory management vs garbage collection.

We also see it socially too. There are particular problems with both 0%
regulation and 100% regulation, with the ideal that nobody can agree on lying
somewhere in between. In fact, some situations call for more or less,
compounding the confusion.

Perhaps the solution is a template system that can fit current needs, in that
a programmer can choose to remove a restriction but the removal of the
restriction gives the seconds required to think if removing a restriction is
necessary.

That then means we can collaborate as an industry. We may find that there
exists one or a handful of "ideal general restrictions". We may also find that
actually for certain types of problem would do well with a handful of specific
restrictions that work well there.

I just don't think there is a one size template solution and our attempts at a
fixed ideal haven't seemed to work. After all, if we had the true ideal, we
wouldn't keep making new ones.

~~~
elcct
It seems like a huge waste of time to create a new language so that people
will not do "stupid" things in their templates. The case of PHP is especially
amusing. How about using common sense? I mean if a programmer intends to do
"dangerous misuses" in the templates, maybe he shouldn't work on it in the
first place. Having a person not being able to tell whether something is
dangerous or not, working on the project and then creating a template language
to forgive the lack of knowledge is just asking for trouble in the long run.

------
nawitus
"Polymer custom elements are authored in HTML files, which limits you to plain
JavaScript/CSS (and language features supported by today’s browsers). In
comparison, Vue’s single file components allows you to easily use ES2015+ and
any CSS preprocessors you want."

This is incorrect. It's easy to use ES2015+, TypeScript and CSS preprocessors
in Polymer.

------
smegel
Reading the comments here makes me realize it is probably better to come back
in 12 months and observe what is still left standing.

------
Tade0
I've used Vue since before v1 and for my use cases it's fine - especially v2
combined with Vuex. I was suspicious towards React from the get go because to
me it looked over-engineered. As for Angular 2, yeah, it's a major improvement
over its predecessor, but that's about it.

------
franciscop
> By embracing HTML rather than trying to reinvent it within JavaScript, [...]

I am sorry, but that looks totally wrong with the previous code example. Vue
in that instance seems to be reinventing Javascript in HTML (while the
critique is true that React reinvents HTML in JS).

------
Vozze
I am new to Vue.js. What is the use case? Is it like react in that you can use
it to target web,android and ios with one codebase?

~~~
d0m
It's a "Competitor" to Angular.js, focusing on the web but with plans to go on
android/ios like React Native eventually.

------
k__
Is Vue fractal?

------
d0m
Personally, what I love about React is how simple the model is. There are no
Directives or Filter or whatever else. It's just a Component with a state, a
render and some life cycle methods. That's it. The full power of Javascript in
a render function. The second you try to move away from the "full power of
javacript to render your view", the more you need to add special cases in your
template engine.

Just randomly going through the Vue docs, we see stuff like:

>> Note that you should not use an arrow function with the data property (e.g.
data: () => { return { a: this.myProp }}). The reason is arrow functions bind
the parent context, so this will not be the Vue instance as you expect and
this.myProp will be undefined.

I don't want to deal with this crap anymore. I'm still making nightmares about
$scope.$apply. (Yes I know Vue doesn't have the $apply problem, that was just
an example).

Where I think Vue.js really shine is for teams that want a standard, industry
proven solution, to build web apps. Similar to Angular, you don't have to re-
invent the wheel. You just look in the documentation and use whatever is built
for you. I think this is great for many projects. Personally I've been burned
by the limitations of those frameworks and I'd rather keep my freedom to build
things the way I want.

In the Vue comparison, they say this is how you build components with React:

    
    
      render () {
        let { items } = this.props
        let children
        if (items.length > 0) {
          children = (
            <ul>
              {items.map(item =>
                <li key={item.id}>{item.name}</li>
              )}
            </ul>
          )
        } else {
          children = <p>No items found.</p>
        }
        return (
          <div className='list-container'>
            {children}
          </div>
        )
      }
    

If you're the kind of person who keep repeating that kind of code everywhere
in your app, then yes, maybe Vue.js is better for you. But such if/else
pattern is easily abstracted away with a simple function which makes it as
concise as the Vue snippet without relying on directives in templates. Also,
keep in mind that this is only one use case. What if it needs to be slightly
more complex? WIth Vue/Angular, you're forced to add directives or whatnot.
With React, same render function. I like that cognitive simplicity. Yeah,
maybe the render function is slightly more complex, but at least there's only
that to be aware of. Not hundreds of directive/filters/whatnot spread
everywhere.

In a way, I feel like React is more lower level. I use it to build my own
framework on top of it. Where I feel like Vuejs, similar to Angular, __is
__the framework.

------
goodarz
So they left our the one platform more popular than them, Meteor?

~~~
rk06
\- Meteor is promoting react for view layer.

\- Blaze, meteor's original view layer, lacks components and has very slow
development.

So, comparison with meteor quite useless.

------
kinga254
Whose has used mithril and how does it compare to vue?

