Why I left React for Vue(blog.sourcerer.io)
blog.sourcerer.io
Why I left React for Vue
https://blog.sourcerer.io/why-you-should-leave-react-for-vue-and-never-use-it-again-5e274bef27c2
82 comments
And benchmarks don’t tell the whole story.. the React devs have made it clear that they don’t optimize for benchmarks where you insert / delete a ton of rows, but instead for fluid user experience. There’s more to performance than editing rows.
And the numbers in that table are close enough to be meaningless anyways
And yes, Fiber is gonna be the bees knees
And the numbers in that table are close enough to be meaningless anyways
And yes, Fiber is gonna be the bees knees
The numbers are close enough to be meaningless, as is the benchmark. Your users won't be able to read 10 rows in the difference in time it is from react to vue's rendered rows, much less 10,000...
I've never used vue but that v-if thing looks like a terrible idea to me. I want my javascript to look like javascript, not hidden in the attribute of an html component... v-if is less readable imho
With React I feel like I am writing Javascript in a nice functional style and I get to use all the cool new JS features.
with Vue I am writing ..Vue which does not feel right coming from a heavy Javascript background.
My bias is that I've written a ton of embedded Javascript(old Spidermonkey) for embedded devices.
I hear that Vue is more popular for those who have less JS experience.
with Vue I am writing ..Vue which does not feel right coming from a heavy Javascript background.
My bias is that I've written a ton of embedded Javascript(old Spidermonkey) for embedded devices.
I hear that Vue is more popular for those who have less JS experience.
When I first started dabbling in front end code about 3 years ago, Vue really was easier for me to jump into. But part of that was the react didn't really have the simplest tutorials or articles on making a simple stupid page in the way that made logical sense to me.
Everything started with "Start with your webpack file" and I wanted to just swear off front end forever.
So vue was a breath of fresh air at the time. Then I started at a company where react was the norm and I can't imagine going back to vue at this point.
Everything started with "Start with your webpack file" and I wanted to just swear off front end forever.
So vue was a breath of fresh air at the time. Then I started at a company where react was the norm and I can't imagine going back to vue at this point.
> He could have written an if statement
Yes that's where the article lost me. It's almost as if the author is trying to intentionally use non obvious syntax in JS to show the other framework in a better light.
Funny, I’ved used react and agree with everything in the article.
It is. What where the top reasons for liking Vue more? Or it is it more a generic thing?
>The conditional in react is just pure JS.
Who cares? You still write a JS conditional in the v-if string, right?
Who cares? You still write a JS conditional in the v-if string, right?
That gets messy fast though. You start having to escape strings in your code, and potentially have a trickier time with autocompletion etc.
then write a method for it.
Instead of v-if="currentUser && currentUser.id && ..." you can just write v-if="canDoStuff(currentUser)"
Instead of v-if="currentUser && currentUser.id && ..." you can just write v-if="canDoStuff(currentUser)"
> Who cares?
Me. As a CTO I am not confortable having significant amounts of code embedded in strings inside html attributes. Also we use Flow / Typescript.
React is typesafe and sound. No templates, no strings, just functions. This is the basis of the pyramids of developer's needs.
Me. As a CTO I am not confortable having significant amounts of code embedded in strings inside html attributes. Also we use Flow / Typescript.
React is typesafe and sound. No templates, no strings, just functions. This is the basis of the pyramids of developer's needs.
> This is the basis of the pyramids of developer's needs.
Apparently not though, thousands of people use Angular, even more people use VueJS now.
Apparently not though, thousands of people use Angular, even more people use VueJS now.
> thousands of people
Animals*. Not people, FTFY.
Joke aside though, I think this is an artifact of old school web development, which was a mess. People didn’t mind these kinds of hacks. But the number of people willing to accept such incongruities is going to go down in the next years as web development has now normalized into more sane practices that are standard in the software development world.
Animals*. Not people, FTFY.
Joke aside though, I think this is an artifact of old school web development, which was a mess. People didn’t mind these kinds of hacks. But the number of people willing to accept such incongruities is going to go down in the next years as web development has now normalized into more sane practices that are standard in the software development world.
I just can't get behind ` <div v-if="unreadMessages.length > 0">` after years of React. At least with React it is pure JS/TS - No magic.
However I must admit, the css story within vue is more interesting than React and its collection of CSS-IN-JS libraries.
However I must admit, the css story within vue is more interesting than React and its collection of CSS-IN-JS libraries.
Going to have to disagree with the comment on CSS-in-JS.
CSS-in-JS is one of my favorite parts of the React ecosystem. Style as a function of state is such a natural extension to React's programming model that I end up cringing a bit every time I have to go back to writing a bunch of different classes and applying them conditionally. Representing styles as data also means you have the full power of JavaScript at your disposal to compose and manipulate styles (not to mention access to a proper module system), whereas with plain CSS you're limited to a handful of mixins offered by whatever post-processor you choose, and those in turn are generally limited in terms of expressiveness themselves by nature of only being able to perform simple string interpolations, since that's the format they have to deal with.
I think these benefits are analogous to the benefits of HTML-in-JS a la JSX over traditional JS-in-HTML templates. I'm honestly struggling to see why someone would prefer HTML-in-JS but not CSS-in-JS.
CSS-in-JS is one of my favorite parts of the React ecosystem. Style as a function of state is such a natural extension to React's programming model that I end up cringing a bit every time I have to go back to writing a bunch of different classes and applying them conditionally. Representing styles as data also means you have the full power of JavaScript at your disposal to compose and manipulate styles (not to mention access to a proper module system), whereas with plain CSS you're limited to a handful of mixins offered by whatever post-processor you choose, and those in turn are generally limited in terms of expressiveness themselves by nature of only being able to perform simple string interpolations, since that's the format they have to deal with.
I think these benefits are analogous to the benefits of HTML-in-JS a la JSX over traditional JS-in-HTML templates. I'm honestly struggling to see why someone would prefer HTML-in-JS but not CSS-in-JS.
It's funny to hear people debate CSS in JS vs. templates, etc. For me, the answer is none of the above.
That is, all of these frameworks are underpinned by a certain awfulness that is born of the impedance mismatch between applications vs Web. The right framework would abstract away CSS, templating, HTML, and all of the other awful that we've unfortunately come to accept as the cost of doing business when building Webapps.
So far as I know, that framework doesn't exist yet.
That is, all of these frameworks are underpinned by a certain awfulness that is born of the impedance mismatch between applications vs Web. The right framework would abstract away CSS, templating, HTML, and all of the other awful that we've unfortunately come to accept as the cost of doing business when building Webapps.
So far as I know, that framework doesn't exist yet.
Curious if you could point to some solution for building apps outside of the web ecosystem that doesn't have this impedance mismatch you're talking about?
Pretty much all of the UI frameworks on any platform that I personally know of use some combination of an XML-based templating system for laying out components and a programming language to implement the logic behind those components, which is fairly analogous to how the web has HTML for templating and JS for implementing logic. Perhaps the impedance mismatch you're talking about lies in how the web handles styling, i.e. CSS itself and how it's not integrated into either the templating or the logic side like certain other frameworks but is rather a separate independent piece altogether?
Just trying to understand where you're coming from, because in my view React itself _is_ already a powerful abstraction over the DOM (in React you write components, and rendering those components to the DOM is an implementation detail involving an entirely separate library, react-dom, which can be seamlessly swapped with libraries dealing with the implementation detail of rendering to other targets like react-native, react-canvas, react-sketchapp, etc), and CSS-in-JS in the React ecosystem is itself a powerful abstraction over CSS for implementing styling as a function of state (though this abstraction hasn't yet been taken advantage of quite as much, the only notable exception I know of being glamorous-native, which implements glamorous's style as a function of state pattern on top of react-native's Stylesheet primitive rather than on top of CSS).
Pretty much all of the UI frameworks on any platform that I personally know of use some combination of an XML-based templating system for laying out components and a programming language to implement the logic behind those components, which is fairly analogous to how the web has HTML for templating and JS for implementing logic. Perhaps the impedance mismatch you're talking about lies in how the web handles styling, i.e. CSS itself and how it's not integrated into either the templating or the logic side like certain other frameworks but is rather a separate independent piece altogether?
Just trying to understand where you're coming from, because in my view React itself _is_ already a powerful abstraction over the DOM (in React you write components, and rendering those components to the DOM is an implementation detail involving an entirely separate library, react-dom, which can be seamlessly swapped with libraries dealing with the implementation detail of rendering to other targets like react-native, react-canvas, react-sketchapp, etc), and CSS-in-JS in the React ecosystem is itself a powerful abstraction over CSS for implementing styling as a function of state (though this abstraction hasn't yet been taken advantage of quite as much, the only notable exception I know of being glamorous-native, which implements glamorous's style as a function of state pattern on top of react-native's Stylesheet primitive rather than on top of CSS).
>point to some solution for building apps outside of the web ecosystem that doesn't have this impedance mismatch you're talking about
>all of the UI frameworks on any platform that I personally know of use some combination of an XML-based templating system
I also know of no other approaches with significant traction. That's the problem I'm referencing: they all take the approach of starting with technology that was designed for serving static documents then, essentially, layering on some cruft that attempts to adapt it for dynamic environments. This is obviously because the delivery platform (browsers) still rely on the underlying tech. But, there's no reason this can't be completely abstracted away by our tooling/frameworks.
I understand your references to React's abstraction but, in the end, it still comes down to CSS-in-JS, HTML-ish templating, etc. So, React's is not really an abstraction "where it counts". Think about it: why are we writing CSS at all when what we want is an application? In other words, if there were no Web and you wanted to build out a platform and/or development ecosystem for constructing applications from scratch, would CSS or XML-based templates, etc. be a design-choice you'd make? Of course not. They are wonky and inefficient for these purposes. Meanwhile, we're at the point where pre-compiling on these frameworks. So, why isn't there a framework that looks more like what we'd build from scratch that then compiles down to the Web-ish stuff we're working in (i.e. JSX or similar); thus completely abstracting away everything Web?
Because if you step back and look at, say, JSX through this lens, it's slightly insane. Not picking on React here--just following up on your example. This problem is endemic to virtually all frameworks that have gained significant traction.
There's a better way and it's frankly probably more akin to Swing or Visual Basic than it is to anything we've seen thus far.
>all of the UI frameworks on any platform that I personally know of use some combination of an XML-based templating system
I also know of no other approaches with significant traction. That's the problem I'm referencing: they all take the approach of starting with technology that was designed for serving static documents then, essentially, layering on some cruft that attempts to adapt it for dynamic environments. This is obviously because the delivery platform (browsers) still rely on the underlying tech. But, there's no reason this can't be completely abstracted away by our tooling/frameworks.
I understand your references to React's abstraction but, in the end, it still comes down to CSS-in-JS, HTML-ish templating, etc. So, React's is not really an abstraction "where it counts". Think about it: why are we writing CSS at all when what we want is an application? In other words, if there were no Web and you wanted to build out a platform and/or development ecosystem for constructing applications from scratch, would CSS or XML-based templates, etc. be a design-choice you'd make? Of course not. They are wonky and inefficient for these purposes. Meanwhile, we're at the point where pre-compiling on these frameworks. So, why isn't there a framework that looks more like what we'd build from scratch that then compiles down to the Web-ish stuff we're working in (i.e. JSX or similar); thus completely abstracting away everything Web?
Because if you step back and look at, say, JSX through this lens, it's slightly insane. Not picking on React here--just following up on your example. This problem is endemic to virtually all frameworks that have gained significant traction.
There's a better way and it's frankly probably more akin to Swing or Visual Basic than it is to anything we've seen thus far.
There is! It is called Qooxdoo, exists for years, and works wonders around the impedance mismatch.
What do you mean by css story with vue? You mean css modules? Or having one file for css, html, and js?
That's also how angular does it, i don't see anything magical to be honest, just syntax sugar over
if (unreadMessages.length > 0) { addComponent(this) }But it's a lot of syntactic sugar. There's a second, stringly-typed language embedded in your HTML template.
The only reason for it to be "stringly-typed" is that your IDE doesn't support it.
At the end of the day, it's much more of a hack. The IDE having to guess at what the string does is ridiculous to me, and it's just a ton of extra work for the person who wrote the IDE for no real reason. And now if you want to embed a string inside you need to switch quotes. Plus formatting gets super weird if you have a multiline condition. It's also super confusing for new users. There are so many issues I see with that design that I can't begin to understand why someone would argue in favor of it.
A lot of people are familiar with it (and that style) via AngularJS. It may not be as pure, but it's what they know.
An IDE doesn't have to guess anything, if the string is preceded by v-if then is code, that's it. Pretty much how a string literal inside eval() could be parsed as code.
What if another library uses v-if? Or there's no library loaded at all? What if I just wrote a new library that uses c-if? I imagine most IDEs approach this by looking at the string and trying to guess whether it's HTML code or not.
finally a clear code snippet
[deleted]
You can also do `<div :if="foo">` where `foo` is a computed property (or function with ()) -- nothing specifies you have to write code inside the string, though it seems this is a pretty commonly overlooked ability.
I've found styled-components to solve just about all my gripes about CSS in React. You even get auto formatting with Prettier.
https://www.styled-components.com
https://www.styled-components.com
What are your gripes?
I’ve found doing CSS in JS to be a bit awkward. The fancier CSS grid syntax is a good example of CSS that’s awkward to write in JSON. styled-components lets me use normal CSS syntax in a natural way alongside JSX code.
What "CSS in JS" you where using before? JSS?
Mainly I was just using react’s native support for passing styles as JSON objects.
Oh. Now I understand. Yeah, that makes a lot of sense.
Ah yes, the classic "I spent a couple weeks learning technology X, got confused and gave up, so therefore it's bad". What a lot of these articles miss is a good analysis of why. Generally if something is confusing, weird, or wrong, it's for a particular reason. Even if the reason is poor, it's important to know it before you bash. So here's some of the reasons:
The whole v-if statement versus JSX is rather superficial imo. Personally I don't like awkward DSLs that depend on code inside a string, but that aside, did the author ever wonder why JSX uses &&? JSX is fundamentally a fancy syntax over function composition. What's nice about this is that it's a more general abstraction than what Vue offers. Vue has to give the user all these v-if, v-for, v-whatever directives, while React just gives two tools: function composition and brackets to return an expression. You could argue that this is more tedious, more code to write, whatever, but it also means that you don't have to depend on your library writers to add more directives. That being said, I understand the joys of syntactic sugar and I guess v-if is kind of nice.
Binding is a JS problem not a React problem. The fact that these are confused leaves me even less credence in the author. If the author learned about the mess that is JS scoping, they'd understand why binding is necessary.
setState exists for a reason as well: state updates in React should be controlled and minimized when possible. I don't want my state in React to update like a normal JS object. In fact, I'd prefer if React moved to a ReasonReact style reducer format just to emphasize that state should be treated immutably.
All the "code is smaller in Vue" is extremely subjective. I'd need better examples than v-if to judge that. Plus, terseness comes at a cost. I can write extremely terse, metaprogrammed Ruby or even worse, Perl. Chances are I won't understand it within a month.
Finally, I see the author using the word "template" repeatedly. React is NOT templating. This is a very important point. Components are a far far more important abstraction than templating. Components can be wrappers that provide state, or a way of abstracting API calls, or a way to control routing. In the end, they're functions (or rather closures) that call other functions. Calling components "templates" betrays a fundamental misunderstanding of React's core principles.
The whole v-if statement versus JSX is rather superficial imo. Personally I don't like awkward DSLs that depend on code inside a string, but that aside, did the author ever wonder why JSX uses &&? JSX is fundamentally a fancy syntax over function composition. What's nice about this is that it's a more general abstraction than what Vue offers. Vue has to give the user all these v-if, v-for, v-whatever directives, while React just gives two tools: function composition and brackets to return an expression. You could argue that this is more tedious, more code to write, whatever, but it also means that you don't have to depend on your library writers to add more directives. That being said, I understand the joys of syntactic sugar and I guess v-if is kind of nice.
Binding is a JS problem not a React problem. The fact that these are confused leaves me even less credence in the author. If the author learned about the mess that is JS scoping, they'd understand why binding is necessary.
setState exists for a reason as well: state updates in React should be controlled and minimized when possible. I don't want my state in React to update like a normal JS object. In fact, I'd prefer if React moved to a ReasonReact style reducer format just to emphasize that state should be treated immutably.
All the "code is smaller in Vue" is extremely subjective. I'd need better examples than v-if to judge that. Plus, terseness comes at a cost. I can write extremely terse, metaprogrammed Ruby or even worse, Perl. Chances are I won't understand it within a month.
Finally, I see the author using the word "template" repeatedly. React is NOT templating. This is a very important point. Components are a far far more important abstraction than templating. Components can be wrappers that provide state, or a way of abstracting API calls, or a way to control routing. In the end, they're functions (or rather closures) that call other functions. Calling components "templates" betrays a fundamental misunderstanding of React's core principles.
Well said. I'd wholeheartedly recommend anyone learning React to try manually converting a component written in JSX syntax into a bunch of React.createElement calls. The exercise itself is really easy and mechanical, but I find it very enlightening nontheless.
What people coming from a templating background often consider as "quirks" of JSX (such as the limitations around conditional branching and why properties need to be camelCase rather than kebab-case) become painfully self-evident after seeing how the equivalent JSX code would look like in the plain JS React.createElement form.
In fact, in my own projects I often prefer to import createElement, alias it as something short and use it directly to write rendering functions over using JSX because I find it removes a lot of the impedance mismatch involved with switching back and forth between JSX's psuedo html syntax and regular JS syntax in JSX expressions (and basically any other part of the codebase that's all written in JS). Plus, JSX syntax is actually generally _more_ verbose than the raw createElement calls when aliased due to things like requiring named closing tags for any component that takes children and needing to use `blah={blah}` over the `blah,` object property shorthand for passing through props.
Though in team settings I still resort to begrudgingly writing JSX because people are more familiar with it, and I'd probably have to pick a fight with every new team member to get them onboard with the idea, and I'd rather spend that political capital on less superficial issues.
I sometimes really wish the React folks never invented JSX, and just forced everyone to write createElement calls to begin with, then all of these points of confusion from people coming from templates could have been avoided (and we'd end up with only my preferred syntax as the one true way to write components, haha), but I do wonder if React would have taken off as it did if it didn't come with JSX to give people that sense of familiarity, even if it ends up causing much more undue confusion over the long term.
What people coming from a templating background often consider as "quirks" of JSX (such as the limitations around conditional branching and why properties need to be camelCase rather than kebab-case) become painfully self-evident after seeing how the equivalent JSX code would look like in the plain JS React.createElement form.
In fact, in my own projects I often prefer to import createElement, alias it as something short and use it directly to write rendering functions over using JSX because I find it removes a lot of the impedance mismatch involved with switching back and forth between JSX's psuedo html syntax and regular JS syntax in JSX expressions (and basically any other part of the codebase that's all written in JS). Plus, JSX syntax is actually generally _more_ verbose than the raw createElement calls when aliased due to things like requiring named closing tags for any component that takes children and needing to use `blah={blah}` over the `blah,` object property shorthand for passing through props.
Though in team settings I still resort to begrudgingly writing JSX because people are more familiar with it, and I'd probably have to pick a fight with every new team member to get them onboard with the idea, and I'd rather spend that political capital on less superficial issues.
I sometimes really wish the React folks never invented JSX, and just forced everyone to write createElement calls to begin with, then all of these points of confusion from people coming from templates could have been avoided (and we'd end up with only my preferred syntax as the one true way to write components, haha), but I do wonder if React would have taken off as it did if it didn't come with JSX to give people that sense of familiarity, even if it ends up causing much more undue confusion over the long term.
> Binding is a JS problem not a React problem. The fact that these are confused leaves me even less credence in the author. If the author learned about the mess that is JS scoping, they'd understand why binding is necessary.
This is going to be a huge problem going forward since the React documentation team seems to have made it their mission to try and obfuscate the details of JS away from their readers rather than educate them. Which is a terrible decision.
This is going to be a huge problem going forward since the React documentation team seems to have made it their mission to try and obfuscate the details of JS away from their readers rather than educate them. Which is a terrible decision.
Yeah this is a common problem when your library/framework/tool becomes too popular. Your users focus too much on learning the shiny tech and not the foundation. Rails faced a similar issue where people would come in without understanding Ruby and struggle with even the most simple tasks. Of course it didn't help that Rails also tried to hide many of the details of Ruby.
I don't buy into Vue being easier to learn than React.
This year I picked up and started learning React after some experience with vanilla JS and jquery. I first tried Vue and for whatever reason, non-trivial examples were so hard to wrap my head around.
The documentation was hard to follow sometimes, and I had some issues with documentation on other projects like Nuxt.js, whereas the Create React App and Gatsby docs are so good.
I tried React just when I was about to swear off front end web development, and everything clicked. I've never felt like I had superpowers until I started using React to replace jquery soup.
Nowadays, I use vue occasionally if a project is using it, and it's easier to understand for me now. I still greatly prefer React, though, and JSX is a joy to use.
This year I picked up and started learning React after some experience with vanilla JS and jquery. I first tried Vue and for whatever reason, non-trivial examples were so hard to wrap my head around.
The documentation was hard to follow sometimes, and I had some issues with documentation on other projects like Nuxt.js, whereas the Create React App and Gatsby docs are so good.
I tried React just when I was about to swear off front end web development, and everything clicked. I've never felt like I had superpowers until I started using React to replace jquery soup.
Nowadays, I use vue occasionally if a project is using it, and it's easier to understand for me now. I still greatly prefer React, though, and JSX is a joy to use.
Vue might be easier to "learn" under some metrics, but there's no way it's easier to actually understand. Look at the amount of hidden build-time logic in each system. Vue has it's own entire stringly typed DSL, React has one fairly trivial transform that's easily doable in your head, and is totally optional.
which still matters, even though nobody chooses to go that route, because in theory it allows beginners to learn the JSX abstraction seperately, and helps smooth out the learning curve. Unfortunately nobody actually seems to learn this way because there's so much emphasis on getting devs up to speed and working on production systems as quick as possible, at the expense of actually imparting them with any wisdom or knowledge. The React team are the worst at this (although Vue is a very close second), there's no good reason that I need to go to Dan Abramov's twitter and blog to find out how the library I'm using works. It should be in the official docs. Otherwise you're just training devs to code through rote memorisation of patterns instead of any actual knowledge or understanding.
which still matters, even though nobody chooses to go that route, because in theory it allows beginners to learn the JSX abstraction seperately, and helps smooth out the learning curve. Unfortunately nobody actually seems to learn this way because there's so much emphasis on getting devs up to speed and working on production systems as quick as possible, at the expense of actually imparting them with any wisdom or knowledge. The React team are the worst at this (although Vue is a very close second), there's no good reason that I need to go to Dan Abramov's twitter and blog to find out how the library I'm using works. It should be in the official docs. Otherwise you're just training devs to code through rote memorisation of patterns instead of any actual knowledge or understanding.
I’ve been learning Vue myself lately and agree that the documentation is a huge weak point. Even the beginner’s guide leaps around from one advanced concept to another, rather than taking you from step 1 to step 2 to step 3 in easily comprehensible chunks. It makes learning Vue a lot harder than it probably needs to be.
The reason I choose JSX over Vue weird template system is because it's Javascript after all. I don't have to relearn how to do if-else, for loops statement for every template language. But the css story of Vue is definitely better than React.
By the same logic, couldn't you argue that you should be programmatically writing all of your HTML, because then it would "just be Javascript after all"?
I'm sympathetic to not reinventing the wheel when unnecessary, but on the flip side, I haven't found the vue templating syntax to be anything but intuitive and cognitively easy to predict. It's not like you're prolog all of a sudden.
I'm sympathetic to not reinventing the wheel when unnecessary, but on the flip side, I haven't found the vue templating syntax to be anything but intuitive and cognitively easy to predict. It's not like you're prolog all of a sudden.
No, because HTML is built into the platform and is a necessity for every web app. Vue is used in like 10% of them, and everything Vue-specific you learn will be useless for 90% of use cases.
> But the css story of Vue is definitely better than React.
Curious what this is about?
Curious what this is about?
The author's gripe with having to manually bind methods is solved by property initializers, which have been around for a while now.
Or using arrow functions.
This article is at least half a year old by now, though I think it might be a year and a half old.
I went the other way. I enjoyed using VueJS. But the quality of the library and community on React seems a bit better.
It probably helps that I’ve really been learning JS with TS after a decade of Python, and the TS community is pretty good in Reactiflux.
a couple other thoughts:
- the single file concept with Vue is awesome. But I find it irrelevant with JSX - and I never could get it fully working in my IDE (VSCode or VIM)
- the patterns seem to be more established in React (which is helpful to someone who’s learning and developing).
- the VueJS libraries that I used were often a reaction to a React library and seemed to be an afterthought, unfortunately.
All in all, I like having experience in both, but I don’t see a reason to go back to VueJS in the near future.
It probably helps that I’ve really been learning JS with TS after a decade of Python, and the TS community is pretty good in Reactiflux.
a couple other thoughts:
- the single file concept with Vue is awesome. But I find it irrelevant with JSX - and I never could get it fully working in my IDE (VSCode or VIM)
- the patterns seem to be more established in React (which is helpful to someone who’s learning and developing).
- the VueJS libraries that I used were often a reaction to a React library and seemed to be an afterthought, unfortunately.
All in all, I like having experience in both, but I don’t see a reason to go back to VueJS in the near future.
I have gone the other way, after using Vue at work for the last year it feels like such a relief when I get to go back to React and just write plain Javascript.
I have done a medium size project in React and didn't have a lot of fun working with it. Since then I tried VueJS and found it a lot more readable. Maybe the applications I wrote didn't have absolutely everything dynamically generated, but it seems like big chunks of pages were not actually that dynamic and it was nice to just see it in a form that was close to what it was supposed to render to.
The stats at the start of the article is with multiple years old versions of angular and React, doesn’t make much sense for an argument?
JS in an XML property string is just never going to work for me, sorry.
1. JSX puts HTML into JS, which gives you compile errors. While Vue puts JS into HTML again..
2. Never use bind inside render functions.
Unfortunately, the author doesn’t seem to understand what React is about and what problems it’s trying to solve as a framework.
React-Router or anything using centralized router in React Component is bad pattern for scalability.
In this case, you, library authors, could learn from Next.JS.
The fact is that, by splitting your route into something like `pages`, you can do code splitting for your application as well.
When I started Vue I was somewhat disappointed that Vue components aren't first-class HTML.
I looked at W3C web components instead and I liked the concept better. For example why not define control flow elements like, for example <c-if> or <c-loop>? However I didn't gain enough practical experience to be able to recommend them. Perhaps there are problems lurking behind them.
So this left me wondering why web components aren't as popular, even including accompanying frameworks like Polymer. I suspect that in a few years Vue will maybe again being overtaken by another framework basing on W3C web components, just because web components feel more natural than Vue components.
I looked at W3C web components instead and I liked the concept better. For example why not define control flow elements like, for example <c-if> or <c-loop>? However I didn't gain enough practical experience to be able to recommend them. Perhaps there are problems lurking behind them.
So this left me wondering why web components aren't as popular, even including accompanying frameworks like Polymer. I suspect that in a few years Vue will maybe again being overtaken by another framework basing on W3C web components, just because web components feel more natural than Vue components.
I've been writing React code for years now, and recently have a gig where we use VueJS exclusively for the frontend. First time using VueJS and I completed a few tickets on my first two days. I couldn't imagine doing the same with React.
I'm now 100% on team VueJS.
You get stuff done quicker, the files contain templates and logic separately, and it makes me happier to work with VueJS. For those people preferring React over "muh its just js", please - it's just code, to get the job done. Use whatever gets the job done and makes you happy. After a few days of VueJS you'll find it incredibly nice to use.
I'm now 100% on team VueJS.
You get stuff done quicker, the files contain templates and logic separately, and it makes me happier to work with VueJS. For those people preferring React over "muh its just js", please - it's just code, to get the job done. Use whatever gets the job done and makes you happy. After a few days of VueJS you'll find it incredibly nice to use.
It sounds that you feel more productive in Vue. Why? What was holding you back in React? After all, those are component based JS frameworks, with comparable data layer patterns and user facing architecture. So what was so different for you? Having everything in one file? Not having to deal with classes?
To each his own. React makes sense for some developers. They love the verbosity and powerful libraries. However I prefer Vue.js on many levels. The creator initially worked as a designer; therefore a lot of the vision for the tool adheres to a strict usability and designing standards for the user or developer. I feel react was rushed giving priority to features over usability, adoption and clean apis.
No mention of Vuex? This, to me, is Vue's major selling point - Redux in comparison looks as if someone tried to shoehorn a few things for the sake of "abstraction".
Also I don't know anything about React's material design component set, but I know Vue's Vuetify is really well made, especially comparing to the equivalent in Angular.
Also I don't know anything about React's material design component set, but I know Vue's Vuetify is really well made, especially comparing to the equivalent in Angular.
Type safety is also one of the reasons why I prefer React over other frameworks such as Angular or Vue. With JSX, we have a unified type system across the logic of the application, its styling, and its presentation. The same level of type safety doesn’t seem to be available with other libraries.
[deleted]
Where Vue is better:
1. Template syntax. While this is just my own preference, my Vue template is 20% shorter than JSX equivalent, mostly due to fewer brackets and better HTML's class support.
2. Computed property: this is so cool and efficient because computed properties are cached (equivalent to Mobx). We also have computed setter as well.
3. Built-in 2-way binding for inputs. Yes I know React people will condemn me to hell for this, but this has been a heaven for form-heavy application. This also makes the HTML you write much much shorter.
4. Prop mutation: this one is extremely controversial. Imagine this.props.foo = newFoo" in React (in Vue land it's "this.$emit('update:foo', newFoo)"). This is useful in situation where you want to mutate a parent's state without going to all the boilerplate of writing store/actions/dispatch. For example
5. Watch expression: it's beneficial and concise if you know what you're doing and not abusing it. This doesn't even exist in React. (edited: plain React doesn't have this, Mobx does)
6. Built-in Vuex support out of the box. Enough said.
7. Nuxt's offerings are superior to what Next can offer. Nuxt allows layout, param validation, node server middlewares, sass and Vuex integration, sensible configuration, and a system of plugins.
8. Filters: coming from functional languages that support pipeline operator, this has been dope to my eyes. Instead of writing:
9. It doesn't need Babel. I dropped Vue into a legacy PHP Symphony project, wrote the Vue's template in a <script type="x/template"> and wrote the components in plain ES5 object, and it just works !!!
10. The event emitter is a better pattern than calling prop as a function.
11. Vue doesn't intefere with SVG attributes. in React, I have to convert "xlink:href" to "xLinkHref", which is annoying
1. Template syntax. While this is just my own preference, my Vue template is 20% shorter than JSX equivalent, mostly due to fewer brackets and better HTML's class support.
2. Computed property: this is so cool and efficient because computed properties are cached (equivalent to Mobx). We also have computed setter as well.
3. Built-in 2-way binding for inputs. Yes I know React people will condemn me to hell for this, but this has been a heaven for form-heavy application. This also makes the HTML you write much much shorter.
4. Prop mutation: this one is extremely controversial. Imagine this.props.foo = newFoo" in React (in Vue land it's "this.$emit('update:foo', newFoo)"). This is useful in situation where you want to mutate a parent's state without going to all the boilerplate of writing store/actions/dispatch. For example
<div>
{{ user.firstName + ' ' + user.lastName }}
<popup-update-user user.sync="user>
</popup-update-user>
</div>
5. Watch expression: it's beneficial and concise if you know what you're doing and not abusing it. This doesn't even exist in React. (edited: plain React doesn't have this, Mobx does)
6. Built-in Vuex support out of the box. Enough said.
7. Nuxt's offerings are superior to what Next can offer. Nuxt allows layout, param validation, node server middlewares, sass and Vuex integration, sensible configuration, and a system of plugins.
8. Filters: coming from functional languages that support pipeline operator, this has been dope to my eyes. Instead of writing:
{ formatDateTime(toDate(myDate), "DD-MM-YYYY") }
{{ myDate | toDate | formatDateTime("DD-MM-YYYY") }}
9. It doesn't need Babel. I dropped Vue into a legacy PHP Symphony project, wrote the Vue's template in a <script type="x/template"> and wrote the components in plain ES5 object, and it just works !!!
10. The event emitter is a better pattern than calling prop as a function.
<MyImageGallery />
<my-image-gallery @imageSelected="doStuff" />
11. Vue doesn't intefere with SVG attributes. in React, I have to convert "xlink:href" to "xLinkHref", which is annoying
Many of those are shortcuts that look appealing on a simple project in the beginning, but have the potential to massively backfire later on when your project grows.
It is like shooting your future self in the foot.
On the other hand react make some things difficult because they are antipatterns, independently of react itself. (I'm looking at you number 4: Prop mutation...)
It is like shooting your future self in the foot.
On the other hand react make some things difficult because they are antipatterns, independently of react itself. (I'm looking at you number 4: Prop mutation...)
In addition to #2, mobx also covers #5.
I realize front end frameworks can be in the language of the trophy awards for solving a real consumer's "temporary endeavor undertaken to produce a unique product, service or result: actually a helplessly complicated system of activating the end result, which also from Fundamental of Project Management book, is "a headless chicken project" before the developers take enough "aftercare" to realize all has been ended and the honey room is next (human resources).
This is of course for CM0 type of whatever development though that may be in carriage of more advanced software life cycle systems. I tried some Vue dot js, I got some Angular dot js, I saw Angular dot whatever is difference positive. I read JS survey reports and of course always am super diligent about understanding Stack Overflow surveys of developers.
I think any particular perspective on the end results tends to be from the myopia of the skillist's perspective (to use confederal type of language instead of under-squiggley-tells-me federal non-adverbial BE that IBE can understand, without massive disassembly efforts on the part of the communication triangle (most direct, least direct, something else).
This is sort of like unpunctuated scriptures being upgrade to punctuated before being universalized after failed attempts to understand the Hegelian master/slave "golden" pretend morality (not to be hypercritical about "geeks" jargon file meaning as someone who knows chickens can be engineering to be pretty amazing and basically do a 50 yard dash in amazing pirouettes like dolphins released from old Navy, Pavlov sacristen-blasphemer, padawan of Orloff, yards that aren't still supposed to be around).
I mean it is Bacchanalia day and all, so Festivus!
React is great, Vue is great, conditional reflexology is trump over nonreflexive thinking attempts, it is all good to Pathology Excellent Rubbish Lister (PERL, red squiggle word kill count = 0). Ok front door 89 hz beep went off. I'm over my trolling limit. Be well, program in popular script-y.
This is of course for CM0 type of whatever development though that may be in carriage of more advanced software life cycle systems. I tried some Vue dot js, I got some Angular dot js, I saw Angular dot whatever is difference positive. I read JS survey reports and of course always am super diligent about understanding Stack Overflow surveys of developers.
I think any particular perspective on the end results tends to be from the myopia of the skillist's perspective (to use confederal type of language instead of under-squiggley-tells-me federal non-adverbial BE that IBE can understand, without massive disassembly efforts on the part of the communication triangle (most direct, least direct, something else).
This is sort of like unpunctuated scriptures being upgrade to punctuated before being universalized after failed attempts to understand the Hegelian master/slave "golden" pretend morality (not to be hypercritical about "geeks" jargon file meaning as someone who knows chickens can be engineering to be pretty amazing and basically do a 50 yard dash in amazing pirouettes like dolphins released from old Navy, Pavlov sacristen-blasphemer, padawan of Orloff, yards that aren't still supposed to be around).
I mean it is Bacchanalia day and all, so Festivus!
React is great, Vue is great, conditional reflexology is trump over nonreflexive thinking attempts, it is all good to Pathology Excellent Rubbish Lister (PERL, red squiggle word kill count = 0). Ok front door 89 hz beep went off. I'm over my trolling limit. Be well, program in popular script-y.
I mean, I kind of miss TempleOS... if you could step it up a notch
I see no compelling reason to move from AngularJS 1.x for both new and existing projects to either React, Vue, or whatever else is hot in certain circles. We generate many millions in business, and I can tell with certainty that the framework has nothing to do with how well we perform. If anything, staff's confidence that our stack is extremely stable and not prone to team leaders deciding to jump into a new framework only contributes positively to their productivity.
[deleted]
Everything else is biased and mostly wrong. In terms of performance, recent versions of react with Fiber can achieve figures vue can only dream of.
The conditional in react is just pure JS. He could have written an if statement instead of the anti pattern use of && for a non Boolean expression. And arguing that the v-if followed by code in a string is simpler sounds dishonest to me. Or we don’t have the same frame of reference.
The main problem to me is that the author compares his experience with react in 2015 with his experience in Vue in 2018.