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

41–50 of 136 posts

Re: Ember's Glimmer Engine

#41

Post by awj »

theflop wrote: post #31

So what happens with all those JQuery plugins that manipulate the DOM directly in didInsertElement? I'm guessing Glimmer doesn't have a clue how to optimize that use case. So a lot of components need to be rewritten from scratch in Ember-style?

Well, if you need the performance increase, the yes. Otherwise your options are to (maybe) tweak your current implementation so it continues to work or rewrite the functionality to be compatible with the view layer. This is the same trade-off you make with React since it's basically the same technology.

Re: Ember's Glimmer Engine

#42

Post by quaunaut »

virmundi wrote: post #25

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?

My try with it was anecdotal, but the demo[1](which is a pretty brutal demo) ran at a fair speed on my phone- about 3 updates per second.

Currently, on Android devices most complex JS apps have performance issues(some problems were found in how Android processes JS), but this should go a long way in mitigating that problem while it's worked on by Google.

Re: Ember's Glimmer Engine

#44

Post by emodendroket »

jjbiotech wrote: post #26
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…

Well, you know, the native Ruby Mongo driver and Ruby itself are both abstractions, too.

Re: Ember's Glimmer Engine

#45

Post by aero142 »

untog wrote: post #33
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…

Every framework has a learning curve. In this instance it seems to have a significant performance benefit. That's your trade-off.

I didn't take his comment to be about a learning curve. I think the complaint is that the abstraction on top is not as expressive as the thing it abstracts. This means that when you break the abstraction you have the complexity of the thing you abstracted away on top of the abstraction layer itself, which means you might have been better off without the abstraction in the first place.

Re: Ember's Glimmer Engine

#46

Post by rxcfc »

theflop wrote: post #31

So what happens with all those JQuery plugins that manipulate the DOM directly in didInsertElement? I'm guessing Glimmer doesn't have a clue how to optimize that use case. So a lot of components need to be rewritten from scratch in Ember-style?

You shouldn't be both manually manipulating the DOM _and_ using Handlebars mustaches for the same element. Since there wouldn't be mustaches, Glimmer would ignore these cases. In general, you should only be using jQuery plugins for special cases not covered by Ember anyway.

Re: Ember's Glimmer Engine

#47

Post by ralmidani »

vjeux wrote: post #24

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

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.

Re: Ember's Glimmer Engine

#48

Post by rxcfc »

ChrisGaudreau wrote: post #29
mmgutz wrote: post #18

Will this be built into handlebars or just ember?

Just Ember. I'm pretty sure Ember doesn't even have a dependency on Handlebars anymore. (possibly only off stable)

Ember still uses the Handlebars syntax, but we don't use the standard Handlebars runtime anymore.

Re: Ember's Glimmer Engine

#50

Post by colinramsay »

davexunit wrote: post #37

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

You appear to have been downvoted; while I don't know whether your potential solution is right or wrong your downvoters should have been polite enough to explain their reasoning.
Post reply on HN