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 :)

This is something I've noticed-- spot on. Vue seems popular to people coming from the direction of "augmenting their HTML", whereas React is appealing to me precisely because it's all JavaScript.

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/ [2] https://github.com/jxnblk/rebass

It kinda bothers me when people say X won't scale (implying that React is somehow special in this regard).

For one thing, we're not talking about things like database throughput where you can actually have scalability bottlenecks.

If we want to talk about scaling maintainability, React is definitely not much of a poster child either, compared to other solutions I've used over the years. We got a new context API only recently to deal with concerns Angular had already accounted for years ago, and things like the Enzyme adapter state of the world is pretty terrible - and don't even get me started on React Router migrations :)

IMHO, one major thing Vue did right that React didn't which has an impact on scaling maintainability is that Vue owns its most important peripherals (data management via vuex, styling via single file components, animations, etc). In my experience, the React model (also adopted by webpack and babel) is a real pain in the ass to support at scale as a web platform engineer, because many times you're at the mercy of some random dude with no connection to the core project and you end up having to settle with bizarre makeshift configurations, fork things or do other nasty things to get around random design direction changes.

I think you are reading wrong between the lines. There are no vue users who dont know javascript or are not using with it. The concern is really how are you mixing the two. vue is more of js inside html, while react is html inside js.

And its just a matter of opinion. I work on both vue and react apps and personally dislike writing html inside js. But if the project started earlier using react, I am not going to suggest a rewrite just because of this single preference.

The point is that some people/teams/environments prefer to not treat everything as a javascript app. Especially in the agency world -- thinking about one's website from a markup/design-first perspective is a totally viable thing. And if you have designers on your team (or for solo practitioners) you sometimes don't want to javascript all the things. It's great that you found an approach that works for you, but it doesn't mean that it's the only best way for everyone and every situation.

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.

And on the Javascript side Vue actually breaks existing assumptions about code. For example, it hoists methods and properties and makes `this` available where it can’t be available.

You can't do a.b.c if b is undefined and instead need to wrap it into satanic template extensions

One of the nice things about Vue IMHO is how it leaves more flexibility to the developer to choose the right path.

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.

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.

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.

React doesn't really respect separation of concerns, and it's rare to find an SPA (and now, desktop apps -- thanks Electron!) that isn't complete garbage. Disciplined approach with battle-tested techniques creates much higher-quality software, every time.

Also, "paradigm shift" is nonsense. The web is a platform -- fetishizing specific tools and techniques is foolish. There are many ways to skin a cat.

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#diff...

[2]: But note that not all `domProps` actually need the prefix, either: 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...

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.

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?).

  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 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.

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.

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.

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.

They won’t. jQuery was a much simpler concept and basically a fluent wrapper around a lot of existing APIs.

11 years later none of the browser APIs are not nearly as easy to use or powerful as jQuery. (Did you know that querySelectorAll returns an object that, unlike jQuery, isn’t an array and doesn’t have the same APIs? They added frigging .forEach to it only a few years ago).

Components are a more complex concept. You need data binding, and virtual DOMs (to prevent out-of-order janky updates to the DOM), and templating, and a solution for both global and isolated CSS, and..., and..., and...

These issues won’t be solved in the next 50 years. And that’s the reason no one uses (or talks about) vanilla WebComponents. Everyone is using any of the dozens of wrappers or frameworks on top of them.

Edit: added missing not in not nearly as easy

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!

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.

All of this has happened before and will happen again

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

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)

But I would consider React and Vue for building a larger scale, stateful application like Spotify or Slack.

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.

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.

    <ul id="example-1">
      <li v-for="item in items">
        {{ item.message }}
      </li>
    </ul>

As code goes in complexity Vue quickly becomes ... let’s call it weird: 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).”