I'll take a stab, although I don't share the same absolute stance.
I've run the gambit when it comes to types of front-end projects. The React community has more focus on scaling React for large teams and companies. This isn't to say Vue can't do any of this, but there is a clear focus in the React community. I need to do isomorphic rendering because of SEO, there is a lot of React documentation on that and very little for Vue. I need static analysis for my code to prevent errors, Flow answers that. I need a replayable state for debugging errors, Redux gives you that.
None of what I mention about React is its sole domain. You can list off many alternatives.
Reading through why people choose Vue, many common needs come up. The one that I find interesting is needing a system that Designers can understand because they code up the HTML and CSS. I doubt that is something that comes up with React teams.
In my opinion, if you require a framework, Vue and React are two great options. It comes down to various small differences about your team needs. (Please stay away from Angular though.)
I love both React and Vue, but I feel the need to step in and defend Vue a little here.
Of the 3 points you listed, Vue has a section in the official documentation dedicated to Server-Side Rendering, ditto for using it with Typescript for static typing, and it even gives you replayable state with Vuex (the official redux-style library for Vue).
If I make a typo in the name of a component or the name of an attribute used in a HTML tag property, Typescript will catch it. Since Vue & Angular uses template strings, TS can't do the same check.
This makes catching errors and refactoring easier.
I used to prefer Vue, but since I've discovered Mobx, I only use React now. It took me a lot of time to properly learn the tools, but I'm pretty happy with them now.
This. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings.
Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern.
I'd prefer framworks like React or Riot any time over two-way-binding.
1. Bad Two Binding i.e. Two way binding between components. Vue2 and most of the UI frameworks shun this.
2. Good two way binding i.e. Form model binding.
Because form input can actually come from two sources (user input and javascript). this is naturally two-way and this is why frameworks continue to keep it.
I think the second one isn't really a valid example. There are very few situations where you both want to have state mutations discard what the user has already entered and reflect user-provided state in real time. In other words even if it's supposedly "two-way" you don't actually want multiple inputs to share the same model and you likely don't want to represent the data the same way the form control needs to represent it internally.
As an example, let's say you have a formatted text input field that can be used to enter a decimal number. If the input contains no decimal separator, the decimal part is implicitly zero. But if you just use naive two-way binding with an actual decimal value this means you'll get in the way of the user trying to manually enter a decimal value (especially if the user tries to delete the decimal part starting with the separator).
As soon as any information is lost during the bind in either direction, you still need to explicitly think about where you want the data to flow into and out of the form field.
The archetypical example of two-way binding is definitely the auto-generated CRUD form that lets you edit a model in place, but IMO this is a tiny niche in practice because it falls apart as soon as you want to do anything non-trivial. It's great for prototypes though.
EDIT: To clarify, I think you're talking about two-way binding a form model to form inputs. But calling that two-way binding from an application developer's POV is kinda redundant because you still need changes from the form model to propagate outside the form in a more controllable and predictable way than two-way binding offers, so the two-way binding of the actual form fields becomes an implementation detail.
> Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises.
Can you elaborate on this? The last time I wrote a native application was 6 or 7 years ago using Cocoa and Objective-C. If I remember correctly, Cocoa had a mechanism that was similar to two-way binding. Have things changed recently? What do modern iOS/Mac applications use?
Cocoa Touch (iOS) got rid of bindings altogether and you manage updates manually (although I use a bindings library to emulate the old OSX bindings support in one of my apps).
Not sure on macOS, bindings may still exist there.
That's exactly my point. The concept of bindings (in the sense of two-way-bindings) hasn't proved to be successful - neither today nor in the past, neither on desktop or in the web.
As a more general throught:
When comparing concepts or patterns, there are often discussions about which one is better, comparing different but almost equally good options. Choosing the "best" one is hard. So the list of advisable patterns is constantly evolving and changing.
However, some concepts clearly didn't pay off over decades across a huge variety of settings. These anti-patterns are quite stable, and more or less just growing, not changing. It may make sense to collect these ones.
The "good" concepts may be subject to fashion and evolution, but the "bad" ones are stable and hence worth collecting.
I've run the gambit when it comes to types of front-end projects. The React community has more focus on scaling React for large teams and companies. This isn't to say Vue can't do any of this, but there is a clear focus in the React community. I need to do isomorphic rendering because of SEO, there is a lot of React documentation on that and very little for Vue. I need static analysis for my code to prevent errors, Flow answers that. I need a replayable state for debugging errors, Redux gives you that.
None of what I mention about React is its sole domain. You can list off many alternatives.
Reading through why people choose Vue, many common needs come up. The one that I find interesting is needing a system that Designers can understand because they code up the HTML and CSS. I doubt that is something that comes up with React teams.
In my opinion, if you require a framework, Vue and React are two great options. It comes down to various small differences about your team needs. (Please stay away from Angular though.)