combining jsx with template dsl control flow seems likely to put off

[bughit]

The selling point of jsx, AFAIK, was: we already have a language for logic and control flow, let's not program in an awkward sgml dsl.

If one buys into that notion, combining js with sgml for logic and control flow is unappealing.

The docs mention that otherwise, "This means helper functions." Ok, what's wrong with helper functions, assuming they can get the job done? Perhaps there should be both? Either way its a dsl, but a js dsl seems preferable to an sgml one, when you're already in js.

[ryansolid]

I wrote a long explanation I was quite happy with, with code examples but it seems to have been lost (I guess I never hit "comment"). So I will try to do this again.

1. When you are actually defining your template you generally in JSX at that point rather than in JS expressions. Using the control flow components actually pushes that context change further down. Especially in conditionals. There is less context shifting which actually sort of tightens up the view code. Especially when the predicate contains a large block of code. It reads a little nicer IMHO.

2. You hit this sort of composition pretty quickly anyway. Creating like <PaginatedList> or layout components. This patterns extends out once you get past the simple examples. We are used to seeing things like <Suspense> and <ErrorBoundaries> now or like <Context.Provider> it just makes sense that these sort of more advanced behaviors that depend on hierarchy fit so cleanly in the JSX. This isn't limited to Solid. Normal composition patterns and newer React APIs seem to agree.

3. Using the helper is always an option and Solid exposes mapArray but it leaves you to handle the reactive wrapping yourself. This is a consideration that only applies to reactive libraries mind you, but it makes JSX a better fit. I think this just lends to a cleaner experience. Compare:

<ul>{ mapArray(
  () => props.list, 
  item => <li>{item.description}</li>, 
  { fallback: () => <Empty /> }
) }</ul>

<ul>
  <For each={props.list} fallback={<Empty />}> 
    { item => <li>{item.description}</li> }
  </For>
</ul>

This is easier to show and leaves less room to make accidental mistakes of omission. There is also a slight benefit that since it's a component Solid can also be a little smarter with its heuristic that actually reduces reactive wrappers. We save one on the expression that wraps the mapArray call which in itself could be reactive. One reactive wrapper at the root of the map is probably negible. But might show up in some extreme nested case. Mostly I just want to point out it is more clear the intent so there is more opportunity to optimize at the analysis stage even if it is a runtime mechanism.

[bughit]

Your second example does look cleaner, but that doesn't address the mixing concern. I don't have a problem with pure jsx of react or pure template dsl of vue, it's the hybrid that's off-putting.

You appear to be pointing out and it's starting to dawn on me that raw js is really not suited for fine-grained reactivity in rendering code.

here's another react conditional example

function Greeting(props) {
  const isLoggedIn = props.isLoggedIn;
  if (isLoggedIn) {
    return <UserGreeting />;
  }
  return <GuestGreeting />;
}

My impression is that this won't work in solid (if isLoggedIn() is reactive), will it? Would you use a <Switch/> here?

Doesn't all this suggest that a template dsl is a better fit for fine-grained? So for example Vue 3 could go fined-grained transparently at any time by properly instrumenting their templates (and dropping custom render), whereas react cannot.

[bughit]

My impression is that this won't work in solid

https://playground.solidjs.com/?hash=1577101592&version=1.0.0

[ryansolid]

The hybrid tends to happen anyway as soon as you are writing real apps which is my 2nd point. I gave my thoughts in the comments of this article: https://dev.to/redbar0n/what-happened-to-components-being-just-a-visual-thing-22hc

You are correct the example in Solid would never update. The easiest would to use Show or Switch could put a ternary in a JSX fragment. Could return a createMemo. Vue's templates could change their approach to templates without the end user being any wiser so custom DSLs do have benefit there. The composability is what attracted me to JSX. Most template DSLs do not have all the features I'm looking for. The ideal would be somewhere in the middle in my mind. Template DSLs with more function like semantics. This in itself would be a huge undertaking. I don't think any existing DSLs are there and honestly at this point sort of want to pick your battles. The amount you get for free (TypeScript, Code Formatting, Syntax Highlighting, Tool support) just makes this difficult tradeoff especially where I was starting from. I attribute a large part of Solid being where it was since it didn't need to invest so much there. And JSX is like 90% of where I'd like it to be.

[rturnq]

I would say that JS is perfectly good for fine-grain reactivity but JS is not well suited for expressing rendered content in a declarative way that is easy for authors to understand. HTML is generally acceptable for describing this with the added advantage that it the platform language on the web; however, it fails to adequately express much more than static content. This mismatch is why all the major UI libraries use some DSL be it JSX in React or Vue's template language.

I'm not entirely clear what you mean by mismatch, or how Solid violates JSX "purity". I would actually argue Solid pushes authors toward putting more of the view logic within the JSX template thus reducing its distribution throughout the codebase. The example above looks like a typical React component which tend to be a JS function that returns some JSX, or in other words a mix of JS and JSX.

In React, because component functions re-execute due to state changes your example renders the different greetings in response to isLoggedIn as you might expect. This is not due to some inherent property of JSX, it is just a detail of how React is designed and implemented - if they had taken a different approach like Solid, this would not be the expectation. In Solid, because components are just factories which run once for every component instance, there are a different set of expectations, benefits and drawbacks.

Technically your example works fine, but likely not as you expect because isLoggedIn is not reactive (by design) in the context of the component factory. There are valid reasons one may create a component with a branch condition like this. For example to have different behavior on the server and client or making a decision on some constant value.

[bughit]

how Solid violates JSX "purity"

jsx is not just the x, it's a combination of js and x. The original intent is to have all logic and control flow in js and the x is just for creating elements.

the js in react jsx is plain and arbitrary javascript, and that is its appeal. JS in solid jsx is restricted (the react example I posted does not work) and furthermore needs to be augmented with either helpers or template dsl control flow constructs.

Technically your example works fine

We are discussing reactivity here, so not being reactive is not "fine"

I would actually argue Solid pushes authors toward putting more of the view logic within the JSX template

It seems you are making my point. If you push your view logic into the template, it's no longer jsx, just the x. You now have a template dsl. So why not go with that and not pretend that you are using JSX?

[rturnq]

JSX is a syntax extension to ECMAScript's PrimaryExpression whose only intent is to describe tree structures with attributes in a familiar way. Because it allows for embedding arbitrary JS expressions, and describing a node's children, conditional rendering/control flow is already part of JSX.

Formalizing common use-cases into components which are performant, easy to use and improve code clarity doesn't fundamentally change what JSX means within the context of Solid. As @ryansolid pointed out, React doesn't shy away from this approach either with things like Suspense. Furthermore, Solid does optimize practices common in React such as ternaries and logical and given they are part of the JSX expression an not the factory function.

I still maintain the fact that Greeting example works has nothing to do with the "correct" usage of JSX but simply the nature of components re-executing when state changes - simply a design decision React made which works well with a virtual DOM.

We are discussing reactivity here, so not being reactive is not "fine"

Ok, that's fair. I just trying to suggest that there are valid use-cases for being able to branch in the component factory that are exclusive of those conditions you want to be reactive. Someone may intentionally write something like this which for me actually increases expressiveness and control.

The benefits I see of using JSX are it is:

• Well designed, expressive, easy to use
• Familiar and understandable
• Has existing tooling and in particular TypeScript treats it as a first class citizen

So other than handling arrays without something like mapArray or For, I see little benefit to reinventing the wheel with tons of downside.