Component naming and handlebars syntaxis in future

handlebars → hbx → ?

[Example]

JSX-like hbx syntaxis approach

Ember bring me ability to write less javaScript code. But templates syntaxis is pretty huge.

For example, why we do {{if (or (and a b) (eq d e) ) m n}} instead of {if {or {and a b} {eq d e} } m n}?

How we can pas “true” to glimmer component? <MyComponent isEnabled={{true}} />?

Do we really need positional params? {{some-component positionA positionB}}

Instead of it, we can apply convention to get param with same name from current context. It can help us to reduce code from <FooBar @name={{name}} /> to <FooBar @name />

We can specify special symbol for positional params - like #.

Or we can use this simbol for get param with same name from current context approach. <FooBar #name />

Why we need attributes in components? How often we use it? Why not to use html built-in "data" attributes for this case?

[Example]


	<FooBar 
		@firstName
		#lastName
	/>

	<FooBaz 
		@firstName={myFirstName}
		@onChange={action onNameChange}
		#lastName="NoName"
	/>
	
	{#each item as |items|}

		{if {and foo baz} 'bar' 'baz'}
		
		<HelloItem @firstName={model.name} />
		
		{t 'some.international.text'}
		
	{/each}
	

Points:

  • {{{
  • }}}
  • @foo={{bar}}@foo={bar}
  • {{if a b c}}{if a b c}
  • {{if (and a b c) d e}}{if {and a b c} d e}

Why?

Ember template:

{{foo-bar firstName=firstName lastName=lastName age=age birthDay=birthday}}

75 symbols to write (special 2-{, 2-})

Glimmer template:

<FooBar @firstName={{firstName}} @lastName={{lastName}} @age={{age}} @birthDay={{birthDay}} />

96 symbols to write (special 8-{, 8-}, 4-@)

HBX template:

<FooBar @firstName={firstName} @lastName={lastName} @age={age} @birthDay={birthDay} />

88 symbols to write (special 4-{, 4-}, 4-@)

HBX template (same names in context):

<FooBar @firstName @lastName @age @birthDay />

46 symbols to write (special 4-@)

40% less code to write

But… what if we will mark component attributes using @ and no mark for component arguments?

HBX template

<FooBar firstName lastName age birthDay />

44 symbols to write

Ember is always convention over configuration.

Why we need to write more templates code if we can apply simple convention?

Link to original gist

2 Likes

I’d love to see some discussion about the future of handlebars in Ember. It is confusing, since Ember Handlebars is no the same as regular Handlebars. There has been a pretty significant divergence.

At the same time, I’m a bit envious of {} in React, since it is totally less typing. I probably wouldn’t replace ( with { since it just looks much more noisy.

<FooBar firstName lastName age birthDay />

Looks really clean! And could totally work with angle-bracket components because we don’t support positional params. But it would be different from the way html handles similar syntax, e.g. <input disabled>. Maybe something like:

<FooBar {firstName} {lastName} {age} {birthDay} /> :man_shrugging:

And yes I kind of like using @ for native DOM attributes, since those get used much less. Plus we are adding {{}} for all of the attributes with angle-bracket components, and this. in templates. In the end it really adds up to a lot more typing (add in decorators for each action in es classes, etc…)

In terms of the future of positional params, <AngleBracket> syntax already removes support for positional params (although you can technically use <AngleBracket @params={{array 1 2 3}} /> to get around this.

While the mental model of knowing Handlebars syntax (or Mustache) in the past has been beneficial, now it is more of a sign of age and the small differences in Ember .hbs and other Handlebars dialects now is more of a tripping point than a benefit (as @knownasilya mentioned).

I’m not a big fan of nesting {} since it could be a bit confusing to JSX devs where { {} } is an object instead of a helper invocation. () still seems fine for nested helpers.

In terms of getting rid of the @ symbol I think that would be a step backwards since @ clearly defines HTML attributes vs component attributes and it more closely matches Vue :attr and native web component attribute invocation.

I know hbx is just a working name but I think glm for glimmer or some other extension entirely would be more fitting, which further separates from “Handlebars” and doesn’t lead to confusion with differences in JSX.

1 Like

I think the new name should be ‘sparkle’

Sparkle templates.

.spx ?

3 Likes

I vote for Glimplates or Glimees .glm

I personally like “glimmerbars”

Sounds like a yummy chocolate bar. I love it. :joy:

1 Like