I’m an enthusiast Ember user. I already test everything in no time when something new is released, i’m very happy with Ember.
That said I’m very unhappy when I see something like below.
In this comparison of the perfomance of a few popular javascript frameworks Interactive Results Ember is the latest one.
My question is: maybe these guys have no idea how to use very well Ember and Glimmer?
It’s not a war, I know, but maybe someone who knows how to do must review the test code on that Github repository: GitHub - krausest/js-framework-benchmark: A comparison of the perfomance of a few popular javascript frameworks
It’s possible they aren’t using Ember/Glimmer optimally but it’s also possible they’re not using any of the other frameworks optimally either. There are many different ways to measure performance in a web framework and IMHO very few of them result in anything valuable in the long run. Performance is an incredibly complex metric that can vary wildly across frameworks, browsers, applications, data-intensity, etc. One framework could have great render or rerender time, another framework could be really fast at processing data, yet another framework could work really well in IE 9 over xfinity with exactly 3 components and no data bindings but poorly elsewhere. The point is, performance charts like this only tell you so much. Unless a given framework is an order of magnitude slower across a variety of tests you may never see any real-world performance impact. Maybe Ember and Glimmer are really fast, maybe they’re in the bottom 25% of the performance scale. My question is, at the end of the day does that really matter?
In my opinion Ember’s biggest strengths aren’t performance related at all. That’s not to say that Ember isn’t performant, I think some of the innovations around rendering have been noteworthy at minimum, and I think Ember has always been competitive in terms of performance in general. But I like Ember because of the strength of the community and ecosystem, a diverse core team that puts no single company’s interest first, and the ability to create very powerful webapps very quickly. Those are things that aren’t as easy to quantify, and therefore aren’t as easy to point to a colored chart and say “OMG x framework is the best!” but for most applications I’d say those benefits outweigh raw performance, even if you can quantify that.
So I guess in conclusion I’d ask you: why does this chart make you unhappy? If you’re really trying to eek out the absolute minimum latencies and you absolutely must use the fastest framework available at any given time, maybe Ember isn’t for you. But you’ll probably be switching frameworks a lot. If you like Ember for other reasons, perhaps you’ll be happy to see that ThoughtWorks recently placed Ember in their “Adopt” category in their Tech Radar, which is pretty high praise. They are a consulting company with a ton of influence and experience and a huge variety of clients and experience building software. Specifically they say:
If you are faced with building a single-page application (SPA) and trying to choose a framework to build with, Ember.js has emerged as a leading choice. Our teams praise Ember for its highly productive developer experience, with far fewer surprises than other frameworks such as AngularJS. The Ember CLI build tooling is a haven in the storm of JavaScript build tools, and the Ember core team and community are highly active and responsive.
So I’d say things like that will be of a lot more use when evaluating frameworks than the performance charts. YMMV.
4 Likes
I think it’s nice to just use an app - and let the human in you decide. I’ve never used an Ember app - or really any app (besides atom) and thought / huh - this one is slow. I have however used many apps and websites and thought - ‘wow this is crappy’ for UI and general design reasons.
1 Like