A challenge: figure out how to get to the script data double escaped state (https://html.spec.whatwg.org/multipage/parsing.html#script-d...), or perhaps cheat by looking at https://stackoverflow.com/questions/23727025/script-double-e.... Then, contemplate the implications, and devise an injection attack for something that is foolish enough to try to emit anything user-controllable into JavaScript (suppose it’s a string: they may have thought it was enough to escape \ and ", but this will rapidly show you that it’s not).

Reading through the specs reveals lots of curious historical details. The HTML spec is a glorious tangled mess because it’s an exhaustive definition of a large amount of functionality that grew⸺ ah⸺ organically.

The reason for the error from Babel is that JSX is an HTML like (more so XML) syntax, not HTML. The obtuse comment syntax is because you need to escape to JavaScript with the braces, then use a multi-line JavaScript comment block. I wish they would've allowed HTML comments in the original design, but my guess is that comments were an oversight that just happened to work due to the escape syntax.

One good reason not to support it is that it’s ambiguous: is it a comment (to be ignored), or does it represent a comment node? If the former, why not just use /…/? If the latter, it requires that the library or compilation target or whatever support comment nodes, which is more work for a dubious feature.

I'd argue that comments only serve to help the developer. And when using JSX, the generated HTML might not look pretty (such as being a single, long line). So an HTML style comment in the JSX should be stripped because debugging the minified HTML isn't something people generally do.

And if, for some reason, you wanted to inject an HTML comment into the output, you could abuse the `dangerouslySetInnerHTML` prop like this:

    function Comment(props)
    {
        return <span dangerouslySetInnerHTML={{__html: `<!-- ${props.comment} -->` }} />;
    }

Then use it like this:

    ...
    <Comment comment="my comment" />
    ...

Using `React.Fragment` doesn't work, sadly. Use the "Inspect Element" tool on the output here: https://playcode.io/870223

There are other use cases for (preserved) HTML comments in (or produced by) JSX, but generally more for library authors than end users. For example, comments can be used for hydration markers to delineate “hydration islands” without need for a wrapping element. (I have a proof of concept of this sitting in a Codepen somewhere.)

And while it doesn’t work in React’s Fragment, it can certainly work with another compiler. JSX doesn’t specify anything about what it compiles to, React.createElement/_jsx are just defaults.

It shouldn't be hard to create a component that does what you want

<Comment>some comment</Comment>

The syntax highlighting in Fx dev tools has the same mistake as the article in that they only recognize the "close comment" token if it's at the beginning of the line, even though the spec clearly states that it may be preceded by any number of single-line "multiline" comments on the same line.

However, the way I understand the spec, you shouldn't be able to start a line comment with `-->' after an actual multi-line comment (i.e. a delimited comment that contains line terminators); however, both Firefox and Chrome seem to disagree with my interpretation; for example

  i = 1;
  while (i /*
            */ --> 0
  )
    console.log(i); // this loop never terminates

I’ve literally been programming in JS for more than 20 years and this is new to me too!