Ember.js Octane Edition | Hacker News Reader

Ember.js Octane Edition

blog.emberjs.com

187 pointswycats75 comments

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

Can you shed a little light on the sorts of things that are shipped hundreds of times a day? curious if you could share some use cases or examples.

Intercom is pretty awesome - congrats!

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.

do you work there? how would you know?

Here's a graph showing ships / day from 2013 to 2015: https://youtu.be/NoCxHTxpmSQ?t=299

Doubt it. There's a lot going on under the hood.

5 PRs a _day_ per engineer? What exactly are they cranking out? 1hr 30min per PR that's insane. Are these literally one-liners or extremely well defined tickets? Do your engineers work very late days?

I have days where I submit 0 PRs, and I have days where I submit 10+ PRs. It just depends a lot of things. Focus, Well defined small tickets, etc

Sorry, I meant to say we ship to production about a hundred times per day, not hundreds of times per day. We've shipped continuously since the very early days of Intercom. [1]

We have a solid CI/CD pipeline meaning that every good merge to master hits production a small number of minutes later. Most of these changes are pretty small, focused and routine, adding a new button behind a feature flag, a db migration, a bug fix.

These small changes add up over time to a steady stream of highly polished features and improvements.

[1] https://www.intercom.com/blog/shipping-is-your-companys-hear...

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

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

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.

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.

Yes, basically all frameworks became React-like after the success of React.

In my opinion, the only one that got a really interesting take on components was Cycle.js, the rest simply tried to bend their APIs to look more Reactish.

good ideas are good ideas. The world only gets better when we let ourselves be inspired by others' success

More like everything is seen from the viewpoint of react. I've seen people lump in frameworks like angular and vue with react while comparing them in a way that don't make sense for the first two.

Aurelia is a framework that didn't rewrite their API's to try and become Reactish either. They have been over in their own lane, while Vue seemingly becomes React Lite.

Q: with regard to mixins and root elements, what downsides do you see to being more like React? I can’t see how these aspects aren’t better this way.

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

I think this is fresh opportunity for Ember to become mainstream again, modern Ember is so clean and productive

So many frameworks have borrowed from Ember more than Ember itself becoming mainstream I'd like to see the idiomatic approach become widespread whatever the idiom

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.

It's the golden standard for how ambitious web apps should be structured built tested and and deployed nothing comes close once you've experienced ember you can't possibly equate to the industry status quo

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

if you have any questions, feel free to join the ember discord: https://discord.gg/emberjs <3

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.

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!

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.

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

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

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.

100kb is an ideal right now. Many apps will have more than that in just CSS.

100kb is the max amount of JavaScript. There's a number for all resources but I don't know what it is offhand.

Using more than 100kb of CSS is a red flag and probably means you are using a framework like Bootstrap and not just importing the parts you need.

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

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.

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.

A big part of Octane is reducing the amount of "magic" under the hood for a lot of features. For instance, autotracking and tracked properties now allow you to use plain JS for most computed values, which means that every stack trace that you have while debugging a getter will be a standard stack trace, without confusing computed property code in between!

I definitely encourage you to check it out sometime, a lot has changed!

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

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!

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

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

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.

CrowdStrike also uses ember and loves it.

Handlebars isn't really what ember uses. And it's unfortunate that the extension is shared.

there are tons of improved semantics with Octane's Ember Templates that the handlebars you're thinking of could never dream of representing -- mainly @args vs attributes (like html attributes can be forwarded via ...attributes)

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

is there anything in particular you don't like?

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

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.

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.

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.

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!

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

Reply on news.ycombinator.com