Interesting..it has been 10 days Yehuda made that comment and now we come to know about it...or there was discussion before on same which i might have missed?
Ember's Glimmer Engine
111–120 of 136 posts
Re: Ember's Glimmer Engine
#112I always have a problem with these kinds of frameworks. Every time I try to use one, and want to do something more in-depth for fancy than a lot of the functionality out-of-the-box, then I end up having to hunt down the way to extend X feature, and it often takes me more effort to do that then just writing in the root language would be. That is to say: The abstraction isn't as expressive as the root language, and whe…
I have been following Ember since its 0.9 beta stage and believe me until it released around 1.3 or 1.5 there has been lot of change and was a huge learning curve. But now that I know how exactly ember works, it is easy and fast to write Ember Apps since lot of boilerplate can be easily avoided.
Re: Ember's Glimmer Engine
#113I see a lot of talk and comparison to React but nothing about Meteor's Blaze engine and HTMLJS which seems even more comparable
Re: Ember's Glimmer Engine
#114I see a lot of talk and comparison to React but nothing about Meteor's Blaze engine and its HTMLJS virtual DOM diffing approach which seems even more comparable
Re: Ember's Glimmer Engine
#115I always have a problem with these kinds of frameworks. Every time I try to use one, and want to do something more in-depth for fancy than a lot of the functionality out-of-the-box, then I end up having to hunt down the way to extend X feature, and it often takes me more effort to do that then just writing in the root language would be. That is to say: The abstraction isn't as expressive as the root language, and whe…
I've been working on a large app using Ember, and this has been my experience over the last several months. I'm still excited about embers future, and hopeful our choice to use it will one day pay off, but for this first project, we would absolutely have been further along, and happier, had we chosen a less all-encompassing framework and built the required abstractions ourselves (for the very reasons you have pointed out).
Re: Ember's Glimmer Engine
#116For the curious, here's a port of the Dbmonster demo to a simple Underscore template — the kind of base-level rendering strategy you might start with in a Backbone app. (And vintage 2009 technology.) http://jashkenas.github.io/dbmonster/ Edit: To head off grumbling at the pass — It would also be easy to do a slightly less-simple version that keeps the flickering impossible-to-read popups open (putting redundant toolt…
Tangentially: (yet somehow related), you could write [1]:
> The process of converting a string template into a fully compiled HTMLbars template function that emits DOM nodes is somewhat involved. The purpose of this document is to shed some light on the process and describe where in the HTMLbars codebase these steps take place.
or you could just write:
> OVERVIEW
If the parallel is not obvious, it feels like many JavaScript frameworks are written in this overly verbose style.
1: https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...
Re: Ember's Glimmer Engine
#117React 0.14 is going to have similar optimizations. Check those three posts if you are interested in the details :) Reuse Constant Value Types like ReactElement: https://github.com/facebook/react/issues/3226 Tagging ReactElements: https://github.com/facebook/react/issues/3227 Inline ReactElements: https://github.com/facebook/react/issues/3228
React's unfair and one-sided patent grant aside (personally, I will never build a real app with React unless that situation changes), it is not a complete MVC framework, and to my knowledge there is nothing that fills in the gaps to make something close to Ember feature-wise. So while React may end up faster, Ember will hopefully be quick enough that its programming model wins out. Edit: grammar.
[deleted]
Re: Ember's Glimmer Engine
#118Earlier quoted context omitted.
Indeed. I continue to be impressed at how painless keeping current with ember in our application has been.
That's awesome to hear! It takes an unbelievable amount of energy and sometimes frustrates us with how slow and deliberate we need to be with features.
Thank you for taking the time. Ember's API stability made it the only viable choice for our web apps at work.
Re: Ember's Glimmer Engine
#119>building virtual DOM nodes for static areas of your markup that will never change for every change requires many more allocations and increases GC pressure. I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem? For example, in MithrilJS, you write templates in plain JavaScript, so I just stash large, static parts of the tree in variables and only rebuild vdom nod…
I believe they're saying that a virtual DOM is created and updates that would cause a re-render are first applied to the virtual DOM (thus avoiding the over head of a render). The virtual and actual DOM are then compared to see which parts have changed and need to be re-rendered, which results in a net saving of CPU time.
There is no constant value to store here. Perhaps you are referring to the templates, which are static and are already stored in memory?
Re: Ember's Glimmer Engine
#120So mutable structures can be powerful too, when handled right :)