I'm currently working on a project where some people had a bright idea of implementing this exact <If /> via a component instead of babel transform, so not only it looks like shit, it also breaks if you mention something that doesn't exist at this point...

Some reasoning would be nice.

I'm guessing this is mostly a nicety to paper over the fact that 'if' is not an expression in JS, so you have to do things like

    var foo;
    if (something) {
       foo = <SomeComponent.../>;
    } else {
       foo = <OtherComponent .../>;
    }
    
    <Container>
       {foo}
    </Container>

whereas if JS has if-expressions, you'd just say

    <Container>
       {
         if (something) {
            <SomeComponent.../>;
         } else {
          <OtherComponent .../>;
         }
       }
    </Container>

(or similar). From that perspective it seems like a nice little thing to have.

Dart actually observed this exact thing and added if expressions inside the language; more exactly, "if" works as an expression if it is inside of an initialization of a collection. It might seem a bit less elegant that the semantics of such an important token changes with context, but I think it solves this particular problem pretty well.

Dart also has spread operators and for-expressions to make writing "UI with code" much easier. It's fresh to see how language design choices are being made more by pragmatic ones (for Dart it's the fact that it's primarily being used for Flutter to make UIs) instead of ideological ones (One might claim that "if" should be a pure expression following the tradition from functional languages like ML, but that also has its own set of problems in a language designer's perspective)

https://medium.com/dartlang/making-dart-a-better-language-fo...

Yup, it's such a small thing, but it actually makes a huge difference. C++ has the same problem when dealing with optionals, etc. etc.

(I know absolutely nothing about Dart, but it does sound a bit weird that the expression-ness of an if is contextual. Is there a good underlying reason for the exceptionalism here?)

How come?

I'm not the person that insulted the plugin, but I had a less than positive reaction to it too. I would say that this is putting into the template what belongs as JavaScript.

In pretty much every case, where the README shows the "before transformation" and "after transformation" comparison, the "after" part is what you should be writing to begin with. This feels like adding an extra layer of abstraction just for the purpose of not learning to do some simple things in JavaScript itself.

I would be pretty annoyed if I started working on an existing React project and it had that sprinkled across all the components.