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

21–30 of 80 posts

Re: Ember.js Octane Edition

#21

Post by wycats »

jchw wrote: post #12

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.

You got that right.

We got a lot of inspiration from the React ecosystem, both in terms of component design (the root element is just another element) and composition.

Those changes played out differently in the context of Ember, because of the way our APIs work, but the core ideas are sound, and I'm happy that the React community paved the way.

Re: Ember.js Octane Edition

#22

Post by Touche »

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…

Just for anyone reading, 100kb is the max you want for initial load if targeting mode. This means that Ember is a bad choice for most web apps today. React isn't a great choice either because the lack of features and relative large size means you have to add more stuff and quickly get large builds.

Re: Ember.js Octane Edition

#24

Post by wycats »

dstaley wrote: post #16
gavinjoyce wrote: post #13

Earlier quoted context omitted.

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!

I think that's probably a good change to the default. Today, `ember build` is analogous to `ember s`, and most people deploy to production with `ember-cli-deploy`.

But that's not a good enough reason :)

Thanks for surfacing this!

Re: Ember.js Octane Edition

#25

Post by sudders »

We have been using Ember for the last 5 years, and have been continuously shipping new features and updates on a daily basis. Our different applications have been following every upgrade path, and because of that we have not required a rewrite of our codebase.

Ember has been a great choice for our business, and has given us the opportunity to punch well above our weight class.

Ember is a wonderful front-end framework and deserves a lot more credit than it is currently getting.

Great job Ember Team, keep it up, the community loves you!

Re: Ember.js Octane Edition

#26

Post by pzuraq »

sergiotapia wrote: post #23

Superficially, Glimmer reactivity looks very much like Mobx in a very good way. Any significant differences?

The underlying implementation is the largest difference. Where MobX relies on pub/sub and observables to propagate dirty state, Glimmer’s autotracking uses a lazy system that incurs minimal cost until render occurs. We’ve found the overall performance of this system to be much better, and the primitive easier to optimize.

Re: Ember.js Octane Edition

#27

Post by wycats »

pzuraq wrote: post #26
sergiotapia wrote: post #23

Superficially, Glimmer reactivity looks very much like Mobx in a very good way. Any significant differences?

The underlying implementation is the largest difference. Where MobX relies on pub/sub and observables to propagate dirty state, Glimmer’s autotracking uses a lazy system that incurs minimal cost until render occurs. We’ve found the overall performance of this system to be much better, and the primitive easier to optimize.

And on top of that, the fact that we use a simple reactivity primitive under the hood[1][2] means that we have been able to transition from an API designed for 2012-era two-way bindings to a unidirectional data-flow model with minimal disruption, and with free interoperability between code written with the two APIs (even in the same object).

This also means that we can design new functionality (like Octane's modifiers, and other upcoming reactive APIs) without worrying about how the parts of the system will work together.

[1]: https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...

[2]: https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...

Re: Ember.js Octane Edition

#28

Post by wycats »

sergiotapia wrote: post #23

Superficially, Glimmer reactivity looks very much like Mobx in a very good way. Any significant differences?

You're absolutely right. We took a lot of inspiration from the MobX API design.

One thing worth calling out: MobX requires you to mark getters as `@computed`:

  class OrderLine {
      @observable price = 0
      @observable amount = 1

      @computed get total() {
          return this.price * this.amount
      }
  }
The equivalent Octane class:

  class OrderLine {
    @tracked price = 0
    @tracked amount = 1

    get total() {
      return this.price * this.amount
    }
  }
This is more important than it looks. The fact that you don't need to decorate the getter also means that you can break up a computation that uses tracked properties into smaller functions without needing to think about how the smaller pieces should be written. You just use functions.

Here's what happens when you try to add methods with arguments to MobX:

  import { observable } from "mobx"
  import { computedFn } from "mobx-utils"

  class Todos {
    @observable todos = []

    getAllTodosByUser = computedFn(function getAllTodosByUser(userId) {
      return this.todos.filter(todo => todo.user === userId))
    })
  }
And Octane:

  import { tracked } from "@glimmer/tracking";

  class Todos {
    @tracked todos = [];

    getAllTodosByUser(userId) {
      return this.todos.filter(todo => todo.user === userId))
    }
  }
The rule in Octane is: "mark any reactive property as @tracked, and use normal JavaScript for derived properties". That's pretty cool!

Re: Ember.js Octane Edition

#29

Post by holler »

wycats wrote: post #28
sergiotapia wrote: post #23

Superficially, Glimmer reactivity looks very much like Mobx in a very good way. Any significant differences?

You're absolutely right. We took a lot of inspiration from the MobX API design. One thing worth calling out: MobX requires you to mark getters as `@computed`: class OrderLine { @observable price = 0 @observable amount = 1 @computed get total() { return this.price * this.amount } } The equivalent Octane class: class OrderLine { @tracked price = 0 @tracked amount = 1 get total() { return this.price * this.amount } } Th…

this is incredibly awesome :) solid work, really excited to try this out!

Re: Ember.js Octane Edition

#30

Post by karmelapple »

artsyca wrote: post #9
anm89 wrote: post #5

It is such a tragedy that ember did not gain more traction. It's incredibly elegant, powerful and ergonomic. Once you got into the groove, writing ember code was so intuitive. Glad to see they are pushing through

It's no tragedy Ember is a niche product and the community is unique and hasn't gone the way of angular or react with all the false corporate stereotypes

Outside of the solid technical foundation and pedigree, the organization of how Ember is managed is one of its best aspects. There is no single massive company that may decide to drive development in a major breaking way.

Ember has always focused on ensuring upgrades are fairly easy to do, and has only gotten better over time.

Post reply on HN