61–70 of 136 posts
Interesting it's using Handlebars - I wonder how it compares to the diffing done in Ractive, which also uses a similar syntax ( http://www.ractivejs.org/ ).
>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.
> 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.
Earlier quoted context omitted.
It's also worth noting that we're getting to the point where fastest doesn't really matter. Both Ember and React will be fast enough. Performance shouldn't be a deciding factor.
One of the motivations for this change was that a real-world application was too slow. As the original presentation says, choosing a technology and then finding out that it's limiting you is really rough when it happens to you. Performance _does_ enable certain kinds of applications, and it does absolutely matter, even on the desktop.
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?
Earlier quoted context omitted.
One of the motivations for this change was that a real-world application was too slow. As the original presentation says, choosing a technology and then finding out that it's limiting you is really rough when it happens to you. Performance _does_ enable certain kinds of applications, and it does absolutely matter, even on the desktop.
Performance matters, but if Ember can have 50-60% of the speed of a performance-optimized React app without the associated cognitive overhead, I suspect many will see the trade-off as worth it.
Earlier quoted context omitted.
One of the motivations for this change was that a real-world application was too slow. As the original presentation says, choosing a technology and then finding out that it's limiting you is really rough when it happens to you. Performance _does_ enable certain kinds of applications, and it does absolutely matter, even on the desktop.
Performance matters, but if Ember can have 50-60% of the speed of a performance-optimized React app without the associated cognitive overhead, I suspect many will see the trade-off as worth it.
For 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…
For 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…
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…
Earlier quoted context omitted.
It's also worth noting that we're getting to the point where fastest doesn't really matter. Both Ember and React will be fast enough. Performance shouldn't be a deciding factor.
I should have added the caveat that there will always be a handful of cases where you do need absolute top performance. However, I do think that for the vast majority of apps we'll end up at a point where performance isn't the deciding factor. It doesn't mean that we shouldn't keep improving performance, just that being the fastest doesn't matter so much if all the options are very fast.
your concern would be whether to use a framework at all