[pier25]

The ergonomics look nice but Ember still needs to make a lot of progress in bundle size and performance.

Glimmer is certainly much faster than previous Ember versions but it's barely competitive by today's standards.

https://krausest.github.io/js-framework-benchmark/current.ht...

Also, in that link check how Glimmer fares in start-up metrics (very bad). And it's not even the complete Ember framework.

[HatchedLake721]

Why spread fud? Glimmer beats react on re-rendering thanks to bytecode and virtual machine architecture https://engineering.linkedin.com/blog/2017/06/glimmer--blazi...

[pier25]

Those are tests from 2017. The link I posted uses more current versions.

[mixonic]

The results there are using Ember 3.11, not Octane, so I'd also say those results are out of date :-p I will try to get the benchmarked Ember codebase updated over the winter holidays. I've always love looking at these microbenchmarks.

At large app scale Ember apps perform very well, and I would happily pit the performance of a full-complexity Ember app against any other framework. At the end of the day the goal of the Ember project is not to be the fastest, especially at microbenchmarks, but to have competitive performance with an API that any level of developer can be successful with. To have a fast Ember app there aren't any special tricks or APIs to learn, it is simply fast out of the box with performance that scales.

Thanks for the reminder about this benchmarking project!

[pier25]

I was referring to the glimmer results, not the ember ones.

[nullvoxpopuli]

those tests there are not using current stuff. The glimmer VM has had loads of perf improvements since those versions.

something else to keep in mind is that both the glimmer and ember benchmarks in that test are full framework-level apps. Not just the view layer. This is largely what impacts the startup time and memory usage.

[pier25]

If that's the case it would be great if the Ember team updated and optimized Ember and Glimmer on those benchmarks. A lot of people in the JS community use those to compare libraries and frameworks.

https://github.com/krausest/js-framework-benchmark

[pzuraq]

Definitely agreed. We’ve been focused on optimizing for end-to-end, realistic benchmarks. One of the Ember core team members, Kris Selden, has been working on a testing framework specifically for this actually: https://github.com/TracerBench/tracerbench

Now that we have a full set of new features, and are comfortable with the performance as a whole, I think we can also start to tune for some microbenchmarks. Our primary concern was to not over optimize for microbenchmarks at the expense of real world performance in real apps, which can happen if you’re not careful.

[nullvoxpopuli]

I agree. I believe there are efforts coming to improve perception around these benchmarks.