I agree that React's (and maybe other frameworks? I don't know them) conditional rendering syntax is very odd.
Like {my_bool && <Component />} instead of (if my_bool then <Component /> else null).
Or {my_bool || <Component />} (which is harder to express in most other languages because of Javascript considering truthy/falsy values instead of boolean true/false).
I am a fan of the UI-as-code approaches (as opposed to UI-as-markup or server-templating approaches) that React has though because of the other arguments you see in this thread, although the syntax could be better for React specifically. Elm is honestly pretty great in my opinion, and Flutter also has a nice language for describing UI as code. React just has less-than-optimal syntax.
I don't have a problem with map, though, except that I would like to extract the mapping function out of the "main view" into its own parameterised function that takes a list of whatever it needs.
What makes it weird for me is the filter/map/etc with an implicit destination, since function chains like that usually get rolled into a variable. It'd get you a compiler warning in Swift or Kotlin ("Result of call to 'map' is unused", etc). Agree that a for loop reads better in this case.
I suppose that depends on whether you look at it as a templating DSL within a JavaScript expression, or expressions within a templating language.
A `for` loop doesn't really make sense from the JS expression viewpoint — `for` loops in JS are statements, and in languages that do treat them as expressions they usually evaluate to the last iteration of the loop. From there, the filter/map makes more sense, since it's an expression that evaluates to an array of template-y stuff.
If you see it primarily as a templating langauge, though, the `for` loop makes way more sense — every iteration, it's adding a string to the template.
I'm not sure how to back that up... just look at it! Weirdest way I've ever seen to implement an if statement in a template.