Why would people hate React (or JSX), but not Vue SFC, or even Angular?

Or even, do you hate lit-html?

I mean, all you are doing is either HTML-in-JS, or truly JS function syntax anyway. No real separation of concern here, unless you truly visually separate them.

I think HTML-in-JS is the basis of SPA, anyway.

Comments

[Roland Kainbacher]

I use React and Vue for more years now. The biggest problem on react is that it has no clean code. It's kind of a mixture, very bad to read and if you have to maintain it is a big problem.

VueJs is based on React and Angular and solve this problems in a very beautyful way.

I am convinced that react only exists because facebook invests a lot of money. Some times a bad tenology wins because of mony > VHS.

[Jim Montgomery]

React is a snapshot from the past in the evolution of frontend work. Over the years it progressively gets in the way of native features and hasn't addressed complexity, so what it offers is increasingly a cost, not benefit. Given the lack of awareness of modern native features and recently released higher level libraries that outperform both for development and users, along with strange polarizations like OO vs FP instead of OO with FP patterns applied appropriately, I'd chalk up this stuff to inexperience. Speaking for myself as well.

I see job listing mention unit testing and nothing about any integration tests and then when looking at their unit tests see it's higher level than unit. Given the performance of end user features are the determination of "it works" and "it doesn't work" I'd say the picture painted is pretty consistent.

I dislike React because it doesn't seem legit and I just find it frustrating to consume a perceive reinvention stuff with heavy marketing. Sure it may look cool and do something useful but why would I bother when something else works better? Just find myself seriously questioning what people are doing when the stuff they output begin to suggest a lack of competency. There's always something to learn, that's just being human, and it also means I can feel free to dislike any/all of these options entirely separate from mixing markup in templates in scripts or whatever.

[Jim Montgomery]

Random observations, without a lot of reflection (and no don't hate, or rather quite like and appreciate anything lit-related so far):
JSX is obsolete and irrelevant relative to natively supported template literals and transformations for backward compatibility.
React imposes unnecessary technical peculiarities/requirements on an already complex range of topics.
DOM diffing doesn't help in the way React does it, LitElement/lit-html performs better in the few cases where this makes a difference, especially relative to proper strategy.
While native Web and DOM APIs have matured React has stagnated and is in the way.
Overall React is the technical debt that jQuery was in times past.
It is odd to see new projects commit to React, except they must not have information or experience with the alternatives (LitElement, Elix, native, etc?).
In exploring using Deno I've come to learn the vast majority of NPM imports for testing, etc are generally becoming obsolete due to its included standard library and the ability to use the same exact API on the front and backend in development and testing.
I don't like the growing complexity in the patterns: tree and component types (also the case in Flutter, etc). Prefer instead to limit this complexity in various different ways.
In LitElement state management is clearer and less cumbersome based on my limited experience so-far relative to React and Flutter. In Flutter the Provider pattern mixed with local state was helpful and similar to various things I found easier to use in my own native Web Components work.

[Nick Mudge]

I suggest using Webscript: mudgen.github.io/webscript/docs/

This is creating the DOM in Javascript the right way.

[Pacharapol Withayasakpunt]

The website is broken on mobile.

[Nick Mudge]

Fixed. Thanks.

[Nick Mudge]

Thank you. I am making it work on mobile now.

[Bryan Winter]

That's totally fair, and I have no complaints about the architecture of react or JSX for that matter. It's an extremely solid and well engineered library.

Though as a general rule I try to avoid describing anything view related in code, and likewise I avoid describing complicated logic in views. When i build something in any language or framework I try to find a really stable subset of it, and write everything in that and I try to avoid getting clever.

It's probably a good rule of thumb for any SPA framework actually.

[Bryan Winter]

JSX Syntax is terrible. It reminds me of the old days when we had PHP inside ugly tags. Then we came out with template engines and the world was a better place.

SPA's have this problem generally, with qoutes inside qoutes inside qoutes making terrible to read templates. I prefer clean and simple templates with nothing more than a few capitalized key words inside mustache brackets. You don't need anything else, and anything else more complicated should be inside code and delivered as a value to the view. Languages inside of languages always annoyed me, and for more complex projects it quickly gets out of hand. Your essentially trading the spaghetti code of one kind for spaghetti of another, which then requires you to write ever more complex code to check the code.

It's the sort of design pattern that reminds me of John Stewart Mill's warning about how "The bureaucracy is expanding to meet the needs of the Expanding Bureaucracy."

Vue has the least annoying template syntax, so it's my go to for persona projects.

React as a whole is quite good and I'm a big fan. But I write as little JSX as possible, and when I do, it's almost always an actual value with data-binding instead of a method call to a method call inside a method call. Every time I see an arrow function inside a template I die a little on the inside. And before someone mentions how bad code shouldn't damn a language, I'd like to point out that React design docs actually encourage this pattern.

Angular has a different problem. There are about 5 ways to mark up html elements, to the point that you get that absurd banana-in-a-box syntax for stuff like ngModel, and again you end up with quotes inside of quotes because you have to appease the parser ... rather than having a unified syntax and forcing the parser to appease us.

[thedevkim]

because vue and react has better documentation.

[Daniel Ahn]

React's documentation was never good! And 4 years after hooks were released, they're finally releasing new docs (still in beta, only 20% of API docs finished). Huge pain point for React. Vue's documentation is very solid, very nice, even despite the need to juggle Vue 2 Options API and Vue 3 Composition API.

[HS]

A "long" time ago people used to put php/ruby with html and let it be generated on server. First they moved it to separate files then they started using SPA. It is in a way better to have application logic like UI stuff and validations run on client as you get scalability for free. However you still need to validate again stuff on backend. Now should be again forget the front thigs and get back to server? I don't think so. Same goes for HTML in JS. I'm more into Angular only because everything is separated. As for Vue i can see the point of having 1 file split in 3 sections. However Angular is slower then the rest and I'm just a backend guy.

[Jordy Lee]

You use vanilla JavaScript and vim? Well I write everything in machine code, like a real developer

[Michael Z]

I feel like react often introduces new ways to do the same thing and everybody refactors and updates all their libs to the new hot way of doing things. The most recent addition is hooks, which was supposed to reduce 90% of your code's complexity. Unfortunately, it only makes simple code simpler, everything else became harder and requires you to know the nuts and bolts of react, hooks and javascript. Some argue that's not a bad thing, but it's by no means progressive like vue. Consider all the devs out there whose "first language" is not JavaScript...

E.g the following will execute the useEffect every time it renders if you don't pass the item prop because it is considered new. Imagine setting state in the useEffect, you got yourself an infinite rerender without any sort of error message hinting to the solution, or even the problem.

const { item = {} } = props

useEffect(() => something(), [item])

[Jordy Lee]

I'm not sure I can agree with your comment about hooks making React more complicated. Of course, if you've only ever written class components and are using hooks for the first time, you can expect there will be some learning curve - as with anything. But I firmly believe the learning curve is worth it. The main points I disagree with:

• React continuously introducing new ways to do the same thing: I view this in a totally different way. Yes, ultimately React/Angular/Vue all do the same thing - decoupling application state from the DOM. But if the React core team is constantly looking for better ways of achieving this goal, surely that's a good thing? Otherwise we might as well all be using React.createClass still and never upgrading past v3.0.0.

• The next question then is "are these new ways of doing things better or worse than the old ways?" Regarding hooks, my experience is that they're much, much better than using classes when writing stateful components. By "better" I mean that after becoming accustomed to the style, it is much easier and faster for me to build an app. I can also scan and understand others' codebases written in hooks much faster.
  Additionally, with hooks there's less boilerplate code and React apps written with hooks are technically more performant than ones written with class components.

• Surely you'd rather have library maintainers who update their packages to support new features, rather than using some npm library which has been untouched since 2014 and doesn't support ES6?

• I can't comment specifically about the code snippet you provided, but I'm fairly certain React always warns you when doing weird things with setting state that cause infinite re-renders.

The caveat to my favourable opinion of hooks is there's still a couple of things I hate about them: firstly, how cumbersome/hacky it can be to properly add event listeners inside useEffect, and the currently poor solutions for async data fetching inside hooks (although this looks like it will be improved with the next major release).

Feel free to let me know if you disagree with anything