8 ms·

As far as I can tell, Vue doesn't introduce anything new over other front end technologies. It's ironic developers who complain about React being the "new hotne

As far as I can tell, Vue doesn't introduce anything new over other front end technologies. It's ironic developers who complain about React being the "new hotness" turn to Vue. It's the same core concepts as Backbone, Knockout, Angular, Ember, and the countless private frameworks we've home-grown on top of jQuery in our front end jobs. This is highly stateful, object oriented, mutate-by-defualt, class based, imperative programming, with imperative DOM manual wirings, separate templates from view logic (probably the biggest sin), and programming by non-transferable conventions (v-model="todo", this.$parent.$emit). I don't even want to know the implicit magic that makes list.push() update the view (notice how the author of the article doesn't know either!), but this is again the same as all of the above. While I don't personally prefer any of the above style, the point is not a criticism, but to point out that fundamentally Vue doesn't seem to offer any different core concepts than other frameworks. I think it just hit a sweet spot timing of being a React competitor, when developers who didn't like (or, I suspect, don't fully understand) React's fundamentally paradigm and convention shift. As a biased pattern match, most times I see people comparing React to Vue, they're new to both, and don't get React. I'm biased, but I'm biased through experience. Building Backbone apps where you glue events to DOMs written in strings with magic stateful data classes, and then scaling and debugging those apps, _sucked_. We didn't know any better back then, though, because we didn't have React to compare it too. React can introduce problems (like any framework), but instead of trying to jump through hoops of convention, custom data binding and HTML tags, now my problems are my own. They're problems of composing functions or structuring my data flow. React is so thin that it's rare to have a "React" problem, now I have vanilla "Javascript" or even "function" problems, and it's such a breath of fresh air. Even when I'm debugging performance problems, I don't feel like I'm dealing with React, I'm dealing with comparing Javascript objects.

cageface 8y ago
Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. I understand why people feel overwhelmed with the whole React/Redux/Router/Saga stack but you really don't need most of that when you're just getting started and React itself is quite simple and elegant.
- no1youknowz 8y ago
  > Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential. I've been coding since '02-ish. When I code with Vue, I have an App Developer mindset, rather than a web developer jQuery mindset. When I use an attribute, it's just referencing a variable. It reacts to its own state in real-time. I'm not the best at explaining. But with a legacy mindset, you have to interact with the DOM in some way. Whereas with HTML attributes in Vue, you can use the state in the local component to determine whether something is shown or even if a particular class is shown depending on what the state is of a variable. Even better, that could be a computed variable or one that's watched. This functionality allows a bit of logic to then be run to determine how that variable behaves. This alone minimises the code I need to write in terms of legacy applications. Which also leads to less bugs. Using if, for, show, and binding classes are very very powerful. I rarely interact with the DOM now and everything in state that is complex is an array. I can write way more complex apps with Vue, than I ever could with jQuery. About the examples given here by the developer. You can still see that he's coding with a legacy mindset and that he hasn't internalised a lot of what Vue offers. Some minor nitpicks: - No need for this.$parent.$emit. There is a better way to use $emit. - this.$on. <- What is this? An Event Bus? This should really have been a method. - No need to use id attributes at all. - Why not pass in the index attribute (which he is not using) to the delete function and then he can simply splice the array? If he wanted to be real flash. He could have written the ToDo component as a JSX render function and taken the array from the parent and looped out the list. I know the Vue community looks down on it, but would have been a better way of going. I don't really want to seem like I'm crapping over this. I'm not. I've only been using Vue since April myself. But there seems to be a lot of mistakes here and it's just not idiomatic.
  - sunilsandhu 8y ago
    Hi there - Thank you for taking the time to read and review, I really appreciate it. I wondered whether you would be interested in making an update to the git repository with the suggestions you have made. I'd be more than happy to update the article and credit you for your input. If so, the link can be found at: https://github.com/sunil-sandhu/vue-todo https://github.com/sunil-sandhu/vue-todo As an aside, I thought I'd let you know that I've been a developer for just under one year, so admittedly do not have anywhere near the level of expertise that you have. I've also only been using Vue since April, but I guess that my level of overall experience, relative to yours, is lacking somewhat.
koboll 8y ago
React is certainly more elegant than Vue. But for me, the key question is which allows me to build faster. Does elegance mean I will spend so much less time fixing bugs that this benefit outweighs the much smaller amount of boilerplate required to put an app together in Vue? I don't really think so, but I haven't come to a firm conclusion either way yet.
- no1youknowz 8y ago
  > React is certainly more elegant than Vue. It's also slightly more powerful. - It has more functionality when it comes to JSX. - It handles reactivity better. However, judging the comments by Evan in Mays webcast. He mentions these two will be resolved by 2.6, 2.6-next. I think the gap will be closed somewhat.
  - cztomsik 8y ago
    Actually, you can do jsx in vue. So it should be on par, except it has mobx-like state management built-in.
    - no1youknowz 8y ago
      > Actually, you can do jsx in vue. Never said you could not. The difference is that React is way more powerful and easier when building complex applications with JSX. With Vue. I have a functional component that renders out JSX templates 6 levels deep and other DOM elements on-demand. All from a single multi-dimensional array. In terms of the code count and simplicity. You couldn't achieve the same result with Single File Components so JSX to the rescue. But I'm sure someone could with SFC, but it would be such an over-engineered mess, it would be counter intuitive. It was seriously difficult compared to what React offers because the functionality for Vue just isn't there. But I am sure in time, the functionality will be there. Starting with Vue 2.6/2.6-next.
vmware505 8y ago
I still prefer Ember.js, it is the only one which is focus on developer happiness, and corporate friendly, ideal for big teams. Modern, fast, lightweight, and easy to learn: www.emberjs.com, www.yoember.com
bryanrasmussen 8y ago
backbone was pretty thin, but you seem to imply you might have had backbone problems?
munchbunny 8y ago
I agree with you for most of that, though I have definitely run into cases of "React" as a paradigm getting in the way. I'd love if someone here has a good solution. The inherent problem I run into with React is that it's "context-less", in the sense that the "React way of thinking" makes it hard to represent things like animations where you care about the previous state and how you got there. So in my case, I'm doing a multiplayer boardgame. Someone plays a card, I want to animate the card getting pulled from one deck and shuffled into another. The best solution I've found so far is to add extra "annotations" (using terms loosely) into the current "board state" that represents the changes that happened, and that allows me to queue up the necessary animations. But that feels clumsy because it means persisting stateful data into the data structure alongside the actual "pure board state".
- pnloyd 8y ago
  Well without knowing the specifics of your use case, the two most practical react packages for animation I've used have been react-move and CssTransitionGroup. They both work on the principle of toggling the animation based on a property "show". It's pretty great!
inopinatus 8y ago
It’s not owned by a reprehensible consumer surveillance utility. That is 50% of why I chose Vue. The other half is also programmer happiness, due to impedance matching with Rails.
- anonytrary 8y ago
  > It’s not owned by a reprehensible consumer surveillance utility I don't like Facebook that much either, but that doesn't mean they don't write useful software. > The other half is also programmer happiness, due to impedance matching with Rails. So impedance matching with a limited technology is a good thing? I find that to be... a limitation.
  - inopinatus 8y ago
    Utility does not improve ethics, which is why making the trains run on time did not excuse Italian fascism. Choosing React is to condone its owner.
    - ncmncm 8y ago
      Fascist trains didn't really run on time. It is just that nobody could say they didn't. But, yes, utility is poorly correlated with ethics, at least in the short term. Longer term, maybe not. Ethical failure has a way of gumming up communication paths.
guru4consulting 8y ago
> separate templates from view logic (probably the biggest sin) Can you please explain a bit more on this?
Aeolun 8y ago
Vue doesn't really introduce anything we haven't seen before indeed. Fortunately it doesn't regress from what we have learned before either. The most important factor in favor of Vue however, is that it 'just works'. When working in the reaction ecosystem I feel like I'm constantly trying to couple together chains that call functions on functions on objects. Then there's the components that have bugs that make them fail in the most basic of situations. And lastly I have to write 3 times as much code to get all of it even running. Give me Vue and it's magic any time of the day.
- mmanfrin 8y ago
  When working in the [react] ecosystem I feel like I'm constantly trying to couple together chains that call functions on functions on objects. This is a very good explanation of how I feel as well. At work I use React, but on sideprojects I'm a Vue fan. React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about. Vue feels like it compartmentalizes things much more effectively. A component can just be a component, not a stateless function that renders a react component that wraps around a redux plugin component, with each step having its own little isolated DSL.
  - anonytrary 8y ago
    > React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about This is like saying recursion is hard to reason about because you're dealing with a function which calls itself then calls itself then calls itself and there are layers and layers of calling itself with chains of arguments passed down through the many layers. > a stateless function that renders a react component that wraps around a redux plugin component IMO React's recursion makes it much easier to reason about than something imperative like Vue, while its function composition enable powerful patterns for reusing logic.
    - sametmax 8y ago
      Recursion is hard to reason about. As a teacher, it's one of the first concepts my students have a hard time with.
nicostouch 8y ago
"I'm biased, but I'm biased through experience" BAZINGA!
anonytrary 8y ago
> hit a sweet spot timing of being a React competitor, when developers who didn't like (or, I suspect, don't fully understand) React's fundamentally paradigm and convention shift React is elegant and simple and I think most people understood it. I think they were less excited about the licensing, which was probably responsible for things like Vue and Preact. Personally I don't like Vue -- the "magic data" is touted as a plus, but IMHO it's room for confusion. At least when I setState in react, I can see the function call to "setState" implying I'm queueing a reactive change.
luord 8y ago
> separate templates from view logic (probably the biggest sin) Not a sin. > or, I suspect, don't fully understand Your suspicion is wrong and so pointless I'm shocked this comment became the top one for this thread. Usually, pointlessly provocative stuff gets downvoted, as it should. > React's fundamentally paradigm and convention shift. You mean the paradigm shift of mixing HTML and JavaScript in the same hodgepodge? That's what we moved away from in the first place. React brought it back and many people convinced themselves that now it should work. > React is so thin that it's rare to have a "React" problem, now I have vanilla "Javascript" or even "function" problems Ah, this explains it. So deep into the... I don't want to say fanaticism but I can't think of another word, that there's even a preemptive rationalization of the technology's problems. And this comes from someone who, over the last two years of experience, has taught himself to stop hating react by sheer force of will.
- sanderjd 8y ago
  > You mean the paradigm shift of mixing HTML and JavaScript in the same hodgepodge? Are you talking about JSX? If so, this doesn't ring true to me; it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. I've personally always found that really weird, but it isn't a hodgepodge, it's just normal javascript function calls with a weird syntax.
  - luord 8y ago
    > it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. This is a distinction without a difference. The point is that putting HTML and JS logic in the same file is what was usually done in the early days of programming on the web, before separating code from event attributes into their own script tags and files became the norm. All JSX does is the exact same mix in the opposite direction: it's not about JS inside HTML; it's HTML inside JS. And I understand that that's fine for many people -- and I've learned to stop caring -- but I take issue with pretending that it's a "paradigm shift".
    - sanderjd 8y ago
ppseafield 8y ago
> It's the same core concepts as ... I agree that it feels similar to those frameworks. I'm not put off by that because it's a framework that's clearly learned from all of the above and refined the forumla. > This is highly stateful, object oriented, mutate-by-defualt, class based, imperative programming, with imperative DOM manual wirings Vuex is a state management library similar to Redux which you can use to structure your app. Vue now has functional components, and there are libraries that let you process form data entirely from the store. Have you never used $refs in React code? That's about as manual as I've seen Vue wiring get... > separate templates from view logic (probably the biggest sin) I think this is more a matter of taste. I really like that .vue files let you specify things like the kind of style loader (css/sass/less), script type, etc. Everything's still in one file, but each part is separate. I think (if ? then : else) stacked multiple levels in JSX looks pretty ugly. :) > v-model="todo", this.$parent.$emit v-model is just sugar for something like v-bind:value="todo" v-on:input="setTodo", which provides an initial value and makes a simple function that sets the component's todo property, similar to how you might call this.setState({...}) with React. I was put off by this.$parent.$emit as well. You can simply pass the delete function as a prop in Vue as well, which is what I would do. > implicit magic that makes list.push() update the view This part is a little bit magic, but of course you could use Vuex for a more complex application. I was under the impression that excessive use of the analogous this.setState is frowned upon - am I wrong? Doesn't it do a bit of its own magic as well? > While I don't personally prefer any of the above style, the point is not a criticism, but to point out that fundamentally Vue doesn't seem to offer any different core concepts than other frameworks. Vue.js, Vuex, and Vue-Router are all maintained and released by a core team that coordinate changes. They all have pretty good documentation. I don't feel like Vue is fighting Javascript. I feel like there's usually an obvious way to do what you want to do most of the time. Nuxt.js (built on Vue) is incredibly simple to set up and offers an app skeleton, express templates, SSR, automatic rendering and plenty more. > React's fundamentally paradigm and convention shift... [...] As a biased pattern match, most times I see people comparing React to Vue, they're new to both, and don't get React. I had done a lot of messy jQuery stuff starting around 2006 or so. I played around with Backbone for a bit on the side, but found it messy. I tried to get into Angular 1 but found it overly complicated for little reward. I tried multiple times to get into React, but (and maybe this is less true now) after you choose the view layer, you still have to put together the rest. I like functional components, explicit state management, and Vue + Vuex has those. I don't mind template syntax - I prefer it separated out into its own concern. It's not revolutionary, but I think it provides a solid, sensible foundation. > Building Backbone apps where you glue events to DOMs written in strings with magic stateful data classes... I've used Backbone some myself, and I agree that event handling is just plain messy. I don't have this problem writing Vue code. Re: your last paragraph I rarely feel like I have a Vue problem because usually the way to do something is obvious. And when I do the errors are usually understandable, and Vue Dev Tools browser plugin is excellent. You can easily pick apart your app and Vuex state with it.
dotancohen 8y ago
> As far as I can tell, Vue doesn't introduce anything new over other front end technologies. That's what is great about Vue. It consolidates all the idiosyncrasies of the countless private frameworks that we've home-grown, and presents their features in a standard fashion that we can use across jobs. We can look at other people's code and understand it. It's exactly what experienced front-end developers do when they do it their way.

cageface 8y ago

Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. I understand why people feel overwhelmed with the whole React/Redux/Router/Saga stack but you really don't need most of that when you're just getting started and React itself is quite simple and elegant.

no1youknowz 8y ago
> Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential. I've been coding since '02-ish. When I code with Vue, I have an App Developer mindset, rather than a web developer jQuery mindset. When I use an attribute, it's just referencing a variable. It reacts to its own state in real-time. I'm not the best at explaining. But with a legacy mindset, you have to interact with the DOM in some way. Whereas with HTML attributes in Vue, you can use the state in the local component to determine whether something is shown or even if a particular class is shown depending on what the state is of a variable. Even better, that could be a computed variable or one that's watched. This functionality allows a bit of logic to then be run to determine how that variable behaves. This alone minimises the code I need to write in terms of legacy applications. Which also leads to less bugs. Using if, for, show, and binding classes are very very powerful. I rarely interact with the DOM now and everything in state that is complex is an array. I can write way more complex apps with Vue, than I ever could with jQuery. About the examples given here by the developer. You can still see that he's coding with a legacy mindset and that he hasn't internalised a lot of what Vue offers. Some minor nitpicks: - No need for this.$parent.$emit. There is a better way to use $emit. - this.$on. <- What is this? An Event Bus? This should really have been a method. - No need to use id attributes at all. - Why not pass in the index attribute (which he is not using) to the delete function and then he can simply splice the array? If he wanted to be real flash. He could have written the ToDo component as a JSX render function and taken the array from the parent and looped out the list. I know the Vue community looks down on it, but would have been a better way of going. I don't really want to seem like I'm crapping over this. I'm not. I've only been using Vue since April myself. But there seems to be a lot of mistakes here and it's just not idiomatic.
- sunilsandhu 8y ago
  Hi there - Thank you for taking the time to read and review, I really appreciate it. I wondered whether you would be interested in making an update to the git repository with the suggestions you have made. I'd be more than happy to update the article and credit you for your input. If so, the link can be found at: https://github.com/sunil-sandhu/vue-todo https://github.com/sunil-sandhu/vue-todo As an aside, I thought I'd let you know that I've been a developer for just under one year, so admittedly do not have anywhere near the level of expertise that you have. I've also only been using Vue since April, but I guess that my level of overall experience, relative to yours, is lacking somewhat.

koboll 8y ago

React is certainly more elegant than Vue. But for me, the key question is which allows me to build faster. Does elegance mean I will spend so much less time fixing bugs that this benefit outweighs the much smaller amount of boilerplate required to put an app together in Vue? I don't really think so, but I haven't come to a firm conclusion either way yet.

no1youknowz 8y ago
> React is certainly more elegant than Vue. It's also slightly more powerful. - It has more functionality when it comes to JSX. - It handles reactivity better. However, judging the comments by Evan in Mays webcast. He mentions these two will be resolved by 2.6, 2.6-next. I think the gap will be closed somewhat.
- cztomsik 8y ago
  Actually, you can do jsx in vue. So it should be on par, except it has mobx-like state management built-in.
  - no1youknowz 8y ago
    > Actually, you can do jsx in vue. Never said you could not. The difference is that React is way more powerful and easier when building complex applications with JSX. With Vue. I have a functional component that renders out JSX templates 6 levels deep and other DOM elements on-demand. All from a single multi-dimensional array. In terms of the code count and simplicity. You couldn't achieve the same result with Single File Components so JSX to the rescue. But I'm sure someone could with SFC, but it would be such an over-engineered mess, it would be counter intuitive. It was seriously difficult compared to what React offers because the functionality for Vue just isn't there. But I am sure in time, the functionality will be there. Starting with Vue 2.6/2.6-next.

vmware505 8y ago

I still prefer Ember.js, it is the only one which is focus on developer happiness, and corporate friendly, ideal for big teams. Modern, fast, lightweight, and easy to learn: www.emberjs.com, www.yoember.com

bryanrasmussen 8y ago

backbone was pretty thin, but you seem to imply you might have had backbone problems?

munchbunny 8y ago

I agree with you for most of that, though I have definitely run into cases of "React" as a paradigm getting in the way. I'd love if someone here has a good solution. The inherent problem I run into with React is that it's "context-less", in the sense that the "React way of thinking" makes it hard to represent things like animations where you care about the previous state and how you got there. So in my case, I'm doing a multiplayer boardgame. Someone plays a card, I want to animate the card getting pulled from one deck and shuffled into another. The best solution I've found so far is to add extra "annotations" (using terms loosely) into the current "board state" that represents the changes that happened, and that allows me to queue up the necessary animations. But that feels clumsy because it means persisting stateful data into the data structure alongside the actual "pure board state".

pnloyd 8y ago
Well without knowing the specifics of your use case, the two most practical react packages for animation I've used have been react-move and CssTransitionGroup. They both work on the principle of toggling the animation based on a property "show". It's pretty great!

inopinatus 8y ago

It’s not owned by a reprehensible consumer surveillance utility. That is 50% of why I chose Vue. The other half is also programmer happiness, due to impedance matching with Rails.

anonytrary 8y ago
> It’s not owned by a reprehensible consumer surveillance utility I don't like Facebook that much either, but that doesn't mean they don't write useful software. > The other half is also programmer happiness, due to impedance matching with Rails. So impedance matching with a limited technology is a good thing? I find that to be... a limitation.
- inopinatus 8y ago
  Utility does not improve ethics, which is why making the trains run on time did not excuse Italian fascism. Choosing React is to condone its owner.
  - ncmncm 8y ago
    Fascist trains didn't really run on time. It is just that nobody could say they didn't. But, yes, utility is poorly correlated with ethics, at least in the short term. Longer term, maybe not. Ethical failure has a way of gumming up communication paths.

guru4consulting 8y ago

> separate templates from view logic (probably the biggest sin) Can you please explain a bit more on this?

Aeolun 8y ago

Vue doesn't really introduce anything we haven't seen before indeed. Fortunately it doesn't regress from what we have learned before either. The most important factor in favor of Vue however, is that it 'just works'. When working in the reaction ecosystem I feel like I'm constantly trying to couple together chains that call functions on functions on objects. Then there's the components that have bugs that make them fail in the most basic of situations. And lastly I have to write 3 times as much code to get all of it even running. Give me Vue and it's magic any time of the day.

mmanfrin 8y ago
When working in the [react] ecosystem I feel like I'm constantly trying to couple together chains that call functions on functions on objects. This is a very good explanation of how I feel as well. At work I use React, but on sideprojects I'm a Vue fan. React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about. Vue feels like it compartmentalizes things much more effectively. A component can just be a component, not a stateless function that renders a react component that wraps around a redux plugin component, with each step having its own little isolated DSL.
- anonytrary 8y ago
  > React feels like layers and layers of render functions, with chains passed down and pared down as you get deeper, which becomes excessively cumbersome to reason about This is like saying recursion is hard to reason about because you're dealing with a function which calls itself then calls itself then calls itself and there are layers and layers of calling itself with chains of arguments passed down through the many layers. > a stateless function that renders a react component that wraps around a redux plugin component IMO React's recursion makes it much easier to reason about than something imperative like Vue, while its function composition enable powerful patterns for reusing logic.
  - sametmax 8y ago
    Recursion is hard to reason about. As a teacher, it's one of the first concepts my students have a hard time with.

nicostouch 8y ago

"I'm biased, but I'm biased through experience" BAZINGA!

anonytrary 8y ago

> hit a sweet spot timing of being a React competitor, when developers who didn't like (or, I suspect, don't fully understand) React's fundamentally paradigm and convention shift React is elegant and simple and I think most people understood it. I think they were less excited about the licensing, which was probably responsible for things like Vue and Preact. Personally I don't like Vue -- the "magic data" is touted as a plus, but IMHO it's room for confusion. At least when I setState in react, I can see the function call to "setState" implying I'm queueing a reactive change.

luord 8y ago

> separate templates from view logic (probably the biggest sin) Not a sin. > or, I suspect, don't fully understand Your suspicion is wrong and so pointless I'm shocked this comment became the top one for this thread. Usually, pointlessly provocative stuff gets downvoted, as it should. > React's fundamentally paradigm and convention shift. You mean the paradigm shift of mixing HTML and JavaScript in the same hodgepodge? That's what we moved away from in the first place. React brought it back and many people convinced themselves that now it should work. > React is so thin that it's rare to have a "React" problem, now I have vanilla "Javascript" or even "function" problems Ah, this explains it. So deep into the... I don't want to say fanaticism but I can't think of another word, that there's even a preemptive rationalization of the technology's problems. And this comes from someone who, over the last two years of experience, has taught himself to stop hating react by sheer force of will.

sanderjd 8y ago
> You mean the paradigm shift of mixing HTML and JavaScript in the same hodgepodge? Are you talking about JSX? If so, this doesn't ring true to me; it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. I've personally always found that really weird, but it isn't a hodgepodge, it's just normal javascript function calls with a weird syntax.
- luord 8y ago
  > it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. This is a distinction without a difference. The point is that putting HTML and JS logic in the same file is what was usually done in the early days of programming on the web, before separating code from event attributes into their own script tags and files became the norm. All JSX does is the exact same mix in the opposite direction: it's not about JS inside HTML; it's HTML inside JS. And I understand that that's fine for many people -- and I've learned to stop caring -- but I take issue with pretending that it's a "paradigm shift".
  - sanderjd 8y ago

ppseafield 8y ago

> It's the same core concepts as ... I agree that it feels similar to those frameworks. I'm not put off by that because it's a framework that's clearly learned from all of the above and refined the forumla. > This is highly stateful, object oriented, mutate-by-defualt, class based, imperative programming, with imperative DOM manual wirings Vuex is a state management library similar to Redux which you can use to structure your app. Vue now has functional components, and there are libraries that let you process form data entirely from the store. Have you never used $refs in React code? That's about as manual as I've seen Vue wiring get... > separate templates from view logic (probably the biggest sin) I think this is more a matter of taste. I really like that .vue files let you specify things like the kind of style loader (css/sass/less), script type, etc. Everything's still in one file, but each part is separate. I think (if ? then : else) stacked multiple levels in JSX looks pretty ugly. :) > v-model="todo", this.$parent.$emit v-model is just sugar for something like v-bind:value="todo" v-on:input="setTodo", which provides an initial value and makes a simple function that sets the component's todo property, similar to how you might call this.setState({...}) with React. I was put off by this.$parent.$emit as well. You can simply pass the delete function as a prop in Vue as well, which is what I would do. > implicit magic that makes list.push() update the view This part is a little bit magic, but of course you could use Vuex for a more complex application. I was under the impression that excessive use of the analogous this.setState is frowned upon - am I wrong? Doesn't it do a bit of its own magic as well? > While I don't personally prefer any of the above style, the point is not a criticism, but to point out that fundamentally Vue doesn't seem to offer any different core concepts than other frameworks. Vue.js, Vuex, and Vue-Router are all maintained and released by a core team that coordinate changes. They all have pretty good documentation. I don't feel like Vue is fighting Javascript. I feel like there's usually an obvious way to do what you want to do most of the time. Nuxt.js (built on Vue) is incredibly simple to set up and offers an app skeleton, express templates, SSR, automatic rendering and plenty more. > React's fundamentally paradigm and convention shift... [...] As a biased pattern match, most times I see people comparing React to Vue, they're new to both, and don't get React. I had done a lot of messy jQuery stuff starting around 2006 or so. I played around with Backbone for a bit on the side, but found it messy. I tried to get into Angular 1 but found it overly complicated for little reward. I tried multiple times to get into React, but (and maybe this is less true now) after you choose the view layer, you still have to put together the rest. I like functional components, explicit state management, and Vue + Vuex has those. I don't mind template syntax - I prefer it separated out into its own concern. It's not revolutionary, but I think it provides a solid, sensible foundation. > Building Backbone apps where you glue events to DOMs written in strings with magic stateful data classes... I've used Backbone some myself, and I agree that event handling is just plain messy. I don't have this problem writing Vue code. Re: your last paragraph I rarely feel like I have a Vue problem because usually the way to do something is obvious. And when I do the errors are usually understandable, and Vue Dev Tools browser plugin is excellent. You can easily pick apart your app and Vuex state with it.

dotancohen 8y ago

> As far as I can tell, Vue doesn't introduce anything new over other front end technologies. That's what is great about Vue. It consolidates all the idiosyncrasies of the countless private frameworks that we've home-grown, and presents their features in a standard fashion that we can use across jobs. We can look at other people's code and understand it. It's exactly what experienced front-end developers do when they do it their way.