TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ember's Glimmer Engine

378 点作者 hswolff大约 10 年前

30 条评论

vjeux大约 10 年前
React 0.14 is going to have similar optimizations. Check those three posts if you are interested in the details :)<p>Reuse Constant Value Types like ReactElement: <a href="https://github.com/facebook/react/issues/3226" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;issues&#x2F;3226</a><p>Tagging ReactElements: <a href="https://github.com/facebook/react/issues/3227" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;issues&#x2F;3227</a><p>Inline ReactElements: <a href="https://github.com/facebook/react/issues/3228" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react&#x2F;issues&#x2F;3228</a>
评论 #9141244 未加载
评论 #9141935 未加载
praxxis大约 10 年前
The performance of Glimmer is amazing, but lets not forget this gem: &quot;backwards compatible with Ember 1.x apps.&quot;<p>Here&#x27;s to a future where our apps get faster without us having to change a thing.
评论 #9141127 未加载
评论 #9142656 未加载
dracolytch大约 10 年前
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.<p>That is to say: The abstraction isn&#x27;t as expressive as the root language, and when I need something more expressive, then it&#x27;s more troublesome than writing than the root language.<p>The rendering engine here does seem to perform admirably, and I have to congratulate them on that. Maybe I&#x27;ve just been burned a few too many times from this kind of language.
评论 #9141026 未加载
评论 #9140955 未加载
评论 #9142726 未加载
评论 #9141479 未加载
评论 #9140840 未加载
评论 #9142757 未加载
评论 #9141034 未加载
mixonic大约 10 年前
Glimmer is a revolutionary improvement in Ember&#x27;s rendering performance. I&#x27;m incredibly excited by the progress and promise being realized in Tom and Yehuda&#x27;s PR.<p>For more context, here are a few quick slides from the EmberConf keynote:<p><a href="http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf" rel="nofollow">http:&#x2F;&#x2F;f.cl.ly&#x2F;items&#x2F;0t031v2Z3y001V1N0F3N&#x2F;Virtual%20DOM.pdf</a><p>They, and the PR, tell the whole story about what is happening in the dbmonster demo. We expect this work to land in Ember 1.13 stable!
评论 #9142125 未加载
jashkenas大约 10 年前
For the curious, here&#x27;s a port of the Dbmonster demo to a simple Underscore template — the kind of base-level rendering strategy you might <i>start with</i> in a Backbone app. (And vintage 2009 technology.)<p><a href="http://jashkenas.github.io/dbmonster/" rel="nofollow">http:&#x2F;&#x2F;jashkenas.github.io&#x2F;dbmonster&#x2F;</a><p><i>Edit:</i><p>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 tooltip DOM into each table cell isn&#x27;t how you&#x27;d actually write this), and the server names selectable ... but those particular &quot;features&quot; don&#x27;t really seem relevant to this particular UI.
评论 #9141449 未加载
评论 #9141457 未加载
评论 #9142848 未加载
评论 #9149487 未加载
makmanalp大约 10 年前
Here is a pretty neat demo with tons of live updates from a firebase cluster: <a href="https://dbmonster.firebaseapp.com/" rel="nofollow">https:&#x2F;&#x2F;dbmonster.firebaseapp.com&#x2F;</a>
评论 #9141279 未加载
评论 #9140268 未加载
评论 #9140077 未加载
评论 #9140848 未加载
评论 #9139972 未加载
hswolff大约 10 年前
Gotta say, the incremental improvement pattern Ember is adhering to is absolutely the bee&#x27;s knees. Kudos Ember team, so awesome to see!
davexunit大约 10 年前
&gt;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.<p>I&#x27;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 nodes for dynamic content. Simple.
评论 #9143268 未加载
评论 #9141248 未加载
评论 #9142089 未加载
steveklabnik大约 10 年前
Quote from wycats during the talk:<p><pre><code> &gt; Because our template language is declarative, we can do this at compile time. </code></pre> &quot;This&quot; being determining which portions of the DOM will never change, and so only needing to analyze the portions that might.
评论 #9142199 未加载
bsimpson大约 10 年前
It&#x27;s pretty cool that a year ago, React was far and away the best choice for new JS development for reasons that seemed to be architectural (no dependence on the DOM&#x2F;server-renderable, isomorphic, intentionally minimal DOM modification), and in the intervening time, the Ember guys have taken the good ideas from React and brought them to Ember. Congratulations! It&#x27;s great to see the best ideas lifting all boats.
some1else大约 10 年前
Looks like Glimmer&#x27;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&#x2F;render function would skip repainting the unchanged parts and use appropriate (previously decomposed) fragments of the template function to render changes.
untog大约 10 年前
Interesting it&#x27;s using Handlebars - I wonder how it compares to the diffing done in Ractive, which also uses a similar syntax (<a href="http://www.ractivejs.org/" rel="nofollow">http:&#x2F;&#x2F;www.ractivejs.org&#x2F;</a>).
评论 #9141344 未加载
ohfunkyeah大约 10 年前
I see a lot of talk and comparison to React but nothing about Meteor&#x27;s Blaze engine and its HTMLJS virtual DOM diffing approach which seems even more comparable
Rapzid大约 10 年前
Will these virtual DOM&#x2F;diff&#x27;ing optimizations be built into the browsers at some point? Seems like they should&#x2F;would.
评论 #9143358 未加载
评论 #9142250 未加载
itsbits大约 10 年前
I am not as smart as lot of guys here..but What exactly is Glimmer&#x27;s additional optimisations other than Virtual DOM?...<p>What exactly does this mean &quot;the programming model is equivalent to render every time, but we take advantage of the declarative nature of Ember&#x27;s APIs to reduce work.&quot;??
评论 #9143866 未加载
drderidder大约 10 年前
I feel like the techniques React uses to deal with state and performance are likely to be addressed in a simpler way by solutions that work better with the existing stack. I&#x27;m not an Ember user but I like the way they&#x27;ve approached this, without re-inventing the DOM wheel.
theflop大约 10 年前
So what happens with all those JQuery plugins that manipulate the DOM directly in didInsertElement? I&#x27;m guessing Glimmer doesn&#x27;t have a clue how to optimize that use case. So a lot of components need to be rewritten from scratch in Ember-style?
评论 #9141164 未加载
评论 #9141232 未加载
评论 #9140998 未加载
pothibo大约 10 年前
Is that DBMonster app becoming the new todo app for all JS framework to implement?
评论 #9142318 未加载
anarchy8大约 10 年前
Can we have a side-by-side comparison of the same demo using normal Ember?
评论 #9140253 未加载
评论 #9140290 未加载
评论 #9140275 未加载
lightblade大约 10 年前
&gt; On my machine, the dbmon app in Ember+Glimmer gets 10 renders per second, React gets 14. Not bad, way better than 0.1 per second!<p><a href="https://twitter.com/ryanflorence/status/572991666090467330" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;ryanflorence&#x2F;status&#x2F;572991666090467330</a>
cfontes大约 10 年前
Never used ember but that deserves a pretty complete write up about what was done and how.<p>Nice work.
评论 #9140723 未加载
评论 #9141134 未加载
评论 #9141285 未加载
virmundi大约 10 年前
So how does this compare with Ionic&#x2F;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?
评论 #9141423 未加载
评论 #9141170 未加载
itsbits大约 10 年前
What kind of DOM model Ember is using like React.DOM?...I don&#x27;t think handlebars create DOM Objects?...great to see How Ember accepted the change and implemented that...
评论 #9145195 未加载
itsbits大约 10 年前
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?
ohfunkyeah大约 10 年前
I see a lot of talk and comparison to React but nothing about Meteor&#x27;s Blaze engine and HTMLJS which seems even more comparable
randomguy7788大约 10 年前
ng2 will have similar optimizations i believe. interesting times in the 2.0 framework wars! lol i kidddd
评论 #9142202 未加载
cellis大约 10 年前
But will it work with Emblem? Also how does this affect FastBoot?
评论 #9142187 未加载
EugeneOZ大约 10 年前
So mutable structures can be powerful too, when handled right :)
mmgutz大约 10 年前
Will this be built into handlebars or just ember?
评论 #9140872 未加载
iamleppert大约 10 年前
Yawn. Dust has had all this (and much more) for a long time. <a href="http://akdubya.github.io/dustjs/" rel="nofollow">http:&#x2F;&#x2F;akdubya.github.io&#x2F;dustjs&#x2F;</a>
评论 #9141247 未加载
评论 #9141121 未加载