<?php include("https://otherdomain.com/somephpcode.txt"); ?>
PHP got ridiculed for years for having this sort of stuff available (even if off by default eventually).
<?php include("https://otherdomain.com/somephpcode.txt"); ?>
PHP got ridiculed for years for having this sort of stuff available (even if off by default eventually).
A closer analogue to what React does would be comparing XHP[1] to JSX, but even that misses the isomorphic aspect of a SPA with SSR, which is almost the entire value proposition, because it allows you to only need to write your component code once while reusing the same render cycle at browser runtime.
It should be pretty evident that PHP-style CGI scripting is not ideal given that even early on many PHP apps moved to using template systems like Smarty and never actually embedding HTML directly into PHP code.
An additional of JSX in particular is that it’s render-target agnostic. Yeah you can render JS/DOM, and HTML… and CLI, and native UI APIs, and smart TVs, and WebGL, and…
(I know there are similar solutions for some of these in the others, but JSX was specifically designed to accommodate this.)
Loading code from remote domains can be abused and mis-used in any language. In this case, I think it's considered a "feature" because code was already being loaded remotely with NPM, who in turn got the code from the original author.
Now you can load the code directly from the author. So instead of trusting both the author and NPM, you only need to trust the author. This could be considered a reduction in your attack surface area, and it's definitely helping with the NPM registry being a single-point-of-failure in the Node.js ecosystem.
myRemoteLib = require(userGeneratedVariable)