Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ember's Glimmer Engine

github.com

Post reply on HN
Print view View original

21–30 of 136 posts

Re: Ember's Glimmer Engine

#21

Post by dracolytch »

I 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 when I need something more expressive, then it's more troublesome than writing than the root language.

The rendering engine here does seem to perform admirably, and I have to congratulate them on that. Maybe I've just been burned a few too many times from this kind of language.

Re: Ember's Glimmer Engine

#22

Post by praxxis »

The performance of Glimmer is amazing, but lets not forget this gem: "backwards compatible with Ember 1.x apps."

Here's to a future where our apps get faster without us having to change a thing.

Re: Ember's Glimmer Engine

#23

Post by searls »

steveklabnik wrote: post #19
cfontes wrote: post #15

Never used ember but that deserves a pretty complete write up about what was done and how. Nice work.

Here's a TL;DR: A handlebars template might look like this: {{#if enabled}} I'm enabled! {{#end}} The usual DOM-diffing algorithm compares every single thing: "has this div changed? Has the class changed? Has the changed?" This uses the knowledge of Handlebars to make the diffing algorithm smarter: you don't need to check if the or its class has changed, it never will. You don't need to check if the 's contents have…

Thanks for the concise description. Love to see Team Ember take advantage of the information users are already feeding the existing public API.

Re: Ember's Glimmer Engine

#24

Post by vjeux »

React 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

Re: Ember's Glimmer Engine

#25

Post by virmundi »

So how does this compare with Ionic/Angular on mobile? I recently made an app with Ionic, but the 1.0 migration caused gestures to no longer work. Can Glimmer run well on mobile?

Re: Ember's Glimmer Engine

#26

Post by jjbiotech »

dracolytch wrote: post #21

I 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…

Yeah, I think what you just stated is an issue for any type of abstraction. You really just have to examine an interface in depth before you start writing code with it to see if it's capable of supporting the functionality you need.

Only a few months ago while developing a REST API in Ruby, I implemented MongoMapper for my ORM/Database access layer. Turns out it didn't support a few things I wanted to do, so I hacked my code into little (ugly) pieces just so I could continue using MongoMapper (Didn't have time for a rewrite). I think if I would have just stuck with using the native Ruby Mongo driver, development would have taken less time and my code wouldn't look like a steaming pile of shit!

Re: Ember's Glimmer Engine

#28

Post by some1else »

Looks like Glimmer's wits regarding the distinction of static and dynamic parts of the template should be applicable to JST, HAML and the rest as well. The dynamic parts are clearly marked with template tags, and local (changed) variables would be easy to scan for within the dynamic parts of the code. This would probably mean that the template engine should decompose the template into smaller bits, and provide metadata by which the view can map DOM fragments to template fragments (DocumentFragment, DOMNode, DOMAttribute, TextNode) and related Model attributes. Attrubte-level change events could then either directly expire the relevant fragments, or the View onChange/render function would skip repainting the unchanged parts and use appropriate (previously decomposed) fragments of the template function to render changes.
Post reply on HN