At Intercom, we've been incrementally upgrading our almost 6 year old Ember app to Octane as the features have landed over the past 8 months. Our app continues to be in great health and we continue to ship hundreds of times a day with a constant stream of features that our customers love [1]

Octane is a huge leap forward for Ember. Its APIs are extremely well designed, composable and cohesive. The new Glimmer components and @tracked properties have resulted in waves of negative diffs as we refactor parts of our app to Octane and, IMO, are an advancement in the state-of-the-art component state tracking / reactive UI.

If you've tried Ember before and were turned off by some of its slightly weird APIs (computed properties, component APIs like tagName, classNames & event handling, the ember object model), you should take a second look.

With Octane, Ember is a framework for rapidly building high quality web applications that will remaining healthy over time as the web platform and JS ecosystem rapidly changes.

[1]: https://www.intercom.com/changes/en

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 for the steps. The build[4] system will run these commands and edits the same way an end-user would, capture the output of the commands and put them in the tutorial. It also takes the screenshots by opening a real browser (via puppeteer) and navigating to the actual app that we are building as part of the tutorial.

All of these ensures that the tutorial content and screenshots are up-to-date with the latest blueprints (the files used by the generators), config files, etc, and that everything really works as-expected. It makes it much easier to maintain and QC the teaching materials, but also servers as a very useful end-to-end smoke test to ensure all the moving pieces in the ecosystem (including external components like npm, node, etc) are all working together.

Right now the tool and the tutorial content are in the same GitHub repo, but the code is actually written to be completely agnostic to Ember.js (or JS even). It just runs shell commands, edit files etc. My intention is to separate out the tool to its standalone thing, so more communities can benefit from this approach.

[1]: https://guides.emberjs.com/release/tutorial/

[2]: https://github.com/ember-learn/super-rentals-tutorial/

[3]: https://raw.githubusercontent.com/ember-learn/super-rentals-...

[4]: https://github.com/ember-learn/super-rentals-tutorial/commit...

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!

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.

I've been building new product from scratch with Ember Octane and TypeScript since March 2019, and it's been a great experience. I will be able to launch the app I spent 10 months building without any substantial refactoring. I would say the Octane API has essentially been stable for almost a year, if not longer. I even had a preview of the rewritten documentation to learn from the entire time. Ember has really come a long way from the early days. The last time I built an Ember app was before 1.0 was released. Building with Octane before it was released has been spectacular.

I've been using Ember in some capacity for 6+ years now I think. And have been using ember on about 5-8 different production-shipped projects (with Elixir backends) and it's been a great combination for our company from a tech standpoint.

The bigger issue has been finding contracting talent that's more affordable. Since there's a real dearth of talent in general (and freelance contractors) in the Ember world since the community is already so small, the few that are there are too expensive for us to hire for more than a couple week bursts.

I hope Octane helps bring more people to the Ember ecosystem and introduces more variance into the contractor rates, since I want to keep using Ember for future projects.

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

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.

Coming from other frameworks the Octane approach definitely seems more familiar. I am looking forward to my first Ember app :).

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 app down too, especially on initial load. For comparison, my _entire_ React application (which includes emotion, react-router, and a full data synchronization library) is only 356 KB (104 KB gzipped). Don't get me wrong: there's certainly applications where the size of the JavaScript doesn't matter, and I think Ember is _great_ for those use-cases. I just wish it could be used for smaller, mobile-focused applications without being several times larger than an equivalent React app.

[1] Apparently this is the development size. The production size is 712.29 KB (180.80 KB gzipped). My point still stands though.

Yaaaaas.

Octane looks so much nicer. This is the lift codebases that have been using Ember for 6+ years will greatly appreciate.

And! It'll be great to show off ember at local meetups with the nice new syntax!

I like Ember.js, been using it since version 1.12, through to 2.x and now 3.x. Had been playing with the beta builds of Octane on the side, glad to see it all coming over to the main build!

On using Ember

I’ve been using ember since 0.9.5.1, so for 8 years or so? (I have 6 biggish apps that are still under active development today)

At the time — there was no router, Ember.View was a thing, there were multiple types of views and controllers, JSON:API wasn’t a thing, ember-data was wild, etc. Most of the contributions depended on tomhudakatzdale, as well as a number of other core contributors (dgeb, tchak, and others I’m leaving off — sorry!). The framework frequently had breaking changes, patterns were moving around rapidly (we had to rewrite one of our pre 1.13 apps), it was a bit of a mess. (Then again, at the time, a lot of other frameworks were in the same state.). I think these times gave Ember a bit of a bad rap.

The thing that stood out to me then, and still holds true today, is that the community has been committed to bringing in the best ideas forward in a community-driven way. Even though much of the initial framework had growing pains, it was able to do a few significant things: establish a community model for managing changes (RFC/RFP process), delegate core responsibilities to a broader team of people (not based on corporate interests), create consistent release intervals, follow semantic versioning, establish json:api as a specification, and really take community feedback in as development priority / direction.

Octane is the cultivated result of years of decision making by the community. (And, I believe, that’s why folks say “Ember is great tech”).

I continue to use and recommend Ember to others. Happy to answer any questions for folks!

Ember does a ton of magic under the hood that when something goes wrong it's the hardest thing to debug. Ember is also strongly opinionated which some people like I guess. Ever since I've switched to React + Redux I've never looked back.

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

I kind of hoped that Ember would ditch Handlebars for templating and move towards something a bit nicer. I find Handlebars syntax to be quite annoying and tedious to write. Kudos to the Ember team for persisting with the framework, I know LinkedIn is using it (and learned in this thread that Intercom is as well).

If this latest Ember release excites people, I highly recommend that people check out what the Aurelia team have been working on with Aurelia 2 https://aurelia.io/blog/2019/10/31/aurelia-vnext-2019-fall-u.... I have always seen Aurelia being similar to Ember, except the syntax is cleaner (especially templating) and is conventions based. There are a lot of similarities between the two.

One thing that Aurelia are doing in Aurelia 2 is an option to shake it down to a tiny app. The problem with frameworks like Angular, Ember and Aurelia 1 is they ship a lot of code to the browser and startup time can be quite slow. In Aurelia 2 they're working on quite a nice and promising AOT compiler. I really wish the Ember team would focus on bundle size, what I have seen with Octane, the bundles are huge.

My money is on Aurelia 2 when it launches in 2020, so it is nice to see Ember firing back as well, great timing given the recent State of JS survey yielded people are really frustrated with Angular.

    <MyComponent 
      class='foo'         // any html attribute
      @arg={{this.value}} // @ = arg
                      // this = owned by the current context
    />

    (and inside that)

    <div ...attributes> // gets the class attribute
      {{@arg}} // you *know* that @ means it was passed in
    </div>

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

This is an awesome update, really like the new component APIs and the ergonomics for manipulating the DOM!

I mostly worked with React and Vue, since Ember had quite a learning curve in the past and wasn't really an option for me. But this new edition seems to be much more straightforward to start working with. Looking forward to build my first Ember app over the holidays :-)

Wow. I really didn't realize it was so close! I've just today finished up what took me away from my Ember project.

Ember has been freakin' amazing to use, and Octane really, really, makes it shine. I love ember because it includes everything you need to manage state in your application, install and you're ready to go. I don't have to pick my view renderer, state/history management, storage system, networking stack etc... I also don't have to maintain the dependencies between them, like I would with something built using React.

Ember also favors convention over configuration; which, I find to be a godsend when visiting the world of JavaScript. Yeah, it's a bit painful sometimes not knowing the convention, but that's just good ol' fashion learning. I also think the opposite, configuration, is incredibly painful in JavaScript, because the ecosystem moves so fast.

The Ember team (and community) also have fixed, and continue to fix, a ton of issues from making module loading easier to better support of Typescript.

I'd like to give a few getting started tips for anyone about to jump in (as I did the same a few months ago):

* Glimmer templates give you nice HTML-esque looking components while separating the HTML from the JavaScript itself (which I like versus embedding it like JSX does)

* Use the decorators. Seriously, they're awesome, they're a MUST if you use typescript.

* Ember modifiers are really a big improvement over the previous hooks/lifecycle management. It's just the constructor and willDestory (I think), it also to me, makes it a lot easy to commit to ol' "data down, actions up" philosophy.

* Ember Concurrency [1] is a brilliant tool and can pretty much prevent any UI blocking you ever find yourself doing.

* Some things are automagically created for you unless you explicitly create them (with the right names) like the application controller and application router. Use the Ember debugger browser plugin to see what controllers and routes are being rendered if you're at all unsure.

* Ember CSS modules [2] helped me quite a lot encapsulating css (and wiring it up correctly for that matter).

* Use Mirage [3] to mock out your data from the beginning, don't hard code things you intend to query for later. You'll have trouble, plus Mirage is super easy to use.

* Make sure guides you're reading are relevant to the current version. Octane has been coming for a while so there's a fair bit of information, it's just something to be aware of (especially from results in google).

* If you're reading an older article that's relevant, but using older syntax try reading this: https://blog.emberjs.com/2019/01/26/emberjs-native-class-upd...

This series of articles is also immensely helpful: https://www.pzuraq.com/coming-soon-in-ember-octane-part-1-na...

Finally, I've found the Ember community to be incredibly nice and welcoming. Their Discord [4] is very active and full of helpful folks. Huge props and thanks to everyone who worked on this, it's super exciting and I'm gonna go hack on my Ember project now.

----

[1] https://ember-concurrency.com/

[2] https://github.com/salsify/ember-css-modules

[3] https://www.ember-cli-mirage.com/

[4] https://discord.gg/emberjs

Edit: Formatting.

Gotta love this. Great job everyone! Looking forward to what we build!

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.

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

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.

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`

I share your concerns.

fwiw, here is a small-medium sized app's bundle: https://emberclear.io/bundle.html (ignore the fact that ember is in that report twice, that's a problem with my analysis, and not the actual bundle)

Over the next year, the framework team is focusing _hard_ on reducing bundle size. Including: stripping deprecated features (which will be huge... at least 20kb (min+gzip), iirc)

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

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.

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!

After trying out almost most of the major libraries in the frontend ecosystem I feel that MobX-style observables (in combination with a state-tree abstraction like MST) simply offer the best combination of developer experience and performance.

It is not hard to write readable code with hooks (and hook based state management solutions), but it takes a lot more ramp up time and I see junior members in our team struggle with the nuances around closures (what value was captured when in the component lifecycle) frequently. Adopting MobX has been a huge productivity boost for our team.

At the same time, I feel the full potential of MobX is not fully realized in react ecosystem because the React core team does not recommend Object oriented state management with observables - the ecosystem would be so much better if popular components accepted observable data-structures and were built with implicit change tracking in mind (rather than the usual combination of controlled+uncontrolled props and callbacks which ends up being verbose and repetitive).

I hope octane results in Ember gaining traction in the community. It would be nice to have a framework that embraces reactive observable models, without also resorting to weird monkey patching (angular zones).

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.