13 ms·

Comparison with Other Frameworks

256 points by wanderer42 10y ago

elcct 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
- unculture 10y ago
  You can use JSX if you like with Vue. The templating language, should you choose to use it, really is very simple though. It doesn't take more than an hour or so to get the hang of.
- Jean-Philipe 10y ago
  Well, display a list of things in JSX and Angular or Vue - I found the latter versions way more elegant. But YMMV.
- kitd 10y ago
  JSX is "new stuff" if you've come from Jade et al. Vue templating is much more like what pre-React frameworks use.
- Touche 10y ago
  > Why do they say their template system is simpler than JSX? JSX doesn't run in browsers.
medeas_crypt 10y ago
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 10y ago
  Because they believe that a single language should be enough for developing web applications.
  - medeas_crypt 10y ago
    Probably a fair enough perspective. I guess I just hate it. With a passion.
  - BjoernKW 10y ago
    What became of "the best tool for the job"? I doubt the benefits of having a single language outweigh the effort put in just to replicate solid server-side environments existing today.
    - MatekCopatek 10y ago
      I know what you mean, but at some point in history you could say that for every programming language that wasn't the first one to dominate that specific domain.
      - BjoernKW 10y ago
        Absolutely and I'm not against innovation at all. The exercise of making JavaScript a valid server-side alternative often seems pointless, though. What's the benefit of JavaScript on the server side other than "one language"? Perl, Java, Spring, Ruby on Rails each offered significant benefits over what existed before. What does JavaScript on the server side do better than other solutions? There's the event loop and non-blocking behaviour but is that enough for most applications to justify using JavaScript on the server side?
hesarenu 10y ago
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.
- unculture 10y ago
  You can drop down to JSX or plain JS render functions with Vue if you like, but JSX (which brings with it all the potential complexity of JS) is harder for many people to understand. The constraints of a (very!) simple templating DSL make things easier to read in the long run.
  - hesarenu 10y ago
    For me it's easier to understand the lifecycle then to learn methods to simply do a boolean check or loops. In that way vuejs is more complex.
- arnorhs 10y ago
  >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. I'm not familiar with the concept of simple js vs advanced js in react. But your statement about Vue's tags being its own dsl holds true for jsx as well.
  - barrkel 10y ago
    JSX doesn't have control flow. Therein lies all the difference. Javascript's void-typed statements are a problem, though.
    - Touche 10y ago
Ciantic 10y ago
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 10y ago
  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 10y ago
    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()..
- bradrydzewski 10y ago
  FWIW my understanding is the vuejs template language is based on an early version of the web component template specification (which might predate the jsx specification). You may therefore notice a good amount of overlap between vuejs templates and polymer, for example.
- paulddraper 10y ago
  > Why invent a new one and not use JSX? JSX is a new templating language too. It not standard; it not JavaScript.
mythz 10y ago
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.
- progx 10y ago
  I didn't use vue, but https://vuejs.org/guide/syntax.html https://vuejs.org/guide/syntax.html did not look so complicated. But you are right, i am not sure to use a template system again. But the advantage is cleaner code, many people change quickly to spaghetti code in jsx (mix all together, ifs, loops, ...).
  - mythz 10y ago
    Spaghetti code refers to poor coupling not cohesive encapsulation or being able to build complex smart views which can easily be refactored using native programming language constructs. I'd much prefer having a single powerful language for everything instead of forced artificial friction on having to spread your component over multiple DSLs.
anonyfox 10y ago
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.
- woah 10y ago
  What does vue resource do that can't be done with fetch?
- iotscale 10y ago
  We use knockout at work but <p data-bind="if: foo">foo!</p> quickly turns into  <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>  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 10y ago
    You should consider using React with MobX. Similar concepts, but more powerful and mature.
k__ 10y ago
Is Vue fractal?
deleted 10y ago
[deleted]
Vozze 10y ago
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 10y ago
  It's a "Competitor" to Angular.js, focusing on the web but with plans to go on android/ios like React Native eventually.
jgalt212 10y ago
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 10y ago
  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.
Ruphin 10y ago
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 10y ago
  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.
FrancoDiaz 10y ago
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".
- rk06 10y ago
  As far html vs jsx goes, i would say its a matter of taste. But when it comes to css, vue's css are way better than React's alternative by a longshot.
- reza_n 10y ago
  As another reply mentions, its a matter of taste, but for me its the clean seperation between data and presentation. Presentation is generally HTML+CSS. Data and plumbing is JS. This is similar to traditional MVC and works well with mixed dev/designer teams. Dev in JS, design with HTML+CSS. You can liken it to a data API returning data with HTML in it, you now have data and presentation together. Do you want the 2 roles in 1 convenient language? Great, JSX gives you that power. Do you want data and presentation separate, then go with templates.
  - eyko 10y ago
    Your component's logic is all presentation logic. You may want to break it even further but it's not a real separation (you still have logic in your templates via `v-if` and `v-for`, don't you?). Data, in both React and Vue, lives outside the component.
    - reza_n 10y ago
Tade0 10y ago
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.
taphangum 10y ago
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/
bikamonki 10y ago
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 10y ago
  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 10y ago
    True...yet I am still not convinced about the clear advantages ;)
- ieatkittens 10y ago
  > Modern devices make it almost irrelevant. A todo list on an mbp, yes. A complex app on a tablet, not so much. > Yours is useless out of the box, to be used on a real complex app it needs...more dependencies. All Vue requires is vue.min.js and you're set. Adding routing and clean data flow out of the box is trivial. _But_ it is easy to end up with a massively over engined babel-webpack-flow-npm-flux meme stack, given the excellent vue cli. I am, of course, guilty of that myself.
nawitus 10y ago
"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.
d0m 10y ago
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 10y ago
So they left our the one platform more popular than them, Meteor?
- rk06 10y ago
  - 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.
franciscop 10y ago
> 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).
smegel 10y ago
Reading the comments here makes me realize it is probably better to come back in 12 months and observe what is still left standing.
kinga254 10y ago
Whose has used mithril and how does it compare to vue?

256 points by wanderer42 10y ago

elcct 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.
unculture 10y ago
You can use JSX if you like with Vue. The templating language, should you choose to use it, really is very simple though. It doesn't take more than an hour or so to get the hang of.
Jean-Philipe 10y ago
Well, display a list of things in JSX and Angular or Vue - I found the latter versions way more elegant. But YMMV.
kitd 10y ago
JSX is "new stuff" if you've come from Jade et al. Vue templating is much more like what pre-React frameworks use.
Touche 10y ago
> Why do they say their template system is simpler than JSX? JSX doesn't run in browsers.

medeas_crypt 10y ago

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 10y ago
Because they believe that a single language should be enough for developing web applications.
- medeas_crypt 10y ago
  Probably a fair enough perspective. I guess I just hate it. With a passion.
- BjoernKW 10y ago
  What became of "the best tool for the job"? I doubt the benefits of having a single language outweigh the effort put in just to replicate solid server-side environments existing today.
  - MatekCopatek 10y ago
    I know what you mean, but at some point in history you could say that for every programming language that wasn't the first one to dominate that specific domain.
    - BjoernKW 10y ago
      Absolutely and I'm not against innovation at all. The exercise of making JavaScript a valid server-side alternative often seems pointless, though. What's the benefit of JavaScript on the server side other than "one language"? Perl, Java, Spring, Ruby on Rails each offered significant benefits over what existed before. What does JavaScript on the server side do better than other solutions? There's the event loop and non-blocking behaviour but is that enough for most applications to justify using JavaScript on the server side?

hesarenu 10y ago

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.

unculture 10y ago
You can drop down to JSX or plain JS render functions with Vue if you like, but JSX (which brings with it all the potential complexity of JS) is harder for many people to understand. The constraints of a (very!) simple templating DSL make things easier to read in the long run.
- hesarenu 10y ago
  For me it's easier to understand the lifecycle then to learn methods to simply do a boolean check or loops. In that way vuejs is more complex.
arnorhs 10y ago
>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. I'm not familiar with the concept of simple js vs advanced js in react. But your statement about Vue's tags being its own dsl holds true for jsx as well.
- barrkel 10y ago
  JSX doesn't have control flow. Therein lies all the difference. Javascript's void-typed statements are a problem, though.
  - Touche 10y ago

Ciantic 10y ago

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 10y ago
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 10y ago
  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()..
bradrydzewski 10y ago
FWIW my understanding is the vuejs template language is based on an early version of the web component template specification (which might predate the jsx specification). You may therefore notice a good amount of overlap between vuejs templates and polymer, for example.
paulddraper 10y ago
> Why invent a new one and not use JSX? JSX is a new templating language too. It not standard; it not JavaScript.

mythz 10y ago

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.

progx 10y ago
I didn't use vue, but https://vuejs.org/guide/syntax.html https://vuejs.org/guide/syntax.html did not look so complicated. But you are right, i am not sure to use a template system again. But the advantage is cleaner code, many people change quickly to spaghetti code in jsx (mix all together, ifs, loops, ...).
- mythz 10y ago
  Spaghetti code refers to poor coupling not cohesive encapsulation or being able to build complex smart views which can easily be refactored using native programming language constructs. I'd much prefer having a single powerful language for everything instead of forced artificial friction on having to spread your component over multiple DSLs.

anonyfox 10y ago

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.

woah 10y ago
What does vue resource do that can't be done with fetch?
iotscale 10y ago
We use knockout at work but <p data-bind="if: foo">foo!</p> quickly turns into  <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>  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 10y ago
  You should consider using React with MobX. Similar concepts, but more powerful and mature.

k__ 10y ago

Is Vue fractal?

deleted 10y ago

[deleted]

Vozze 10y ago

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 10y ago
It's a "Competitor" to Angular.js, focusing on the web but with plans to go on android/ios like React Native eventually.

jgalt212 10y ago

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 10y ago
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.

Ruphin 10y ago

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 10y ago
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.

FrancoDiaz 10y ago

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

rk06 10y ago
As far html vs jsx goes, i would say its a matter of taste. But when it comes to css, vue's css are way better than React's alternative by a longshot.
reza_n 10y ago
As another reply mentions, its a matter of taste, but for me its the clean seperation between data and presentation. Presentation is generally HTML+CSS. Data and plumbing is JS. This is similar to traditional MVC and works well with mixed dev/designer teams. Dev in JS, design with HTML+CSS. You can liken it to a data API returning data with HTML in it, you now have data and presentation together. Do you want the 2 roles in 1 convenient language? Great, JSX gives you that power. Do you want data and presentation separate, then go with templates.
- eyko 10y ago
  Your component's logic is all presentation logic. You may want to break it even further but it's not a real separation (you still have logic in your templates via `v-if` and `v-for`, don't you?). Data, in both React and Vue, lives outside the component.
  - reza_n 10y ago

Tade0 10y ago

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.

taphangum 10y ago

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/

bikamonki 10y ago

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 10y ago
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 10y ago
  True...yet I am still not convinced about the clear advantages ;)
ieatkittens 10y ago
> Modern devices make it almost irrelevant. A todo list on an mbp, yes. A complex app on a tablet, not so much. > Yours is useless out of the box, to be used on a real complex app it needs...more dependencies. All Vue requires is vue.min.js and you're set. Adding routing and clean data flow out of the box is trivial. _But_ it is easy to end up with a massively over engined babel-webpack-flow-npm-flux meme stack, given the excellent vue cli. I am, of course, guilty of that myself.

nawitus 10y ago

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

d0m 10y ago

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 10y ago

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

rk06 10y ago
- 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.

franciscop 10y ago

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

smegel 10y ago

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

kinga254 10y ago

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