@zens@merveilles.town not exactly. React doesn't deal with template or html strings at all at runtime, it compiles to "hyperscript", aka, 1000s of "document.createElement()"s in a trenchcoat. And the hyperscript it generates is always fundamentally xss-proof unless you use the " danger" functions.
Other frameworks like angular 1.4 that used string templates were never fundamentally xss-proof... They were like input sanitizers, so it was always a cat and mouse game between attacker and defender.
There is a fundamental difference between trying to sanitize inputs vs explicit separation of code vs data. Similar to the difference between parameterized SQL queries and special "SQL template" tools that would try to sanitize inputs. There was a similar cat and mouse game w/ those.
@zens@merveilles.town react is not the only game in town for this kind of strictly enforced code vs data separation, but its definitely a popular example.
In vanilla js, one would simply stick to document.createElement and element.textContent and everything should be fine.
Tools like htmx fundamentally don't do this, they load the HTML from the server and execute it as code, so the server is responsible for making sure its templating is clean.
Its harder to be sure its right without access to the actual DOM implementation that the browser uses, google search had an xss that was caused by differences between two different html parsers/serializers, the one they used on the server vs the one they used on the client side.
