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