Ember's Glimmer Engine
github.com
github.com
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
Edit: grammar.
Performance _does_ enable certain kinds of applications, and it does absolutely matter, even on the desktop.
your concern would be whether to use a framework at all
do you need something to be "at least X(ms) fast" or "faster than what company Y is doing" or "as fast as possible, no exceptions"
For a more balanced approach to patents, see the GPL, Mozilla Public License, or Apache 2.0 License.
He doesn't agree with your interpretation. The license is very clear in that everything a company would typically do to /defend/ against a patent suit brought by Facebook will terminate its patent rights on React.
Let me quote the second paragraph (added line formating for readability), the (b) part is the broadest I think:
The license granted hereunder will terminate, automatically and without notice,
for anyone that makes any claim (including by filing any lawsuit, assertion or
other action) alleging
(a) direct, indirect, or contributory infringement or
inducement to infringe any patent: (i) by Facebook or any of its subsidiaries or
affiliates, whether or not such claim is related to the Software, (ii) by any
party if such claim arises in whole or in part from any software, product or
service of Facebook or any of its subsidiaries or affiliates, whether or not
such claim is related to the Software, or (iii) by any party relating to the
Software;
or (b) that any right in any patent claim of Facebook is invalid or
unenforceable.
It says making "any claim" against a Facebook patent will terminate your right to use the software. Facebook gets to protect its own software patents: "that any right in any patent claim of Facebook is invalid or unenforceable."
The other lines are okay, it seems.
I am not an IP law expert or lawyer though, but the writing seems pretty simple.
Here's to a future where our apps get faster without us having to change a thing.
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.
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!
Often I discover that I can do exactly what I wanted in just a few lines of code and writing it in pure javascript or jquery would have been many, many more lines of code and much less maintainable.
Developers smarter than I have struggled with these problems and developed optimal solutions that might not be easy to fully grok at first, but are always worth the effort to understand.
For more context, here are a few quick slides from the EmberConf keynote:
http://f.cl.ly/items/0t031v2Z3y001V1N0F3N/Virtual%20DOM.pdf
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!
A situation which still remains in production Ember today: http://youtu.be/z5e7kWSHWTg?t=2m42s
It's too little too late for me. I wouldn't want to touch anything Ember or anything from the authors.
I hope the stability and reliability of Ember's process, and its continuing improvement, will tempt you back.
> the stability and reliability of Ember's process
I'm aware you're one of the people who finally got it done, kudos. But the chances of going back to Ember are nonexistent. This was my experience with Ember:
http://discuss.emberjs.com/t/when-will-htmlbars-be-ready/315...
* 08/2013: Unusable performance when displaying listviews with over 20 items, without infiscroll (unofficial and poorly supported, or roll-your own). Promises that it will be resolved in next months.
* 08/2014: Still getting the runaround about when those "improvements" will arrive.
Only one of a dozen things which made working with Ember horrific. Apologies for being bitter, but it is what it is.
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 tooltip DOM into each table cell isn't how you'd actually write this), and the server names selectable ... but those particular "features" don't really seem relevant to this particular UI.
> 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...
These demos are like listening to MongoDB talk about how great MongoDB performs. Always better to look for yourself or check a trusted third party.
Here's an angular dbmon that is at least using track by. I didn't write it. http://run.plnkr.co/plunks/Uu7w8p7jiPEJp5lLHWbB/
Be careful, it is very slow and may crash your browser.
My terminal is faster than that and doesn't even use 1%. A native application is faster than that and barely uses 1%. I know this is a nice advance for client side rendering, but can we stop pretending it's in a good state ?
(Although if you're updating this many times per second your application, you might be having a problem already.)
It's reasonably quick on an iPhone 6 (though obviously slower than on a desktop). In actual use you'd obviously design things a bit differently. Again, this is a performance test, not a real application.
Despite the inherent performance disadvantages, people are stepping up and working on pushing Web applications to run faster. The efforts of the Ember team and others should be commended rather than ridiculed.
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 nodes for dynamic content. Simple.
> virtual DOM nodes for static areas of your markup
refers to React's virtual DOM implementation, not Ember's.
> I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem?
Ember is a complex framework. Suggesting a "solution" to challenges with an acknowledged lack of context, and adding "Simple", shows fairly poor attitude.
> I just stash large, static parts of the tree in variables and only rebuild vdom nodes for dynamic content
This sounds pretty much like what is already described in the PR.
Again, still confused, and still don't know what is being suggested.
yesterday, I got downvoted repeatedly for mentioning that I hadn't seen an IIS header in years. ¯\_(ツ)_/¯
There is no constant value to store here. Perhaps you are referring to the templates, which are static and are already stored in memory?
> Because our template language is declarative, we can do this at compile time.
Is it an artifact of the DOM API? In WPF, they have to maintain two sizes because of this: a set size (if specified) and a layout computed size that is filled when layout computations are done in batch. This adds some complexity (e.g. ActualWidth is not always equal of width, and so on), but the perf is pretty good.
http://stackoverflow.com/questions/21109361/why-is-reacts-co...
Some points:
> Dirty checking is slower than observables because you must poll the data at a regular interval and check all of the values in the data structure recursively.
You don't have to poll your dirty bits! When you dirty something, you put it into a dirty list/set. You only re-render if your dirty list/set is not empty, clean deeper elements before shallow elements, and its quite optimal.
> A virtual DOM is nice because it lets us write our code as if we were re-rendering the entire scene.
Totally: they are basically turning a retained model into a not-so-slow immediate model, which is a nice programming abstraction, but it is not a performance win over an efficient retained model.
> DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM.
So layout calculations in normal DOM aren't incremental, but are made incremental in virtual DOM? Assuming this isn't related to batching, it sounds like the concrete DOM is just a bad implementation? Or does the virtual DOM avoid doing layout calculations at all and somehow magically fixes the layout when things change?
To prevent this the programming model should be changed. There are two ways that I can imagine.
- Introduce "DOM batching mode". In this mode remove the immediate mode guarantees. If you specify an element width you are no longer guaranteed to read it back until the layout occurs. So store your intermediate element width somewhere if you want to use it. Of course you don't need to specify batching mode for all the DOM tree. Just the majority of it that doesn't require custom layout.
- IIUC the majority of times that you need to perform multiple reads and writes of the DOM properties is due to special layout requirements. In some cases CSS layout may not be enough. There should be an API that allows to specify custom layout strategy for a parent DOM element. JavaScript should be fast enough. The additional benefit is that we would no longer need to wait for e.g. Flexbox adoption. Just roll your own.
It is obvious that we are trying to turn HTML into a GUI framework. So let's do it properly.
The problems we are facing with DOM have already been solved by multiple game engines and GUI frameworks.
Some sort of DOM-like buffer[1] that you could render into and then "flush"/insert, maybe?
[1] https://developer.mozilla.org/en-US/docs/Web/API/DocumentFra...
What exactly does this mean "the programming model is equivalent to render every time, but we take advantage of the declarative nature of Ember's APIs to reduce work."??
<div class="container"> <-- this won't change
<h1>Hello World</h1> <-- this won't change
<div>{{name}} <-- this might change </div>
</div>But I think now this may force us to use more handlebars. Manipulations in didInsertElement may get affected as well. Like updating classes which I sometimes prefer doing in hooks like click, didInsertElement.
That said, I think that binding classes (like `class={{foo}}`) and updating it through HTMLBars is a safer way to do it, comparing to direct DOM manipulation.
But where it get interesting is when it comes to actual DOM interaction. To create DOM, we use document fragments + cloneNodes, but for granular updates we utilize property/attribute/textContent updates. When used correctly, this combination turns out to be very fast.
As a bonus, we are typically able to utilize the browsers built-in XSS and sanitization (or just lack of parsing) rather then having to implement this slowly in JavaScript ourselves.
Ultimately, I am extremely happy with how the various front-end frameworks keep pushing the envelope. Getting faster, easier to use, and more secure. Ultimately regardless of the framework the ecosystem moving forward benefits the end users the most.
DBMonster is more like a standard performance benchmarker.
Nice work.
A handlebars template might look like this:
<div class="foo">
{{#if enabled}}
<p>I'm enabled!</p>
{{#end}}
</div>
This uses the knowledge of Handlebars to make the diffing algorithm smarter: you don't need to check if the <div> or its class has changed, it never will. You don't need to check if the <p>'s contents have changed, it never will. This means less to diff, which means more speed.
This is the advantage of using a declarative syntax for templating: this analysis can be done entirely at compile time.
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.
[1](https://github.com/tildeio/htmlbars/blob/master/ARCHITECTURE...)