6 ms·

No one I work with has ever even brought up the possibility of switching from React to Vue, let alone counting Github stars. Compare to when React came out, it

• MentallyRetired 8y ago
  I've tried Vue out and have pretty clear gains in productivity, personally. For me, it really zeroed in on the pain points of React.
• crooked-v 8y ago
  To me, React also has the killer feature of being "generic enough" that I can see directly migrate-able variants of it still being used in ten years. The backend may change, but the basic setup of JSX -> function transpiling with param-attribute equivalency is simple enough to be a new foundational structure.
  • lsalvatore 8y ago
    Yep, React seems to have been built from the beginning as a new foundation. It leveraged ES6 features just as they were coming out, so we got to learn a new way to write JavaScript and HTML at the same time.
  • baddox 8y ago
    That's a big one for me, particularly with the way I prefer to write all my React components: as stateless functional components (just a function that takes props as its only argument and returns some JSX). For adding state, lifecycle methods, etc. I'm using recompose, which is also generic enough that I could easily see myself reimplementing it for some future view library.
• ehnto 8y ago
  > React (really JSX) solves the single problem of making HTML a part of JavaScript The reason I like the way Vue works is because it makes javascript part of the HTML definition (with component definitions), essentially the opposite of what you like about React. That said, my use case of Vue is very different to my use case for React. Even though Vue does essentially solve the same problem set, their approaches have pros and cons in different scenarios. (all that said I typically don't need to use either for what I do, in preference of light vanilla JS classes)
  • macleodnine 8y ago
    Could you elaborate on the different use cases for each? I don't know enough about vue to spot them myself
    • ehnto 8y ago
      My use case where Vue fits better is in lots of isolated reusable components that aren't tied to a global state. So an image slider or datepicker for example. But I would consider React and Vue for building a larger scale, stateful application like Spotify or Slack.
• anonytrary 8y ago
  This is pretty much exactly how I feel. There has been a lot of "anti-React" virtue signaling in the Javascript community over the past few years, and I just don't get it. Why is your whole front-end team switching from React to X, where React - X ~ epsilon? If it ain't broke, don't fix it. If you're switching from jQuery or templates to X, it is more reasonable, but I've seen teams rewrite Angular and React codebases in Vue (i.e. "we're hip and modern now"). In my experience, React's API has been far more intuitive than directive-based frameworks, and switching between the various directive-based frameworks seems like too much work for too little change. I would be interested in frameworks which aim to mimic React's API but offer more in terms of size (smaller is better) and performance. This is why I closely watch projects like Preact.
  • macleodnine 8y ago
    I agree, and Preact is fantastic! Not only is it very fast and light, but so is the community
  • benatkin 8y ago
    What do you mean by virtue signaling, and how should they defend their choice without virtue signaling? Is it possible that some just prefer to use something that feels closer to the W3C standards? Or is the virtue signaling about it being a facebook project, with facebook being a threat to the open web? Angular is a google project, but I've heard some say that since Evan You used to work for google it's sort of like it's a google project, which I disagree with. The clear winner of the three for being independent of FAAMG is Vue. Angular at least has its own GitHub organization that makes it a bit less blatant of an ad for its corporate steward (remember io.js and the movement to get Node moved out of Joyent to a foundation?).
    • anonytrary 8y ago
      Maybe I was being hyperbolic, but it could refer to any or all of the following: 1. The W3C standards convention 2. Being a product of Facebook 3. The old license being restrictive 4. Too much hype around the framework I'm positive I've seen people conjure these reasons before. I was deterred from React mainly for the third reason. When they fixed their license, I felt no need to pursue alternatives. I've played around with Vue a bit, and I just wasn't compelled enough to switch to it. It seemed like a solved problem already. The only thing that will get me to switch from React is a 2x in performance and/or a 10x reduction in complexity or size.
• yayana 8y ago
  I find the whole premise of putting the html in JavaScript bizarre and I think it is a passing fashion while the various debates around web components and shadow DOM isolation get sorted out. I would hope my graphic artist will eventually be mixing 3 layers of HTML elements that seem entirely standard to him except the 3 different sources of docs.
  • lsalvatore 8y ago
    The only bizarre thing is the HTML was ever separate from JavaScript in the first place.
    • yayana 8y ago
      How is that bizarre? Trying to enforce MVC is done even when it is a lost cause.. But you properly separate html, css and (arbitrary Code language to be replaced by transpiling) and all you hear is "I wish my graphic artist had to understand all of this and what a compiler does before he could fix my poor UX ideas.. and my copywriter should have to find my spelling mistakes using an IDE too." If my graphic artist expected me to go into Adobe every time I needed a new background, I would ask him what his job was.
      • lsalvatore 8y ago
        It sounds like you're coming from a landing page/blog/Wordpress background. I'm primarily building data-driven apps, like financial data or dashboards. My UX/UI people don't come near my code, and I wouldn't want them to. For me, every time I need a new button, I'm not going to my designer, I'm just copying over the last button. So I need to be able to quickly edit styles, and state functionality, like dropdowns and date pickers. For these types of components, your life will be a living hell if every time you needed to add a style, you were going to a CSS/HTML file. This was how we first worked with Backbone and Handlebars, and it absolutely sucked.
        • yayana 8y ago
          I see just enough of landingpages and corporate customers and multilingual to see why most of these frameworks ship with toy features when it comes to the lifecycle of the overall site. Then you end up with two parts (a site in so.e kind of CMS and a compiled SPA) that have to look kind of alike where they can only sort of edit one.. Handlebars is just a general text template language so it was naturaly quite rough. From there one can move to dressing components in the angular style and keep the templates all in one folder and the custom CSS in one file. My designer and I share the templates folder, I usually add enough attributes for bootstrap to do something or other and then the custom CSS is his and the code is mine. If we were writing our SPAs for consulting clients it would be essential that the templates and CSS were not compiled so they could go on with them without us and without either paying us to keep a bunch of unstable node tooling able to compile and up to date or feeling like we intentionally snuck a time bomb into the project and are underhanded in seeking hours.
• amelius 8y ago
  > With React there's no weird "v-if ng-if" template logic that you have to grapple with. Yes, I hate that syntax. It's like they picked the worst from HTML and Javascript. Instead "if" statements should be dealt with in Javascript entirely. It's one of the reasons why I don't use Vue.
  • jaequery 8y ago
    that was how i felt too which was the same reason i disliked angular. but vue's templating syntax have turned out to be really enjoyable to use. it made me think how wrong i was of my initial impression of vue. you have to give it a try to understand it.
    • serpix 8y ago
      how do you access nested properties in Vue templates? You can't do a.b.c if b is undefined and instead need to wrap it into satanic template extensions
      • bigtunacan 8y ago
        When logic starts to get too complicated you have the option to move it into a render function; you can even use JSX if that's your thing. One of the nice things about Vue IMHO is how it leaves more flexibility to the developer to choose the right path.
    • amelius 8y ago
      Sorry, I appreciate your enthusiasm, but I just can't imagine how shoehorning a language into XML could ever be a good idea.
      • jaequery 8y ago
        thats how i felt too, and i'm now a big fan of vue. its funny how that works.
        • 8y ago
• benatkin 8y ago
  With Vue and Angular you don't have to deal with controlled components, and you don't have to figure out how to mix JavaScript expressions with JSX expressions (sometimes it gets ugly).
  • dmitriid 8y ago
    In Vue and Angular you only need to figure out how to mix Javascript-like expressions with HTML-like templating language: <ul id="example-1"> <li v-for="item in items"> {{ item.message }} </li> </ul>
    • benatkin 8y ago
      Pretty slick. It isn't fundamentally different from *ngFor in Angular (with let to declare the variable), but the details make it much more pleasant.
      • dmitriid 8y ago
        Not slicker than JSX, definitely. It’s not HTML, it’s not Javascript. As code goes in complexity Vue quickly becomes ... let’s call it weird: https://mobile.twitter.com/dmitriid/status/987771666846699520/photo/2 https://mobile.twitter.com/dmitriid/status/98777166684669952... Javascript-like scripting in strings? Check. Different versions of HTML-like attributes? Check. Magic binding of all that to specific structures in JS code? Check. But please, do tell me how it’s beter than React where you “have to figure out how to mix JavaScript expressions with JSX expressions (sometimes it gets ugly).”
• lsalvatore 8y ago
  I also wanted to make an additional comment expressing my frustration with the consistently negative comments on posts like this about JS Frameworks. These commenters, those who see React as "just another JS Framework" and whom see JavaScript developers as people who would change JS Frameworks as if they were ordering a new drink at Starbucks: These people are the epitome of amateur. Building web apps has been my career for nearly a decade. If you think entire teams would just up and switch to a new JS framework tomorrow because of a Medium article, or because of Github stars, you don't understand how the industry works at all. React is not a fashion statement, it's an evolved paradigm shift in the web. Vue is not, it looks like Angular and Handlebars, the way apps were built 5 years ago, it adds nothing to the industry but more bloat and distracting people from using React.
  • mythrwy 8y ago
    Thus spoke the priest of the inquisition confronting heretics distracting from the one true way:) I personally had a lot of trouble with React, I didn't care for it, it was too foreign, too invasive. Vue on the other hand just clicked nicely and appeared a thing of simplicity and beauty. But admittedly I'm a wanton sinner. Who also don't care for Facebook products no matter how great and open and popular they are.
    • lsalvatore 8y ago
      React was created by Jordan Walke, a software engineer at Facebook. Facebook had a good reputation at the time, and so we forgive Jordan's divine genius for that slight error in career choice.
  • brightball 8y ago
    Personally, I view it as a case of right-tool-for-the-job vs the-one-true-way. The core of the matter boils down to one thing...everything on the web doesn't need to be an SPA because most things are open, check, close experiences. For the things that don't need to be an SPA, where a server side app serving HTML is a significantly faster user experience and dropping in a small bit of JS here and there is the right approach...Vue makes sense. This is the same place that jQuery makes sense because it makes the goal simple. For the places where you do need an SPA because the user is going to be opening your site/app and working within it for a while...absolutely...use React. If that's going to translate to a native application, even more so...use React. The concern is that Single Page Apps with React are gaining the hammer-and-everything-is-a-nail experience...when really only a few things are nails and most things are actually screws. Just pick the right tool for the job without all of the zealotry, like suggesting anything that is not react distracts people from using react.
• smdz 8y ago
  >When Angular gained popularity, we did not have an urge to switch because it felt unclear what the scope and direction of Angular actually was. I do not remember React coming in before Angular. I loved Angular1. But Angular2 made me very uncomfortable and thats when I switched to React. And I'm not looking back. Even if I need a very simple drop-in not-transpiled solution without the React tooling - I always fall back to Angular1 instead of using Vue. Fortunately I have no regrets moving to React.
  • lsalvatore 8y ago
    Sorry, I told the story out of order, we saw Angular and passed on it. Also have no regrets or issues with React. Been 3 years now and I have no complaints or frustrations with my job anymore, compared to the horror of adding jQuery plugins.
• jordanlev 8y ago
  > React (really JSX) solves the single problem of making HTML a part of JavaScript. This is the crux of the matter. The people who find Vue appealing (myself included) come from the world of design and html+css markup and jQuery. We're not looking to get html into our JavaScript -- rather we're looking to get JavaScript into our html! There is absolutely no reason to switch from React to Vue if it's working for you (and I don't think anyone in the Vue community would argue with that). But you came from using backbone -- the people who love Vue I think primarily come from using jQuery. We feel the same way about Vue as you do about React, and that's okay! (btw I also use react and also think it's great) As for staying in React for the rest of your career -- give yourself more credit and hope you'll be around long enough that this isn't true :)
  • lsalvatore 8y ago
    Appreciate your comment, it sounds like Vue may be an easier option for you, if you don't want to write JavaScript. However, you should just learn JavaScript, even if you're doing nothing but designing components, will explain why. I also came from jQuery (Backbone and jQuery was a popular duo, in fact using jQuery in everything was). The way people wrote apps at one point basically was a stream of jQuery statements, $thing.add('something'), etc.. This created nothing but spaghetti code over time. Now, we're using React to design extendable components that can be nested, or structured to add more functionality. Check out styled components below to see how much easier it is to combine CSS, HTML into JavaScript. Rebass is built on this as a minimal component library. I know this might be really advanced and you may not adopt any of this, I'm just showing you the latest in what we could be moving toward. I don't think I would leave React unless JS/HTML/Browsers dramatically changed. The industry is too far into JavaScript code at this point to where I am concerned about job security. Back to your original point, I don't think Vue would scale well for serious JavaScript heavy apps, so that's why I don't think it's fair to compare it with React, but that's not how it's being discussed, which is some sort of React killer. [1] https://www.styled-components.com/ https://www.styled-components.com/ [2] https://github.com/jxnblk/rebass https://github.com/jxnblk/rebass
    • codegladiator 8y ago
• gaius 8y ago
  I'm comfortable staying in the React ecosystem for the rest of my career. You won’t have that option. No one has had it with their favourite tech for decades now. Hell I’d still be writing Motif code if I could. Unless you are 2 years from retirement in which case, enjoy!
  • lsalvatore 8y ago
    2008 is more similar to 2018 than it is to 1998. I will wager that 2028 more similar to 2018 than 2018 was to 2008. Doesn't look like there's a future appearing where we strap on our Magic Leap and wave our hands around and suddenly single page apps appear. I'm giving my opinion that React ecosystem will stay around for an absurd amount of time because unlike jQuery, the size of the community and usability of the tool scales really well. Maybe people said the same thing about Rails, or Motif, but I just feel like React is the end of the line for whatever we're doing here.
    • gaius 8y ago
      See if the question is how do you host an application on a server and run thin clients with local rendering and some limited local interactivity... then that problem keeps getting solved over and over again. X11/Motif and “React running in the browser” are fundamentally the same thing. Every solution actually works pretty well, fulfilling all use cases. Then for no reason we chuck it all away and start again. All of this has happened before and will happen again
• max_im 8y ago
  As someone who has built with both professionally, I'd say you're spot on. Vue has been great to work with because its readability and low-barrier to get started, but nothing beats writing plain-old JavaScript with some JSX. Not to mention, Vue can get really hairy with something as simple as passing props between components while React makes that a breeze.
  • Canadauni 8y ago
    Just to note you can use render functions and write jsx in Vue :) https://vuejs.org/v2/guide/render-function.html https://vuejs.org/v2/guide/render-function.html
    • threatofrain 8y ago
      But every time I ask about that, I get crickets. So who here is using JSX in Vue?
      • lsalvatore 8y ago
        Also curious about why someone would choose Vue/JSX over React. My argument is essentially in favor of JSX, if Vue or something else uses JSX in a more interesting way or creates something better than JSX, that's cool.
      • bdchauvette 8y ago
        I did once, about 18 months ago. A couple of problems I remember having: - Not all features (e.g. most built in directives) work in JSX, and some 3rd party libs didn't work at all as JSX components. - The JSX isn't a direct mapping to the object properties in `createElement`, which is how (almost?) every other flavor of JSX works. This means you don't just have to learn the the low-level `createElement` API, you also have to learn how that API maps to JSX. [1] For example, you can't do `<div domProps={{ innerHTML: 'foobar' }} />`, which you might expect if you just read the `createElement` docs. Instead, you have to use `<div domPropsInnerHTML="foobar" />` (but note that not all `domProps` actually need the prefix [2]). Likewise, event handlers use an `onEvent` camel case convention that maps to the `on` property in `createElement`, which is kinda nice because that's how you add event handlers in other JSX flavors. However, it also means that if a Vue component accepts an `onSomething` prop, you actually have to do something like `propsOnSomething` [3] in JSX, because passing just `onSomething` would convert it to `on: { something: ... }` instead of `props: { onSomething: ... }`. Overall, when I was trying to use JSX with Vue, it very much felt like a second-class feature, tacked on primarily (if not exclusively) to help convert people from React. However, Vue's flavor of JSX doesn't seem to appreciate that the simplicity of how React maps JSX to `React.createElement` is a large part of its brilliance. In other words, I think that Vue's flavor of JSX introduces just enough magic to make it confusing. It sacrifices consistency for haphazard ergonomics, making the experience frustrating for someone used to JSX being just an XML-like alternative syntax for `createElement` (or `h` or `m`). I think Vue's JSX would be much better if it didn't try to do any magic, and just forced people to write stuff like `<button on={{ click: () => {} }} />` instead. In the end, I gave up on using JSX with Vue, tried templates for a bit, didn't like them, and moved away from Vue altogether. Caveat lector: Things might be a lot better now. I tried to read up a bit to see, but I didn't dig very deeply. --- [1]: https://github.com/vuejs/babel-plugin-transform-vue-jsx#difference-from-react-jsx https://github.com/vuejs/babel-plugin-transform-vue-jsx#diff... [2]: But note that not all `domProps` actually need the prefix, either: https://github.com/vuejs/babel-plugin-transform-vue-jsx/pull/89 https://github.com/vuejs/babel-plugin-transform-vue-jsx/pull... [3]: This actually used to be impossible when I was trying Vue and JSX. It was only added somewhat recently: https://github.com/vuejs/babel-plugin-transform-vue-jsx/pull/126 https://github.com/vuejs/babel-plugin-transform-vue-jsx/pull...
• dereke 8y ago
  > With React there's no weird "v-if ng-if" template logic that you have to grapple with. To me, Handlebars already gave me enough taste of how horrible and limiting maintaining template logic outside of components is. React was a good step in the right direction. But IMO they lost the plot with things like: - shouldComponentUpdate(nextProps, nextState) - componentDidUpdate(prevProps, prevState, snapshot) and the whole props vs state thing. This adds so much unnecessary complexity to the code base. Thankfully I can get all the benefits of the react style without any of the awkwardness of its API with hyperdom https://github.com/featurist/hyperdom https://github.com/featurist/hyperdom
  • vanillapepsi 8y ago
    How is that relevant in any way? If you're using those two you're already doing something wrong. State is local props, props are from parent. How can that concept be "complex" to someone is beyond me.