6 ms·

The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework. I understand that it's only an approx

The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework. I understand that it's only an approximation of the real thing, but they're clearly managing to at least get the core idea out there into real production systems. The Vue implementation seems to ultimately lack this core understanding, and comes off almost a bit cargo-cultish in comparison. React has hooks, so we must have something similar. I don't mean this as singularly bad, I'm certain Vue can be productive and that this can be a productive feature for Vue devs - but when will we as an industry manage to evaluate software by semantics rather than the syntax we prefer? Does Vue truly offer anything over React that's not in the realm of preferred syntax?

nickdandakis 7y ago
Preferred syntax should be enough, but here's a couple more differences: - Vue has a set of core libraries (Vuex, vue-router, etc) maintained by the same org. - Single file components with scoped styling out of the box. - Vue integration as a standalone runtime is a little easier than React (unsure about this one). You can read more about the differences here: https://vuejs.org/v2/guide/comparison.html#React https://vuejs.org/v2/guide/comparison.html#React I couldn't find any official comparison documentation from the React docs, though.
- ng12 7y ago
  > Single file components Honestly I think this is a step backwards. How many components my "component" is built out of should be an implementation detail.
  - zamalek 7y ago
    You're misinterpreting what an SFC is, it's just something like the following: <template>  </template> <script> // JS, TS, or whatever </script> <style scoped> /* CSS, LESS, SCSS or whatever */ </style> That components may use other components itself, no part of SFCs disallow that.
    - ng12 7y ago
      That's not what I'm saying. What if I have a child component I don't want to put in a separate file? What if I want a child component defined as a closure inside my parent component? What if I want one file that exports many components? React makes no judgements here -- it's completely up to me to decide what's best for my application.
      - cooperadymas 7y ago
        I don't think anything would stop you from creating multiple components in a file using 'Vue.Component' and a template string. I've never remotely wanted anything similar to this in Vue, but I have seen what you're talking about used in React, mostly for component wrappers to encapsulate logic. It's not something I like using or seeing but that could easily be swayed by my preference for Vue. See how it's done in the guide. It wouldn't be as natural as react allows but should suffice for tiny, contained sub components. https://vuejs.org/v2/guide/index.html#Composing-with-Components https://vuejs.org/v2/guide/index.html#Composing-with-Compone...
        ng12 7y ago
        > 'Vue.Component' and a template string. But the template string is just a string, right? Can you get the same IDE integration while avoiding SFCs?
        cooperadymas 7y ago
        At that point it should probably be its own SFC. But You can also override the render function, and even use JSX. https://vuejs.org/v2/guide/render-function.html#JSX https://vuejs.org/v2/guide/render-function.html#JSX
        adamwathan 7y ago
        > I've never remotely wanted anything similar to this in Vue, This was true of me as well until actually playing more with React. In practice, being able to very quickly extract a child component by just copying a chunk of code to a different spot in the same file is a very nice workflow benefit I now sorely miss when using Vue. In Vue my components tend to be larger and more complex than they are in React because I feel like some small extraction I want to make doesn't "deserve" it's own dedicated file, whereas in React I just quickly make a new function that returns some JSX and I'm done.
  - cooperadymas 7y ago
    It largely is an implementation detail. The official guide starts you off without them. You ostensibly could develop an entire application without touching SFC or using the vue cli. But they're such a well implemented pattern that you'll find almost no one in the wild avoiding them, which is pretty telling.
    - ng12 7y ago
      Correct me if I'm wrong but I imagine that's more for the tooling (e.g. syntax highlighting for my template and styles) than an actual preference for SFCs.
      - cooperadymas 7y ago
        Shrug. Maybe? I think Vue is popular enough that if people actually disliked SFCs once they started using Vue they you would see blog posts about how to avoid them, complaining that's why they're leaving Vue, or tooling that makes it easier to bypass them. I don't really see this so my assumption is devs generally like them once they start using them. I could certainly be proved wrong.
    - jplayer01 7y ago
      A bit tangential - I've been messing around with vuejs and Django recently (I'm not a web developer in the slightest) and I haven't found a decent way to get webpack integrated. So I can't use SFC or cli and I wonder how people do this in the real world. Do people even use vue with Django?
      - thefreeman 7y ago
        They are generally deployed separately. Django is used to build a rest API and webpack / Vue are deployed on their own to consume the API. You can put something like nginx in front to route API requests to Django and everything else to an s3 bucket for your single page app.
        jplayer01 7y ago
  - jimktrains2 7y ago
    It isn't? You don't have to define them in a single file. I prefer having the template, styles, and code together, but it isn't required.
- Rapzid 7y ago
  Wouldn't mind some other opinions on this but having used Mobx a lot in the past and starting to look at Vuex for current employer it's not looking enticing in comparison.. Mobx will work with Vuejs and I'm reading about a lot of people who have switched from vuex and been very happy. Considering just jumping in with Mobx and the bindings.. My and many others dev environments lean heavily on Vetur and it.. Is plagued with various issues in various releases. JSX/TSX JustWork™ while SPCs are okay sometimes but other times are found wanting..
jaequery 7y ago
"The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework" Is that a good thing?
acemarke 7y ago
I'm a complete React fanboy and fully engaged in the React ecosystem, but I'd like to speak up in Vue's defense here. Yes, there's some obvious copying going on here, but this is not a bad thing! There's been a lot of cross-pollination and inspiration between the major frameworks and ecosystems. While I haven't deeply inspected the exact details of the new Vue APIs, my understanding based on discussions is that the Vue team has heavily adapted the hooks APIs for a more Vue-idiomatic approach. This includes things like removing the need for the call order limitation, only calling them once on setup, making use of Vue's reactivity, and so on. Those changes fit well into Vue's stated focus on ease of use and handling a lot of behavior automatically. This gives the Vue community a chance to benefit from some of the same concepts and improvements that the React team has described for hooks, while staying with their same toolset. I'm entirely happy with React and have no plans to switch, but there's plenty of reasons for folks to choose Vue (and similarly, each of the other frameworks). I gave a list of some reasons why you might pick each of them a while back on Reddit [0]. [0] https://www.reddit.com/r/javascript/comments/avsuei/react_vs_vue_a_sidebyside_code_comparison/ehi6g1m/?context=3 https://www.reddit.com/r/javascript/comments/avsuei/react_vs...
- brlewis 7y ago
  More on the relationship between hooks and the proposed Composition API: https://vue-composition-api-rfc.netlify.com/#comparison-with-react-hooks https://vue-composition-api-rfc.netlify.com/#comparison-with...
- palerdot 7y ago
  Copying is a harsh word IMO. Vue has been liberal and open in quoting prior art, particularly from the React ecosystem. For example vuex[0] docs, actually quotes Dan Abramov regarding flux implementations for state management. [0] - https://vuex.vuejs.org/ https://vuex.vuejs.org/
  - bpicolo 7y ago
    Programming and open source is a massive ecosystem of making use of prior art and incorporating diverse ideas to make alternative, better, or more robust abstractions. That's the whole beauty of it. Very few things are entirely new.
lhorie 7y ago
Approximating Suspense to algebraic effects is a pet peeve of mine. Algebraic effects are more akin to DI or at best to using a generator than the throw-and-retry-everything hack that Suspense does. And to boot, that's not even necessarily the right abstraction (e.g. AFAIK multiple nested suspense things are still an open issue). I do agree that Vue seems to be reactive in its choice of features, in the sense that it tries to be everything to everyone. The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing. I feel like Angular is the one framework that sorta "gets it" now. It went all the way to CS lala-land w/ 1.x and rewrote from the ground up for v2 taking several lessons from its v1 and from elsewhere.
- brlewis 7y ago
  >The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing. Sounds like you want Mithril, but keep in mind that backward compatibility and marketability are, in fact, useful features.
  - lhorie 7y ago
    > backward compatibility and marketability are, in fact, useful features They are (and FWIW, the Stroustrup quote[1] is quite applicable here). I'm merely pointing out that feature creep leads to bloat/complexity which lead to people to complain, and that feature creep also leads to marketability (which is a reason why mainstream language spec documents typically have hundreds of pages). Personally I think this pattern is a problem, but I don't know if anyone has managed to figure out a solution. [1] https://www.goodreads.com/quotes/226225-there-are-only-two-kinds-of-languages-the-ones-people https://www.goodreads.com/quotes/226225-there-are-only-two-k...
    - brlewis 7y ago
apatheticonion 7y ago
The thing that I find most amusing about modern front end is the over-emphasis developers put on the rendering engine. Presentation is only a small portion of an application. A view rendering engine is required to do a couple of things, accept and render data. The semantics of how it accepts data enables good software engineering practices like dependency injection and dependency inversion. The semantics of how it renders data enable ergonomic usage of the renderer (templating, JSX). Modern web developers tend to write "React" or "Vue" applications - not "Type/JavaScript applications that render with React" Global objects, singletons fetched from module-powered service locators, unlimited power global stores and enough boilerplate to make the most hardened Java developer confess their sins to Oracle. Looks like Vue 3 is fine but continues the trend of doing it all.
- jakobloekke 7y ago
  This! But I find that a combination of Typescript, MobX and React brings me very close to a good place.
preommr 7y ago
> a wonderful job incorporating actual CS concepts like algebraic effects into their framework. What does "actual CS concepts" event mean? This is the first time in my life that I've heard about algebraic effects. If I am understanding your comments, the implication seems to be react is implementing concepts that elevate the tool while vue goes around in circles to make an alternative syntax. I don't even agree that the react team has done a good job with implementing a clear concept for their framework. Things like Elm have done a much better job of that. Granted that's a lot easier to do when they don't have to force themselves to deal with js directly. But even then, why is react implementing hooks not bad, but vue implementing them is? There's a reason why react made the switch, and some of those advantages also apply in vue. These changes aren't just made to follow trends.
- alipang 7y ago
  There's been an unfortunate trend in the JS world where a lot of frameworks are created, but without any real meaningful sense of progress, resulting in a sense of going around in cycles in various "reskins" with different syntax and conventions, all round some kind of core MVC idea. When I say "actual CS concepts" I mean things that have been broken down into it's core using a suitable mathematical model. This is ultimately a much more suitable way bo build tools used by engineers. My personal concerns is that Vue to me is mostly just a reskin with new syntax on things that are already in React. Hooks become the "composition api". Redux becomes VueX. Is this necessary? Could VueX just have been an alternative to Redux, like MobX is? Could we just have implemented a Webpack-loader to put styles and react components together? Some people don't like that React uses `className` instead of class. Is `v-bind:class` and various `@` notations really so much better we can justify a whole new ecosystem? So roughly - Vue provides fragmentation in the frontend ecosystem. I like competition - but what does it really offer that justifies it? I don't get it, and now what they have been working on is just catching up to React.
  - vcoelho 7y ago
    Well, I started with Angular and couldn't make any sense of it. It had two versions with huge differences between them and React offered a more concise path for learning. But I found JSX hard to read and there was no consensus on how to write CSS and some people were saying that it was ok to use inline styling. WTF? The web design community have been telling me the opposite for years! Then I started working with Vue and everything fallen in place: no deprecated lifecycles, CSS into style tag and easy to read markup with no Array.map() returning HTML tags. Fragmentation is bad, but is nice to have a balanced option between extremes.
al2o3cr 7y ago
TBH, React feels like what you get when a bunch of very smart devs decide to "incorporate actual CS concepts like algebraic effects" into showing people ads. Arguing that we should pick tools based on semantics without considering syntax is like arguing people should pick spouses based on genetics and not personality.
neya 7y ago
Have you used both? This is a comment I usually see from people who have used only one, but not the other. Let me give you some background about myself - I'm a full time consultant, I write both frontend and backend code for a living. I have worked for almost 27 companies in the last 2 years as a consultant. I have used both. Vue may copy react, but their implementation and opinionated code structure (Eg. Single file components, Vue-Router, Vuex, etc.) is so much better than the complete freedom that React gives you. Almost all of them who used React had terrible code quality and really bad code organization. In contrast, the Vue code base I've worked with all had some level of uniformity enough for an external consultant to come in and understand what was going in. The worst code I've ever seen till date was on React from an analytics firm. I lasted 15 seconds after which I closed the tab and re-negotiated the contract to do only backend for that firm. I'm not saying React is bad, end of the day, they're all just tools, but a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app. Especially for large codebases, this is so true when you work with stuff to manage state like Flux/Vuex. I also observed that companies using React usually also tend to do more re-writes of their codebases as it becomes unmaintainable over time without an opinionated way to do things like with Vue. Companies with Vue also seem to be more profitable and less reliant on VC money. You can feel free to verify these stats by heading over to LinkedIn/Angel.co and checkout the companies who hire for Vue/React. So, to answer your question - Does Vue truly offer anything over React that's not in the realm of preferred syntax? Definitely (as I explained above). I personally would never touch React for a prototype or a project that needs to go to market with less bugs.
- ng12 7y ago
  > a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app These would be almost identical in structure and design. You're drastically overstating the difference between React and Vue.
- aitchnyu 7y ago
  Picking your brain. Somehow React+Redux feels the stuff of horror stories. Which of React, React+Redux, Vue, Vue+Vuex will lead to the least disaster for a sloppy team?
nailer 7y ago
> The Vue implementation seems to ultimately lack this core understanding, and comes off almost a bit cargo-cultish in comparison. React has hooks, so we must have something similar. Aren't hooks only needed because React and Vue still use a virtual DOM?

nickdandakis 7y ago

Preferred syntax should be enough, but here's a couple more differences: - Vue has a set of core libraries (Vuex, vue-router, etc) maintained by the same org. - Single file components with scoped styling out of the box. - Vue integration as a standalone runtime is a little easier than React (unsure about this one). You can read more about the differences here: https://vuejs.org/v2/guide/comparison.html#React https://vuejs.org/v2/guide/comparison.html#React I couldn't find any official comparison documentation from the React docs, though.

ng12 7y ago
> Single file components Honestly I think this is a step backwards. How many components my "component" is built out of should be an implementation detail.
- zamalek 7y ago
  You're misinterpreting what an SFC is, it's just something like the following: <template>  </template> <script> // JS, TS, or whatever </script> <style scoped> /* CSS, LESS, SCSS or whatever */ </style> That components may use other components itself, no part of SFCs disallow that.
  - ng12 7y ago
    That's not what I'm saying. What if I have a child component I don't want to put in a separate file? What if I want a child component defined as a closure inside my parent component? What if I want one file that exports many components? React makes no judgements here -- it's completely up to me to decide what's best for my application.
    - cooperadymas 7y ago
      I don't think anything would stop you from creating multiple components in a file using 'Vue.Component' and a template string. I've never remotely wanted anything similar to this in Vue, but I have seen what you're talking about used in React, mostly for component wrappers to encapsulate logic. It's not something I like using or seeing but that could easily be swayed by my preference for Vue. See how it's done in the guide. It wouldn't be as natural as react allows but should suffice for tiny, contained sub components. https://vuejs.org/v2/guide/index.html#Composing-with-Components https://vuejs.org/v2/guide/index.html#Composing-with-Compone...
      - ng12 7y ago
        > 'Vue.Component' and a template string. But the template string is just a string, right? Can you get the same IDE integration while avoiding SFCs?
        cooperadymas 7y ago
        At that point it should probably be its own SFC. But You can also override the render function, and even use JSX. https://vuejs.org/v2/guide/render-function.html#JSX https://vuejs.org/v2/guide/render-function.html#JSX
      - adamwathan 7y ago
        > I've never remotely wanted anything similar to this in Vue, This was true of me as well until actually playing more with React. In practice, being able to very quickly extract a child component by just copying a chunk of code to a different spot in the same file is a very nice workflow benefit I now sorely miss when using Vue. In Vue my components tend to be larger and more complex than they are in React because I feel like some small extraction I want to make doesn't "deserve" it's own dedicated file, whereas in React I just quickly make a new function that returns some JSX and I'm done.
- cooperadymas 7y ago
  It largely is an implementation detail. The official guide starts you off without them. You ostensibly could develop an entire application without touching SFC or using the vue cli. But they're such a well implemented pattern that you'll find almost no one in the wild avoiding them, which is pretty telling.
  - ng12 7y ago
    Correct me if I'm wrong but I imagine that's more for the tooling (e.g. syntax highlighting for my template and styles) than an actual preference for SFCs.
    - cooperadymas 7y ago
      Shrug. Maybe? I think Vue is popular enough that if people actually disliked SFCs once they started using Vue they you would see blog posts about how to avoid them, complaining that's why they're leaving Vue, or tooling that makes it easier to bypass them. I don't really see this so my assumption is devs generally like them once they start using them. I could certainly be proved wrong.
  - jplayer01 7y ago
    A bit tangential - I've been messing around with vuejs and Django recently (I'm not a web developer in the slightest) and I haven't found a decent way to get webpack integrated. So I can't use SFC or cli and I wonder how people do this in the real world. Do people even use vue with Django?
    - thefreeman 7y ago
      They are generally deployed separately. Django is used to build a rest API and webpack / Vue are deployed on their own to consume the API. You can put something like nginx in front to route API requests to Django and everything else to an s3 bucket for your single page app.
      - jplayer01 7y ago
- jimktrains2 7y ago
  It isn't? You don't have to define them in a single file. I prefer having the template, styles, and code together, but it isn't required.
Rapzid 7y ago
Wouldn't mind some other opinions on this but having used Mobx a lot in the past and starting to look at Vuex for current employer it's not looking enticing in comparison.. Mobx will work with Vuejs and I'm reading about a lot of people who have switched from vuex and been very happy. Considering just jumping in with Mobx and the bindings.. My and many others dev environments lean heavily on Vetur and it.. Is plagued with various issues in various releases. JSX/TSX JustWork™ while SPCs are okay sometimes but other times are found wanting..

jaequery 7y ago

"The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework" Is that a good thing?

acemarke 7y ago

I'm a complete React fanboy and fully engaged in the React ecosystem, but I'd like to speak up in Vue's defense here. Yes, there's some obvious copying going on here, but this is not a bad thing! There's been a lot of cross-pollination and inspiration between the major frameworks and ecosystems. While I haven't deeply inspected the exact details of the new Vue APIs, my understanding based on discussions is that the Vue team has heavily adapted the hooks APIs for a more Vue-idiomatic approach. This includes things like removing the need for the call order limitation, only calling them once on setup, making use of Vue's reactivity, and so on. Those changes fit well into Vue's stated focus on ease of use and handling a lot of behavior automatically. This gives the Vue community a chance to benefit from some of the same concepts and improvements that the React team has described for hooks, while staying with their same toolset. I'm entirely happy with React and have no plans to switch, but there's plenty of reasons for folks to choose Vue (and similarly, each of the other frameworks). I gave a list of some reasons why you might pick each of them a while back on Reddit [0]. [0] https://www.reddit.com/r/javascript/comments/avsuei/react_vs_vue_a_sidebyside_code_comparison/ehi6g1m/?context=3 https://www.reddit.com/r/javascript/comments/avsuei/react_vs...

brlewis 7y ago
More on the relationship between hooks and the proposed Composition API: https://vue-composition-api-rfc.netlify.com/#comparison-with-react-hooks https://vue-composition-api-rfc.netlify.com/#comparison-with...
palerdot 7y ago
Copying is a harsh word IMO. Vue has been liberal and open in quoting prior art, particularly from the React ecosystem. For example vuex[0] docs, actually quotes Dan Abramov regarding flux implementations for state management. [0] - https://vuex.vuejs.org/ https://vuex.vuejs.org/
- bpicolo 7y ago
  Programming and open source is a massive ecosystem of making use of prior art and incorporating diverse ideas to make alternative, better, or more robust abstractions. That's the whole beauty of it. Very few things are entirely new.

lhorie 7y ago

Approximating Suspense to algebraic effects is a pet peeve of mine. Algebraic effects are more akin to DI or at best to using a generator than the throw-and-retry-everything hack that Suspense does. And to boot, that's not even necessarily the right abstraction (e.g. AFAIK multiple nested suspense things are still an open issue). I do agree that Vue seems to be reactive in its choice of features, in the sense that it tries to be everything to everyone. The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing. I feel like Angular is the one framework that sorta "gets it" now. It went all the way to CS lala-land w/ 1.x and rewrote from the ground up for v2 taking several lessons from its v1 and from elsewhere.

brlewis 7y ago
>The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing. Sounds like you want Mithril, but keep in mind that backward compatibility and marketability are, in fact, useful features.
- lhorie 7y ago
  > backward compatibility and marketability are, in fact, useful features They are (and FWIW, the Stroustrup quote[1] is quite applicable here). I'm merely pointing out that feature creep leads to bloat/complexity which lead to people to complain, and that feature creep also leads to marketability (which is a reason why mainstream language spec documents typically have hundreds of pages). Personally I think this pattern is a problem, but I don't know if anyone has managed to figure out a solution. [1] https://www.goodreads.com/quotes/226225-there-are-only-two-kinds-of-languages-the-ones-people https://www.goodreads.com/quotes/226225-there-are-only-two-k...
  - brlewis 7y ago

apatheticonion 7y ago

The thing that I find most amusing about modern front end is the over-emphasis developers put on the rendering engine. Presentation is only a small portion of an application. A view rendering engine is required to do a couple of things, accept and render data. The semantics of how it accepts data enables good software engineering practices like dependency injection and dependency inversion. The semantics of how it renders data enable ergonomic usage of the renderer (templating, JSX). Modern web developers tend to write "React" or "Vue" applications - not "Type/JavaScript applications that render with React" Global objects, singletons fetched from module-powered service locators, unlimited power global stores and enough boilerplate to make the most hardened Java developer confess their sins to Oracle. Looks like Vue 3 is fine but continues the trend of doing it all.

jakobloekke 7y ago
This! But I find that a combination of Typescript, MobX and React brings me very close to a good place.

preommr 7y ago

> a wonderful job incorporating actual CS concepts like algebraic effects into their framework. What does "actual CS concepts" event mean? This is the first time in my life that I've heard about algebraic effects. If I am understanding your comments, the implication seems to be react is implementing concepts that elevate the tool while vue goes around in circles to make an alternative syntax. I don't even agree that the react team has done a good job with implementing a clear concept for their framework. Things like Elm have done a much better job of that. Granted that's a lot easier to do when they don't have to force themselves to deal with js directly. But even then, why is react implementing hooks not bad, but vue implementing them is? There's a reason why react made the switch, and some of those advantages also apply in vue. These changes aren't just made to follow trends.

alipang 7y ago
There's been an unfortunate trend in the JS world where a lot of frameworks are created, but without any real meaningful sense of progress, resulting in a sense of going around in cycles in various "reskins" with different syntax and conventions, all round some kind of core MVC idea. When I say "actual CS concepts" I mean things that have been broken down into it's core using a suitable mathematical model. This is ultimately a much more suitable way bo build tools used by engineers. My personal concerns is that Vue to me is mostly just a reskin with new syntax on things that are already in React. Hooks become the "composition api". Redux becomes VueX. Is this necessary? Could VueX just have been an alternative to Redux, like MobX is? Could we just have implemented a Webpack-loader to put styles and react components together? Some people don't like that React uses `className` instead of class. Is `v-bind:class` and various `@` notations really so much better we can justify a whole new ecosystem? So roughly - Vue provides fragmentation in the frontend ecosystem. I like competition - but what does it really offer that justifies it? I don't get it, and now what they have been working on is just catching up to React.
- vcoelho 7y ago
  Well, I started with Angular and couldn't make any sense of it. It had two versions with huge differences between them and React offered a more concise path for learning. But I found JSX hard to read and there was no consensus on how to write CSS and some people were saying that it was ok to use inline styling. WTF? The web design community have been telling me the opposite for years! Then I started working with Vue and everything fallen in place: no deprecated lifecycles, CSS into style tag and easy to read markup with no Array.map() returning HTML tags. Fragmentation is bad, but is nice to have a balanced option between extremes.

al2o3cr 7y ago

TBH, React feels like what you get when a bunch of very smart devs decide to "incorporate actual CS concepts like algebraic effects" into showing people ads. Arguing that we should pick tools based on semantics without considering syntax is like arguing people should pick spouses based on genetics and not personality.

neya 7y ago

Have you used both? This is a comment I usually see from people who have used only one, but not the other. Let me give you some background about myself - I'm a full time consultant, I write both frontend and backend code for a living. I have worked for almost 27 companies in the last 2 years as a consultant. I have used both. Vue may copy react, but their implementation and opinionated code structure (Eg. Single file components, Vue-Router, Vuex, etc.) is so much better than the complete freedom that React gives you. Almost all of them who used React had terrible code quality and really bad code organization. In contrast, the Vue code base I've worked with all had some level of uniformity enough for an external consultant to come in and understand what was going in. The worst code I've ever seen till date was on React from an analytics firm. I lasted 15 seconds after which I closed the tab and re-negotiated the contract to do only backend for that firm. I'm not saying React is bad, end of the day, they're all just tools, but a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app. Especially for large codebases, this is so true when you work with stuff to manage state like Flux/Vuex. I also observed that companies using React usually also tend to do more re-writes of their codebases as it becomes unmaintainable over time without an opinionated way to do things like with Vue. Companies with Vue also seem to be more profitable and less reliant on VC money. You can feel free to verify these stats by heading over to LinkedIn/Angel.co and checkout the companies who hire for Vue/React. So, to answer your question - Does Vue truly offer anything over React that's not in the realm of preferred syntax? Definitely (as I explained above). I personally would never touch React for a prototype or a project that needs to go to market with less bugs.

ng12 7y ago
> a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app These would be almost identical in structure and design. You're drastically overstating the difference between React and Vue.
aitchnyu 7y ago
Picking your brain. Somehow React+Redux feels the stuff of horror stories. Which of React, React+Redux, Vue, Vue+Vuex will lead to the least disaster for a sloppy team?

nailer 7y ago

> The Vue implementation seems to ultimately lack this core understanding, and comes off almost a bit cargo-cultish in comparison. React has hooks, so we must have something similar. Aren't hooks only needed because React and Vue still use a virtual DOM?