(htmlbars) should inherit from Handlebars

[nknapp]

I am currently working on refining the handlebars-language to support literal-segments:

• example
• description

The Handlebars-tests are working fine with my changes, but HTMLBars detection testcase no fails... because highlight.js detects Handlebars instead of HTMLBars.

Now, the file that should be detected as HTMLBars, might was well be a Handlebars file

<div class="entry">
  {{!-- only output this author names if an author exists --}}
  {{#if author}}
    {{#playwright-wrapper playwright=author action=(mut author) as |playwright|}}
    <h1>{{playwright.firstName}} {{playwright.lastName}}</h1>
    {{/playwright-wrapper}}
  {{/if}}
  {{yield}}
</div>

In my oppinion, there is no need for an HTMLBars language, because the syntax is actually the same as Handlebars. It even uses the Handlebars parser to generate an AST. Couldn't htmlbars just be an alias of Handlebars.

I think the only difference really lies in the list of built-ins. HTMLBars/Glimmer/Ember seems to have many more builtin-helpers. But it should be possible to somehow handle that.

There are parts of the html-bars definition that should be moved into the handlebars-definition anyway (like sub-expressions).

I am willing to put some work into that. I just wanted to ask for your opinions first.

[joshgoebel]

I was thinking about this the other day actually. I think there are two ways to go here:

1. Merge them and make the master a superSet... so "htmlbars" would become an alias.

I think this sounds good at first glance, but then I think it starts to get complex later... like how we're forcing Javascript to be JS, JSX, etc... (the problem there is that JSX is quite a bit more complex than JS, but that might not really be the case with HTMLBars if it's just additional helpers rather than syntax changes) in another world you could have imagined just building JSON into JS if you followed this line of thinking too far.

2. Go with a dependency/clone instead, laying in the new keywords on TOP

I'd like to suggest (or float) an alternative... that HTMLbars be a superset that derives from handlebars... ie it should be a very minimal syntax that deep clones the handlebars syntax and then perhaps adds additional matchers/keywords on top.

This is also how I feel we should be doing cpp and arduino though it's not presently. One benefit is that the more complex grammar just wins by default... if cpp and arduino are the same but arduino scores 5 points higher, very likely it's Arduino code - and even if it's not, not much harm done.

Same in this case I'd think... if those additional built-ins raise the relevance and now we choose the HTMLBars grammar by mistake, not a LOT of harm done... I also think this likely has the advantage of being easier to maintain over time (cleaner separation of concerns)... though it's possible we currently don't have the tools to make this pattern super easy in PRACTICE (but we may).

I wouldn't want Arduino keywords to just merge into cpp, so that's why I tend to lean a little more towards choice 2 here.

[joshgoebel]

Read this and see if it changes your mind on anything. Looks like the big change is now you can put the {{}} tags anywhere.

https://colintoh.com/blog/htmlbars

Does that break how subLanguages currently work?

[nknapp]

Reading your comment, the following came to my mind: "htmlbars" actually depends on then parser of Handlebars 3, not the latest version. And there have been changes in Handlebars as well, and I'm not sure if "htmlbars" implements them

Partial blocks

{{#> layout}}
{{> @partial-block }}
{{/layout}}

Inline partials and decorators

{{#*inline "content"}}bar{{/inline}}
{{#*customDecorator}}template{{/customDecorator}}

I actually want to deprecate customDecoratory, but the syntax will remain with inline partials.

Now, this sounds like a base language with two derivates.

I also don't know if I really have the time and energy to implement all those missing things.

[joshgoebel]

Well, we do have precedent (recent) for "superset" if it "causes no harm"... so we added comments to JSON... since if you have JSON without comments, no harm done - they just aren't parsed/highlighted...

Now, this sounds like a base language with two derivates.

So I'm not sure by saying that if you're agreeing or disagreeing. :-)

[nknapp]

The examples on https://colintoh.com/blog/htmlbars do look like there is no different highlighting needed.

I agree with your second point, that "htmlbars" should extend "handlebars" and define custom keywords. If you think that the additional syntax causes not harm for "htmlbars"-highlighting we can do it like that.

The changes described at https://colintoh.com/blog/htmlbars do not really change anything in terms of highlighting, so it would mainly be the helpers.

[joshgoebel]

Does the sublanguage stuff already allow this:

<img src={{photo.thumbUrl}}>

I'm not that familiar with sublanguages... my head tells me we'd be in "html' mode and that would get ignored.

[joshgoebel]

I think this is a little hard now (from looking at ARduino and CPP) but would be much easier if we switched to a modular build system. What I really want (for Arduino) isn't the COOKED CPP data, I want the raw data...

IE, really Arduino needs to require the raw CPP metadata and then lay it's pieces on top... that also avoids any need to deep clone...

Then with only a few lines of code Arduino would require CPP, lay a few keywords on-top, then compile as it's very own language.

Although now I"m wondering if sublanguage might be relevant here. :-)

[nknapp]

<img src="{{photo.thumbUrl}}">

with the handlebars-renderer becomes

<span class="xml"><span class="hljs-tag">&lt;<span class="hljs-name">img</span> <span class="hljs-attr">src</span>=<span class="hljs-string">"</span></span></span><span class="hljs-template-variable">{{photo.thumbUrl}}</span><span class="xml"><span class="hljs-tag"><span class="hljs-string">"</span>&gt;</span>
</span>

and

<img src={{photo.thumbUrl}}>

becomes

<span class="xml"><span class="hljs-tag">&lt;<span class="hljs-name">img</span> <span class="hljs-attr">src</span>=</span></span><span class="hljs-template-variable">{{photo.thumbUrl}}</span><span class="xml"><span class="hljs-tag">&gt;</span>
</span>

In both cases, it looks like the mustaches are wrapped correctly in a <span class="hljs-template-variable.

[joshgoebel]

Well, I guess I need to go read the parser and pay attention to how subLanguages work. :)

[joshgoebel]

We'll see if Egor has any concerns but this is what I had in mind for CPP/Arduino:

#2185

Best of both worlds... and now Arduino is really more of a "subclass" of CPP. If we started doing this a lot we could add a little more tooling to make it easier.

[joshgoebel]

And he had no issues with my Arduino/CPP changes... so if the new Handlebars stuff really covers all the bases now I'd use the same strategy for HTMLBars... just make it a super-set of Handlebars, and then lay the new keywords on-top.

If there are no existing markup tests cases I'd add one or two before the changeover, just to get a working baseline.

[nknapp]

It's a breaking change though, because people who only load the htmlbars language (i.e from a cdn) will have to load handlebars as well then.