Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ember.js Octane Edition

blog.emberjs.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Ember.js Octane Edition

#61

Post by pier25 »

HatchedLake721 wrote: post #55
pier25 wrote: post #43

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.

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...

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

Re: Ember.js Octane Edition

#62

Post by pier25 »

nullvoxpopuli wrote: post #48
pier25 wrote: post #43

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.

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.

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

Re: Ember.js Octane Edition

#63

Post by mixonic »

pier25 wrote: post #61
HatchedLake721 wrote: post #55

Earlier quoted context omitted.

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...

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

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!

Re: Ember.js Octane Edition

#64

Post by pier25 »

nullvoxpopuli wrote: post #50
pier25 wrote: post #41

Earlier quoted context omitted.

My current Mithril app weights 30kb gzipped. That includes a router and an http client (both included in Mithril).

what does it do?

Not much, it’s a library of assets for a marketing department, but it’s certainly not a hello world.

Re: Ember.js Octane Edition

#65

Post by pier25 »

mixonic wrote: post #63
pier25 wrote: post #61

Earlier quoted context omitted.

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

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 t…

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

Re: Ember.js Octane Edition

#66

Post by itwy »

nullvoxpopuli wrote: post #56
itwy wrote: post #52

Earlier quoted context omitted.

Definitely a gross exaggeration.

if you have 20 people on your team, and they each have 5 PRs merged which are deployed with some continuous deployment strategy, you're already at 100 deploys in one day. :-\

Their platform is too small to have 100 merge commit per day.

Re: Ember.js Octane Edition

#67

Post by nullvoxpopuli »

pier25 wrote: post #64
nullvoxpopuli wrote: post #50

Earlier quoted context omitted.

what does it do?

Not much, it’s a library of assets for a marketing department, but it’s certainly not a hello world.

yeah, ember (today) doesn't fit the small project space (it's more geared towards medium to large+ projects).

That IS a goal for the next edition (octane being the first edition). Def need better small / toy project support.

Re: Ember.js Octane Edition

#68

Post by nullvoxpopuli »

pier25 wrote: post #62
nullvoxpopuli wrote: post #48

Earlier quoted context omitted.

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.

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

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

Re: Ember.js Octane Edition

#69

Post by pzuraq »

pier25 wrote: post #62
nullvoxpopuli wrote: post #48

Earlier quoted context omitted.

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.

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

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.

Re: Ember.js Octane Edition

#70

Post by vdrizzle »

At coschedule.com we’ve been using EmberJS since 2013. We look at EmberJS as one of the strengths of the development team. It has been rock solid, stable, and progressive. We began our transition to Octane about 3 months ago, and while still very much a work in progress but it has been a delight. We just finished refactoring the oldest section of our app, and on average we’ve seen a 50% render performance increase, this in part to the leaner glimmer components.

The future is bright EmberJS is fun and easy to develop on. The learning curve has been drastically reduced and new devs should not have a hard time getting up and going. The guides have been completely redesigned and the super rentals tutorials is an excellent tool to get started.

Post reply on HN