I must admit that our main reason for choosing Ember was because that at the time it was the only framework that declared its going to have IE8 support for the see able future. Since our product is directed to Enterprise users we still have to support IE8, but I’m trying to convince my boss thats not the case, and currently Ember 1.10 with HTMLbars (and maybe Handlebars I haven’t checked) doesn’t work with IE8.
I should probably try to fixed the minor issues with the template compiler and hope there aren’t any other issues, but past experiences going into ember code made me understand that would just make me sad and I have more productive things to do at the moment. So Ember for IE8 support wasn’t the best bet.
React on the other end seem to support IE8 but was a bit of a wild bet when we started to work on the app.
But I think you completely miss my point. React is really cool, and every js view layer is trying to imitate and improve what they are doing, It would be great if HTMLbars will have all of react features and more. But wouldn’t it be much better if Ember would be flexible enough to work with any view layer you choose to ? Wouldn’t it save so much time reinventing the wheel every time something new comes out ? I mean sure it would have to have a very specific API but any one who know both the APIs of Ember and the new View layer would probably be able to make them work together way more easily then it takes today to render strings from templates.
What is ember view layer API ? how do I keep enjoy all of ember core features but replace specific features with new stuff that I’d like to test ? Sure I can get the API after a few days of going throe the code (which is amazingly hard since most of Ember logic runs async) but how would I know what is a stable API and what will change on the next update? Since Ember explicitly refuse to support this kind of capability everything might change in future version and no Internal API is safe
Here is an example -
An ember core team developer gives a solution for something not knowing the API has already changed in the beta.
To be fair, when we choose to use Ember we knew about the “Omakase” way and that we wouldn’t be able to change any of the main features if will need to. We thought this limitation would be minimized by Ember doing the havy lifting for us, we just didn’t knew that a lot of the light lifting will become unbearable to impossible.
Now if I look at stuff that happening in newer version of Ember this issues do get better. Ember 1.10 comes with the template-compiler logic outside of ember core. I haven’t yet looked at the source changes but I’m planing to do so, but this is alone is a change that will make understanding and changing the template logic more accessible and straightforward. But I would like to see this happening with more modules and of course the documentation that will state what is a stable API that probably won’t change and what is internal unreliable methods which you shouldn’t use