[IDEA] Components represented as HTML elements rather than spacebars syntax. about blaze HOT 14 CLOSED

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.

from blaze.

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).

from blaze.

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).

from blaze.

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.

from blaze.

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

from blaze.

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.

from blaze.

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.

from blaze.

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.

from blaze.

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

from blaze.

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

from blaze.

@brylie True!

from blaze.

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

from blaze.

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.

from blaze.

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!

from blaze.