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

11–20 of 80 posts

Re: Ember.js Octane Edition

#11

Post by thebenedict »

chancancode wrote: post #2

For those of you aren't particularly interested in Ember or frontend development in general, here is a tidbit that may be of interest to you. While revamping the tutorial[1] to showcase the new features and idioms, I worked on this tool[2] to automate the generation of the tutorial. Every page of the tutorial you see is the output from markdown source files (like this one[3]) which contains executable instructions fo…

Love it. Keeping documentation screenshots and code snippets in sync with development has been a headache for me on past projects. This is clever!

Re: Ember.js Octane Edition

#12

Post by jchw »

With a cursory glance, a lot of these changes make Ember look more familiar for React users, w.r.t. not treating root specially (versus Angular for example) and with moving away from mixins for more functional composition. All in all I think this is great and would like to take a look at Ember and see what it has to offer nowadays.

Re: Ember.js Octane Edition

#13

Post by gavinjoyce »

dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

Perhaps you're measuring a development build?

I just tried a new ember 3.15 app production build, the JS payload comes in at 712.29 KB (180.80 KB gzipped)

`ember new myapp && cd myapp && ember build --environment='production' && ls -la dist/assets`

Re: Ember.js Octane Edition

#14

Post by pzuraq »

dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

This is actually going to be my next project, now that we’ve shipped Octane there’s a lot of code that we can slowly start to move away from! The plan is to move toward optional features and then deprecations for many of the classic features, allowing Octane users to opt-in to the benefits progressively, while still supporting Classic users for some time as they transition.

Definitely curious how you got these numbers though. Our current estimate of Ember’s size is ~160kb after min/gzip, and Ember Data (the only other large library installed by default) should be less than that. Jquery should not be included by default anymore, which would be a large chunk. Were you building a production build? `ember build —env=production`? That will cut out a significant chunk of debug code and assertions that are only used for development builds as well.

Re: Ember.js Octane Edition

#15

Post by wycats »

dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

You're not alone! The Ember core team broadly agrees with this goal.

With Octane, we focused on landing broad ergonomic improvements in a compatible release of Ember.

At the same time, we've been working on updating the way that Ember builds JavaScript so that it can make better use of tree shaking and code splitting tools in modern bundlers. That project is called Embroider[1] and it currently builds substantial Ember codebases.

Wrapping up Embroider and shipping it by default is a substantial part of the work we have planned for 2020[2].

Also, now that Octane idioms fully replace the need for Ember's original object model (designed in 2012!), I would expect it to become an optional feature, meant to be used primarily as a transition path. When combined with tree shaking, that should substantially change the default byte size of Ember.

It's too early to say exactly how that will shake out (no pun intended), but it's a big priority for the Ember community next year.

[1]: https://github.com/embroider-build/embroider

[2]: https://github.com/emberjs/rfcs/blob/2018-2019-roadmap/text/...

Re: Ember.js Octane Edition

#16

Post by dstaley »

gavinjoyce wrote: post #13
dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

Perhaps you're measuring a development build? I just tried a new ember 3.15 app production build, the JS payload comes in at 712.29 KB (180.80 KB gzipped) `ember new myapp && cd myapp && ember build --environment='production' && ls -la dist/assets`

Ah yes, I didn't realize "ember build" produced a development build. For comparison, create-react-app always builds in production mode to eliminate this exact scenario!

Re: Ember.js Octane Edition

#17

Post by dstaley »

pzuraq wrote: post #14
dstaley wrote: post #10

One of the things I really wish Ember would focus on is reducing the amount of JavaScript shipped to the browser. I just tried out the included project with ember-cli, and the default JavaScript bundle is 2.7 MB (591 KB gzipped)[1] for an app that doesn't have any functionality. I know that you get a lot with that 591 KB (Ember's router, the Glimmer VM, etc.), but it's still much more than what you can get your React…

This is actually going to be my next project, now that we’ve shipped Octane there’s a lot of code that we can slowly start to move away from! The plan is to move toward optional features and then deprecations for many of the classic features, allowing Octane users to opt-in to the benefits progressively, while still supporting Classic users for some time as they transition. Definitely curious how you got these number…

Sorry, I was apparently producing a development build. I'm used to create-react-app, which eliminates this exact scenario by always building in production mode, so that people can't accidentally ship a development build to production.

Re: Ember.js Octane Edition

#18

Post by gavinjoyce »

dstaley wrote: post #17
pzuraq wrote: post #14

Earlier quoted context omitted.

This is actually going to be my next project, now that we’ve shipped Octane there’s a lot of code that we can slowly start to move away from! The plan is to move toward optional features and then deprecations for many of the classic features, allowing Octane users to opt-in to the benefits progressively, while still supporting Classic users for some time as they transition. Definitely curious how you got these number…

Sorry, I was apparently producing a development build. I'm used to create-react-app, which eliminates this exact scenario by always building in production mode, so that people can't accidentally ship a development build to production.

The idiomatic way of shipping an ember app is with ember-cli-deploy [1] which, among other things, will ensure that it ships a production build.

[1] https://github.com/ember-cli-deploy/ember-cli-deploy

Re: Ember.js Octane Edition

#19

Post by pzuraq »

liketostayanon wrote: post #8

Like the decorator syntax for tracking observables. Is the under the hood implementation an inspiration from mobx? Basically, the use of Proxy.

We definitely looked at MobX and Vue as we were designing the final user facing API! The implementation under the hood is pretty significantly different, ours is not based on pub/sub or observables/streams, it’s based on a pull-based mechanism which we’ve found to be much more efficient at propagating changes in UI driven apps. But the end result is definitely similar, and we learned a lot from their implementations
Post reply on HN