Thanks for your thought-out comment! Your criticism that JSX needs tooling support which used to not be good enough is valid.
A counter-point I could make is that you are not forced to use JSX but could have used nested createElement calls as JSX is “merely syntactic sugar”. There are libraries that make nesting createElement calls more succinct (e.g. react-hyperscript). Another solution would have been to switch the tooling (i.e. using another editor). Being a developer myself I know it is easier said than done.
You know, I’m not big fan of JSX either. Nontheless, I see it is a good compromise. Ideally, we could use a better host programming language that makes it possible to describe hierarchical/nested structures such that there would not be a need for syntactic sugar at all. Off the top of my head, Elm, Scala and Kotlin are examples for such languages.
Angular 2 is a great framework. The way we use React at techboi, i.e. together with TypeScript and MobX, feels like “better” version of Angular 2. So we conceptually agree with many of Angular 2’s decisions. However, the thing that you like about Angular 2 is precisely what I do not like for the reasons mentionend in the article. Plus, since Angular 2 has a separate templating language you have a similar (not exactly the same you described though) tooling problem that you criticized about JSX. E.g. if you want to have syntax-hightlighting or auto-completion, your editor must be aware of Angular 2’s template language. The main advantage Angular 2 gets by doing this is that they can optimize the templates at compile time. I doubt the optimizations are all that important, though.