Guys, any information when HTMLBars will be ready?
Thanks!
@johnny_bushy I think you may have mis-read my comment. What I meant to say is HTMLBars Ember apps will look exactly the same as Handlebars Ember apps. Any new syntaxes will be completely optional. If you write an application with Ember 1.7 (stable today), it will Just Work when we release HTMLBars.
@jimmyps It is coming, but please understand that the effort is pretty much entirely a volunteer one. Currently we have an optimistic goal of landing it with 1.10. A simple way to help is to test apps against the current beta of Ember (1.8) before we go stable.
3 Likes
@Mixonic, random question, whatās the plan with {{bind-attr}}, I understand it wonāt be needed, but will it be reimplemented anyway as per SemVer?
@joe exactly. HTMLBars can and will support a number of neat new syntaxes, but the existing ones will work as they do today.
Ember follows SemVer pretty strictly. When HTMLBars lands in a 1.X series you can be certain that the public API from 1.0.0 will still work.
tldr; Yes, both <div {{bind-attr data-blah=someProp}} and <div data-blah={{someProp}}> should work properly.
@mixonic Appreciated the update. I have an important project coming next month, and would prefer to use HTMLBars in the project. Do you think 1.10 can land next month? Possibly around mid or late October? (Just rough estimation is alright)
@jimmyps Is there any particular reason you donāt want to write your app in Handlebars? As was said, youāll be able to take advantage of HTMLBars whenever it lands in an official release. (That actual date is not known at this time).
@samselikoff The main reason is that HTMLBars provides much cleaner syntax and natural way to build Ember-based apps. If I wrote the app with Handlebars now, I would have to revamp everything to HTMLBars later on. Since the project will have a lot of views, I guess itās best to write the app with HTMLBars directly instead of rewrite it again later. Let me know if you have any thoughts or feedback.
@jimmyps Ember provides way more than just a template syntax, and I really, strongly, suggest that you donāt wait for a new template syntax before starting an app. It delays your project for something that canāt possibly mean too much to your client or business. If the syntax or performance benefits are crucially important, then I urge you to consider getting involved in development or sponsorship.
Ember follows a 6 week release cycle, very publicly:
1.10 is expected to branch into beta on November 14th.
Donāt confuse a cleaner DOM with cleaner syntax. Not having to use {{bind-attr}} for attributes is cool and all, but the real reason that people are pumped about HTMLbars is that it doesnāt inject a bunch of arbitrary script tags into the DOM and it doesnāt have to translate strings into DOM elements, meaning faster performance. This has almost no impact on how you will write an Ember application. The most meaningful difference is that one day, your app will magically be significantly faster.
If youāre that desperate to get rid of metamorph tags, the precursor to HTMLBars (Metal Views) is active on the current beta.
I just wanted to download some āunstable/night/developmentā build to try it on my own risk and integrate it in the development process 
Is there any? Could you please provide it via email for example?
I promise, I will help with reporting bugs while usng it Seems like itās the only way I can help the development process.
@johnny_bushy HTMLBars is developed entirely in public, all the pieces are out there. If you want a version of Ember itself running HTMLBars, when we have that it will land in master of Ember.
@mixonic the htmlbars-* branches havenāt seen any updates since the end of June, is development happening somewhere else?
Is the ārefactored view layerā in 1.8.0-beta.1 not HTMLBars?
@opsb before we can even work on HTMLBars in Ember we need 1.8 to be stable on IE8. We need helpers to be implemented with streams, which @mmun is working on. We need a server-side pre-compiler for HTMLBars, which Jonathan Jackson is working on. We need Saucelabs running on the HTMLBars repo to catch regressions, which @fivetanley is working on . Then we can finally get around to adding a feature flag for HTMLBars to master. Iām un-sure if that branch will figure in this story or not.
If you have significant time in the next few weeks or can support someone to get this work done, fire over an email! You will need to get up to speed but if you set aside the time, I can probably find something we need to do for you to grapple with.
@hooper correct. The metal-views (in 1.8) paves the way for HTMLBars, but it still a view layer based on Handlebars templating.
1 Like
@mixonic thanks for the update, I realise thereās an awful lot of work to be done to get HTMLBars out the door. As it covers so many different areas itās sometimes difficult to get a feel for whatās going on.
Iād absolutely love to get involved but Iām currently sole developer on one startup and half of a two man team on another. My evenings and weekends are already taking a hit. Iāll certainly be there as soon as thereās a beta(or alpha) to try and work through the bugs.
I think the HTMLBars project is a bit unlucky in that expectations were set way to high in terms of when it would be delivered (I think we were originally expecting a release in the first quarter of this year). Everyone appreciates all the work you guys are doing though, we just canāt wait to get started using it!
Agreed, the hype machine went a bit too far here, but we are definitely making significant progress forward.
Go team, GO!
Thanks for the hard work! Looking forward to the grand release! 
@mixonic Iād like to help!
IE8 must die. Who cares? Itās an unnecessary blocker. HTMLBars is much more desired. Old attr-bind syntax is a pain in ass. If somebody need to support crappy ancient browsers he can always use KnockoutJS which supports even IE6.
3 Likes