idea/question: Handlebars as alternative to JSX?

[Jeff17Robbins]

Hi. Your project looks really great. The S package is super performant -- congrats!

We're somewhat stuck on the Handlebars approach to templating, and were wondering if your architecture support Handlebars instead of/in addition to JSX for the templates?

For example, incremental-bars implements Handlebars but uses incremental-dom as its backend, instead of strings.

But I like your approach of going straight to the DOM. It feels similar to Ractive , which has the Handlebars goodness, but, alas, not the speed of S.

I guess one possibility would be for Ractive to leverage S in place of its current data/computed model? But another possibility would be for Surplus to offer Handlebars support.

Of course, we could just learn JSX instead... :-)

[adamhaile]

Hi Jeff --
I don't have handlebars support on my roadmap right now, sorry. JSX isn't my favorite syntax, but one thing that it has going for it is that JSX is just an expression in JS semantics. That makes it easy to integrate with S's functional orientation. Handlebars is different: scoping is dynamic, based on context, and the interpretation of helpers is dynamic as well, depending on the kind of value returned. So it's not just another syntax but another semantics as well. It would take some runtime support to handle that.

Thinking aloud, if there were a translator that took the AST used by one of the existing handlebars parsers, like incremental-bars or htmlbars, and converted it into the AST used by the surplus compiler, then it could re-use the surplus backend (transforms and codegen).
-- Adam

[ryansolid]

On a similar token have you considered ES6 template literals? I guess you lose the ability to package functions as components which is huge, but on the tradeoff no special syntax and uses pure ES6 javascript. No helpers or context required either. I guess because it's precompiled the template literals don't actually help much. And JSX having an established syntax for binding wins out.

[adamhaile]

Yeah, I have looked at template literals as an alternate syntax. Avoiding the need for a build step would be a definite plus. The challenge is that in order for automatic dependencies to work, you might need to wrap some of the expressions in lambdas, something that is done for you automatically by the current surplus compiler.

So for instance, the equivalent to the JSX expression:

<div className={foo() ? 'foo' : 'bar'}></div>

might be something like

html`<div class=${() => foo() ? 'foo' : 'bar'}></div>`

Note the () => inside the binding.

It probably wouldn't be quite as fast as surplus, as some optimizations wouldn't be possible and others might take too much runtime, but no compile phase would be nice.

[luwes]

@Jeff17Robbins I built Hyperstache for just this use case, works with most tagged template solutions out of the box. https://github.com/luwes/hyperstache

[ryansolid]

Mind you Surplus is not one of those Tagged Template solutions. So I think @luwes was trying to say is if you are interested in a library similar to Surplus where you can use handlebars he has created the library Sinuous. This is a good option but has the tradeoffs that @adamhaile highlighted.