I find the popularity of JSX-style templating really surprising.
<div>
<h1>Conditional Display and Looping in JSX</h1>
<ul>
{this.state.items.map(item => (
item.show ? <li key={item.id}>{item.name}</li> : null
))}
</ul>
</div>
That seems like such an unintuitive way of implementing loops and if statements!
I helped design the Django template language, where the above would look like this instead:
<div>
<h1>Conditional Display and Looping in Django Template</h1>
<ul>
{% for item in items %}
{% if item.show %}
<li>{{ item.name }}</li>
{% endif %}
{% endfor %}
</ul>
</div>
I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.
Maybe because you’re thinking of it like a template language. It is not. It is JavaScript through and through. And mapping over an array is quite idiomatic. So are ternary operators. If you really prefer you can pop that out into a for loop with a full-blown if statement, but that’s not very common—at least not in React.
I think the long history of being served over the wire drove the community to prefer shorter, more terse code.
> Maybe because you’re thinking of it like a template language.
I think they just looked at the JavaScript example, and realized how ugly/unreadable it was, and said "I can do better", and they did. the Django example is actually clear and readable about whats going on.
the fact that the community converged on the current monstrosity should bring great sadness, not rationalizations.
Here's my perspective, as someone who's done a lot of JavaScript app development and recently onboarded into a Django app:
- JSX composes normal JavaScript expressions. That means that every operator/function/etc I have access to in JavaScript is also available within JSX. With Django templates, I need to create a custom tag or filter.
- JSX desugars to a normal JavaScript expressions. That means I can store it in a variable, return it from a function, etc.
- JSX returns structured data rather than a string. That means it can be used to support output formats other than text. This isn't so much of an advantage for web dev, where you want a string, but it's a "least worst" situation if you use React Three Fiber, React Native, etc.
- The aforementioned type safety is nice!
On the other hand, I imagine Django templates are significantly more welcoming if you're more familiar with HTML than JavaScript.
By the way, the ternary in your JSX example can be removed by filtering the array:
<div>
<h1>Conditional Display and Looping in JSX</h1>
<ul>
{this.state.items
.filter(item => item.show)
.map(item => <li key={item.id}>{item.name}</li>)}
</ul>
</div>
I love Django. I will be the first to throw spears at modern JS dev. Django's template language works well for simple cases. By design, it is restrictive compared to a proper programming language. I find this to be problematic.
For things beyond if/for statements, the solution is usually to write custom tags in a DSL that I have a hard time grokking. With JS, you can write arbitrary logic in an imperative language.
Personally I've come to prefer the design of Jinja, because it supports a larger set of Python syntax. I like that Jinja lets you use full Python expressions.
We designed Django (back in ~2003) with the idea that it should be usable by frontend developers who just worked in HTML and CSS, which isn't really a category that exists much today any more.
We used {% %} for tags rather than XML-style partly because we wanted the tags to remain visible in Dreamweaver!
Came here to agree with this. Beyond basic conditionals and loops, Django templates get really hard to read IMO. Combine that with “sprinkling in” some HTMX and Alpine and you’ve got the making of a true headache that no one wants to work with, even though it technically gets the job done
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.
Personally I think ternarys should die in a fire. I despise them. Like, of all the thing validly deserving of syntactic sugar... that's the case that's "important"? It's neither especially common, nor is the sugar very nice to read.
As soon as you need a 3rd leg you have to rewrite it as a full blown if/case/whatever anyway.
Not sure why this is getting downvotes. Ternaries are at best a necessary evil in JSX. We'll all be rejoicing when pattern matching finally lands in JS [1].
If you do proper server side rendering you wouldnt even have if statements in the template. your backend code should have divided everything into correct buckets for you to iterate through them. application logic shouldnt be in your view.
I wonder why JSX didn't just go all the way with the language (arrays and objects) to represent html tags and attributes, it would have cut the noise by 50%.
I helped design the Django template language, where the above would look like this instead:
I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.