Stored XSS requires some sort of backend, yes, but reflected and DOM-based XSS does not. Furthermore, all XSS is some variant of a contextual confusion where something that wasn’t intended to be interpreted as JS suddenly is.
jQuery makes XSS more common in several ways, and some of them are really just the influence jQuery on the frontend has on how the back end works. Some of those ways are pretty subtle, eg CSP bypass gadgets in data attributes (which are very commonplace in jQ libraries). By contrast, React, by building a DOM, has contextual information that jQuery lacks. Go’s HTML templating is unique on the server side in that sense since it too actually understands if it’s in a text node context, a script context, an attribute context, or an inline JS (such as onclick) context, and hence the correct way to treat arbitrary input.
Of course, it’s not because you use React you’re immune. I got XSS against every site that used ZeitJS for example. But the pattern that lead to that (generated code dumped into a script tag) is a common pattern for pre-React frameworks.
jQuery makes XSS more common in several ways, and some of them are really just the influence jQuery on the frontend has on how the back end works. Some of those ways are pretty subtle, eg CSP bypass gadgets in data attributes (which are very commonplace in jQ libraries). By contrast, React, by building a DOM, has contextual information that jQuery lacks. Go’s HTML templating is unique on the server side in that sense since it too actually understands if it’s in a text node context, a script context, an attribute context, or an inline JS (such as onclick) context, and hence the correct way to treat arbitrary input.
Of course, it’s not because you use React you’re immune. I got XSS against every site that used ZeitJS for example. But the pattern that lead to that (generated code dumped into a script tag) is a common pattern for pre-React frameworks.