Ember 2.0 - Reducing the frustration

[yonjah]

Warning this is going to be mostly a rent

I just read this article - http://engineering.flipboard.com/2015/02/mobile-web/

You are welcome to read it as it describe a really interesting performance tweaking using Canvas rendering. But my main amazement from this article was how the guys who wrote their own rendering target could easily integrate it with React.

Will Ember be ever able to do it ?

I mean just finding a cool view layer like React or ReactCanvas or Whatever and integrate it with ember ? For the past few months I’ve been trying to figure out how the rendering process of an Ember App Works. All the docs are directed to how to use Ember none of them actually explain how the internal part fits together. In the end I just hacked my way throe which as I understand is the Ember way (If ember can’t do it just ignore it and use jQuery )

I’m sorry but every time before I try to do something new (and usually simple) with ember I take a big breath, make myself a coffee and get ready for the pain. and the most painful thing is that I know that in the end I will have to do stuff in a crooked way cause ember just can’t handle it.

I’m sorry but I’m not sure that the time it saves me to do amazingly complex thing is compensating for the time I spend trying to hack my way for doing simple things.

For example try to render an Handlebars Template into a string. Well you can’t and you know why ? mainly because Ember.Handlebars is not Handlebars but some mutated version that was massively changed to fit Ember.

How massively ? Well try to use Handlebars itself and you discover you can’t use any of your Helpers since they are only available on the Ember version. try to register your helpers with Handlebars Instead of Ember and you’ll discover that Ember templates actually call the Handlebars helpers if they don’t find there own helpers !

Yey! Victory? we’ll not quite because ember helpers are being wrapped with all kind of logic that I can only assume relate to the binding so when the fallback Handlebars helper is called it doesn’t really get the values properly and if you really want to use your helper both with Handlebars and Ember.Handlebars your only bet is to register it twice one time with Ember and the other with Handlebars.

So Ember cant even use Handlebars without changing it completely. I really hope that with HTMLbars the situation is different.

• Why can’t we have a bunch of reusable components that ember use without massively changing them ?
• Why everything has to be tightly coupled without no possibility to change ?
• Why is it so simple to create a view with 2 way data binding that save history state yet so hard to impossible to bind an event to the root of the document ?
• Why is it so easy to have a bunch of methods running in an async runloop but so hard to have an action that can conditionally decide how to let the DOM events flow (like only calling prevent default on certain condition) ?

I’ve been reading “The Road to Ember 2.0 RFC” The Amount of changes there is amazing and will surely benefit the framework, but if I look at the final section -

Version 2.0 marks the transformation of Ember… …and a growing ecosystem that makes taking advantage of additional libraries a breeze, there’s no better way to get started and stay productive developing web apps today.

“taking advantage of additional libraries a breeze” is probaly the most important thing for a modern framework in a global ecosystem that change constantly but I couldn’t understand from the rest of the RFC what changes will happen that will remotely allow it.

As always I might be missing something, I might be missing the article or docblock about ember rendering flow and API (what API do I need to implement to replace HTMLbars ?) I might be missing the code comment that explain how events are being registered and how to use the event dispatcher if so I’d be grateful if you could share the links with me

[atsjj]

Interesting rant… I guess I gotta ask, why are you using Ember?

Please don’t misunderstand, I’m honestly trying to learn your perspective.

I don’t know if you have had the chance to check this out, but @wycats is cookin’ up something pretty cool https://github.com/tildeio/htmlbars/pull/282.

If you’re looking for documentation of the metal, you won’t find a lot on the Ember website. The best documentation for that kind of stuff is actually the unit tests; they will tell you quite a bit about how things work in depths of UnderEmber.

[yonjah]

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 -

How to render a template to a string

When looking up a template, e.g: var template = this.container.lookup('template:greeting'); You can’t do anything useful with it, like render to a string. It would make sense to be able to do: template({msg: 'hi'}); Because then the precompiled templates could be used with other libraries that utilise templating, for example Typeahead.js (I’ve looked everywhere for a solution, including all the tests in github - but these all pass the template into a view, insert it into the DOM and then re…

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

[lfridael]

@yonjah

“taking advantage of additional libraries a breeze” is probaly the most important thing for a modern framework in a global ecosystem that change constantly but I couldn’t understand from the rest of the RFC what changes will happen that will remotely allow it.

I expect that one-way bindings (which will be the default in Ember 2.0) will make it easier to integrate other libraries. The way I see it, two-way bindings cause the relatively tight coupling between modules in Ember 1.x.

[atsjj]

I see what you’re talking about.

If I was going to hack on this idea, the idea of a different view layer, I’d probably start with compiling my own version of Ember just with the metal package. You can drop into the run-loop and then try to figure out how the hell to render a different view based on any property changes for that particular loop.

I totally know what you mean about IE 8. It’s been my crusade to destroy that browser within my own company and my success is at hand. But, enterprise, you know?

[lightblade]

If the view layer you’re looking to integrate is as simple as just inserting DOM elements into the view’s element, then it’s just simply overriding render in Ember.View.

App.MyView = Ember.View.extend({
...
  render: function(buffer) {
    buffer.element().appendChild(...);
  }
...
});

[yonjah]

@lightblade This is exactly the thing I’m trying to avoid. I can also add events listener to the document with

$(document).on(...);

But then you need to manage your events remember removing them when the view is destroyed and so on. This seems very counter productive when you already have all this logic built into ember any way.

Same with the method you mention lets say you want to manually create your element data with Handlebars template how would you do it ? I mean you already have Handlebars and working with it from ember right ? so all dependencies are there and that seems to be like the best way to go. We’ll if you pass your template as a string to the object and your not using any custom helpers you might be fine (assuming you know Ember.Handlebars and window.Handlebars are not the same thing), but if you want to prebuild your templates on the server, use some custom helpers (both with Ember.Handlebars and Handlebars) this very simple method becomes annoyingly complex (and were not even talking about the fact that you will loose all of Ember data binding sugar)

Any way I probably need to look more closely at Ember canary source code cause it seems like a lot of stuff has improved I just wish there would be a much more easy way to find general directions and core decisions information

[mixonic]

@yonjah

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 make it clear that Ember absolutely supports IE8. We have poured lots of effort in to ensuring that Ember 1.10 and HTMLBars work great with IE8. The core team takes our commitment to semantic version very seriously. We regularly test against IE8 during the beta branching and release.

If you are having an issue with IE8, please report it! And I also encourage you to participate the beta cycles if this is important to your business.

[yonjah]

@mixonic from what I could see pre compiling HTMLbars template gets me a code with a bunch of reserved words that are not wrapped properly like ‘class’ and probably default because ie is crap every place a reserved word appears it has to be wrapped -

//not compatible with ie8
a = { 
    class: 'loading'
};
a.class = 'ready';

//compatible with ie8
a = { 
    'class': 'loading'
};
a['class'] = 'ready';

I thought this is such a common use case that it wouldn’t be missed. I’ll try to open a bug report but I’m not sure if this is an issue with ember core or ember-cli-htmlbars

[mixonic]

@yonjah Please open an issue. It sounds like maybe you aren’t processing your built files with an es3recast though. Ember-CLI takes care of wrapping reserved words in quotes for you.

Ember definitely supports IE8, but you must know that this is not a very popular target for apps. We cannot possibly know the specific issues you have if you do not open issues for them. Open source is not a one-way conversation!

[yonjah]

@mixonic I know it might sounds wierd but I usually don’t open an issue with a package I use untill I know what causes the issue and how to fix it ( unless I think it something really huge I won’t be able to handle and then I’ll open an issue once I understand it’s too big for me to understand by myself). It’s just that I prefer to understand what the package does than for it to work without me knowing whats going on.

So you are saying the new HTMLBars compiler needs and es3 compile step ? That wasn’t the issue with Hanlebars templates. what will happen to templates that are embedded in the code and are being compiled at run time ? ( from my understanding ember-cli-htmlbars uses ember-template-compiler.js which is the run time compiler)

[mixonic]

@yonjah You stated:

from what I could see pre compiling HTMLbars template gets me a code with a bunch of reserved words that are not wrapped properly like ‘class’ and probably default because ie is crap every place a reserved word appears it has to be wrapped

I don’t know where in the generated template we would be using class as a property name, but something like that might be possible. I can tell you HTMLBars has a full test suite that passes in IE8 as does Ember itself. The HTMLBars project has a “compile and run” example that might be helpful. With it you can easily see and run templates.

Even a backtrace or copy of the compiled template might be helpful.

[yonjah]

@mixonic I had some more time to look at it (debugging on IE8 is pure pain…) and you are right our app wasn’t working on IE8 due to other reasons unrelated to HTMLBars.

I opened two new issues - https://github.com/emberjs/ember.js/issues/10519 https://github.com/emberjs/ember.js/issues/10520

I’m happy to say that we decided to drop IE8 support for now we’ll revisit the need for IE8 once the product is out and if any of our clients will require it (which I hope will never happen)