6 ms·
Why I left React for Vue
- deleted 8y ago[deleted]
- ystrdytmrrw 8y agoI 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.
- mattigames 8y agoThat'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) }
- ng12 8y agoBut it's a lot of syntactic sugar. There's a second, stringly-typed language embedded in your HTML template.
- mattigames 8y agoThe only reason for it to be "stringly-typed" is that your IDE doesn't support it.
- ng12 8y agoIt's still stringly typed even if someone wrote an IDE plugin that tries very hard to make it safe.
- nv-vn 8y agoAt 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.
- lucidone 8y agoA lot of people are familiar with it (and that style) via AngularJS. It may not be as pure, but it's what they know.
- mattigames 8y agoAn 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.
- nv-vn 8y agoWhat 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.
- liveoneggs 8y agofinally a clear code snippet
- fro0116 8y agoGoing 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.
- unclebucknasty 8y agoIt'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.
- fro0116 8y agoCurious 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).
- molszanski 8y agoWhat do you mean by css story with vue? You mean css modules? Or having one file for css, html, and js?
- cageface 8y agoI'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
- molszanski 8y agoWhat are your gripes?
- cageface 8y agoI’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.
- molszanski 8y agoWhat "CSS in JS" you where using before? JSS?
- cageface 8y agoMainly I was just using react’s native support for passing styles as JSON objects.
- molszanski 8y agoOh. Now I understand. Yeah, that makes a lot of sense.
- Tallain 8y agoYou 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.
- deleted 8y ago[deleted]
- thangngoc89 8y agoThe 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.
- wjossey 8y agoBy 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.
- BigJono 8y agoNo, 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.
- Drdrdrq 8y ago> But the css story of Vue is definitely better than React. Curious what this is about?
- kevinsimper 8y agoThe 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?
- makeupsomething 8y agoI 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.
- dschu 8y ago1. JSX puts HTML into JS, which gives you compile errors. While Vue puts JS into HTML again.. 2. Never use bind inside render functions.
- crubier 8y agoI disagree with everything in this article, except maybe about saving a few kb in bundle size, and the better CSS experience. 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.
- thatswrong0 8y agoAnd 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
- DatBear 8y agoThe 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...
- sergiotapia 8y ago>The conditional in react is just pure JS. Who cares? You still write a JS conditional in the v-if string, right?
- MattRix 8y agoThat gets messy fast though. You start having to escape strings in your code, and potentially have a trickier time with autocompletion etc.
- 8y ago
- yunyu 8y agoThe author's gripe with having to manually bind methods is solved by property initializers, which have been around for a while now.
- MentallyRetired 8y agoThis article is at least half a year old by now, though I think it might be a year and a half old.
- roddds 8y agoOr using arrow functions.
- androidgirl 8y agoI 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.
- BigJono 8y agoVue 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.
- smacktoward 8y agoI’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.
- foofoofoofoo42 8y agoI feel sorry for front-end developers. Their pay is low, their primary language, JavaScipt, is a joke, and they have to constantly learn new frameworks.
- aerovistae 8y agoI feel sorry for people who have nothing to contribute to conversations, and whose attempts to contribute are so obnoxious or dull that they find themselves ignored or ostracized and don’t understand why.
- thatswrong0 8y agoOur pay is low..?
- flocial 8y agoMods please remove this comment it's only adding toxicity.
- dfee 8y agoI 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.
- pkulak 8y agoJS in an XML property string is just never going to work for me, sorry.
- revskill 8y agoReact-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.
- ezxs 8y agoI 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.
- sergiotapia 8y agoI'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.
- molszanski 8y agoIt 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?
- gtoprak 8y agoUnfortunately, the author doesn’t seem to understand what React is about and what problems it’s trying to solve as a framework.
- wraithdroplets 8y agoI 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.
- code_duck 8y agoI mean, I kind of miss TempleOS... if you could step it up a notch
- aviv 8y agoI 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.
- kangoo1707 8y agoWhere 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 <div> {{ user.firstName + ' ' + user.lastName }} <popup-update-user user.sync="user> </popup-update-user> </div> By looking at the above code, I can tell that <popup-update-user> will take an object called "user" in, modify it (and probably calls an API), then update the user object back to me. Of course I can do all that in the Vuex store (or in your favourite Redux flavor, but imagine all the code that has to be written) 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") } you can write it in a better way: {{ myDate | toDate | formatDateTime("DD-MM-YYYY") }} Of course, the difference is just syntactic. But I hope in the future, Vue's filter can be cached just like computed properties. 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 onImageSelected={doStuff} /> vs <my-image-gallery @imageSelected="doStuff" /> Again, you may argue that this is syntactic sugar, but for me it's clear just at a glance which props are "in-ward", and which props are "out-ward" 11. Vue doesn't intefere with SVG attributes. in React, I have to convert "xlink:href" to "xLinkHref", which is annoying
- 8y ago
- _hardwaregeek 8y agoAh 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.
- BigJono 8y ago> 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.
- stevev 8y agoTo 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.
- deleted 8y ago[deleted]
- Tade0 8y agoNo 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.
- candillon 8y agoType 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.
- _nalply 8y agoWhen 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.