51–60 of 136 posts
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.
Indeed. I continue to be impressed at how painless keeping current with ember in our application has been.
Never used ember but that deserves a pretty complete write up about what was done and how. Nice work.
I imagine we'll get something soon. Ember is having it's developer conference this week, and they were planning on announcing this and I believe something related to a server-side trampoline of sorts.
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.
Here is a pretty neat demo with tons of live updates from a firebase cluster: https://dbmonster.firebaseapp.com/
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.)
Earlier quoted context omitted.
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.
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.
Never used ember but that deserves a pretty complete write up about what was done and how. Nice work.
Here is a pretty neat demo with tons of live updates from a firebase cluster: https://dbmonster.firebaseapp.com/
This demo is taking up an entire core of an i5 2500k. To update a table. It barely updates once every two seconds on a three years old phone. 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 seco…
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.
Earlier quoted context omitted.
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.
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.
Performance _does_ enable certain kinds of applications, and it does absolutely matter, even on the desktop.
Earlier quoted context omitted.
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.
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.
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.