[IDEA] Components represented as HTML elements rather than spacebars syntax.

[trusktr]

It may be nice that instead of writing

{{#some-component}}
{{/some-component}}
{{> other-component}}

we can write

<some-component>
</some-component>
<other-component />

This is more inline with other view layers (React, Angular, and others), and expands on the HTML standard rather than having a separate syntax just for Blaze components.

[mitar]

Hm, isn't this similar to how Jade is being used as an alternative way to write templates?

I think this could be done as an optional way to do it.

Or are you proposing that this should be the default for Blaze 2.0?

My personal opinion here is that I do like that Blaze is different from other frameworks and that this brings then people who like those different ways. It should be powerful to use and be easy to do things you can do in other frameworks, but I do not think it should be done in the same way. Diversity is good because people can then select what works for them. For me it is good that templating language (handlebars) is different from the language it is a template for (HTML).

[mitar]

But I do think that we should make sure that this syntax and Jade and other alternative syntaxes can be and are supported.

[aido179]

While using html elements would look really nice, I feel there is a very strong argument against it. From a semantic point of view, HTML represents the static parts of the page, while the curly braces used by blaze/handlebars/spacebars etc. represents dynamically generated content.

It follows a well worn paradigm used by php, handlebars and other tools that render HTML. That familiarity is a strong benefit of blaze.

[necmettin]

Using {{..}} rather than <..> makes it much easier to differentiate between an HTML element and a template element, which in turn increases readability. Using <..> would actually make finding things in text harder.

Even if we agree that <..> would be an acceptable alternative, it should be optional, if at all.

[mitar]

I suggest that along with comments, community uses also upvotes and downvotes on the initial issue comment so that it is easier to see how we feel about proposed ideas.

[brylie]

I would like to see Blaze move towards WebComponents specifications. In effect, Blaze 2.x can support custom HTML elements, taking a step towards WebComponents alignment.

[mitar]

Are you sure Blaze does not already support custom HTML elements?

[brylie]

I meant 'support the Custom Elements specification by aligning with the WebComponents standards'.

[necmettin]

This would effectively turn Blaze into WebComponents. I do not see why we want to make Blaze into something else (which is, let's be honest, uglier).

[brylie]

The WebComponents specification is an open standard. By contributing to the standards process, we can shape the WebComponents to have the beautiful qualities of Blaze, and vice versa.

[trusktr]

@brylie True!

[brylie]

Thanks for your positive reaction @trusktr. I have received mainly negative feedback when trying to discuss this idea.

[filipenevola]

I'm closing this issue because it's too old.

If you think this issue is still relevant please open a new one.

Why? We need to pay attention to all the open items so we should keep opened only items where people are involved.

[trusktr]

The popular framework Vue uses <custom-element> syntax for its components.

If a component is not found, Vue falls back to just inserting the <custom-element> into the DOM, in which case an actual custom element instance will handle it.

The same thing could be done with Blaze, for example.

The syntax is a lot nicer than curly braces (that's just my opinion).

It can totally work!