
Ember.js Octane Edition - wycats
https://blog.emberjs.com/2019/12/20/octane-is-here.html
======
gavinjoyce
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](https://www.intercom.com/changes/en)

~~~
social_quotient
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!

~~~
itwy
Definitely a gross exaggeration.

~~~
nullvoxpopuli
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. :-\

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

~~~
gavinjoyce
Here's a graph showing ships / day from 2013 to 2015:
[https://youtu.be/NoCxHTxpmSQ?t=299](https://youtu.be/NoCxHTxpmSQ?t=299)

------
chancancode
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/](https://guides.emberjs.com/release/tutorial/)

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

[3]: [https://raw.githubusercontent.com/ember-learn/super-
rentals-...](https://raw.githubusercontent.com/ember-learn/super-rentals-
tutorial/master/src/markdown/tutorial/part-1/05-more-about-components.md)

[4]: [https://github.com/ember-learn/super-rentals-
tutorial/commit...](https://github.com/ember-learn/super-rentals-
tutorial/commit/785115a55168b2871d76072a465b9acbfeb6e0c8/checks?check_suite_id=367677990)

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

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

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

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

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

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

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

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

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

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

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

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

~~~
nullvoxpopuli
if you have any questions, feel free to join the ember discord:
[https://discord.gg/emberjs](https://discord.gg/emberjs) <3

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

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

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

~~~
gavinjoyce
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](https://github.com/ember-cli-deploy/ember-cli-deploy)

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

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

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

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

~~~
pzuraq
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!

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

~~~
wycats
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!

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

------
DigitalSea
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...](https://aurelia.io/blog/2019/10/31/aurelia-
vnext-2019-fall-update). 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.

~~~
nullvoxpopuli
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?

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

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

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

------
rubyn00bie
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...](https://blog.emberjs.com/2019/01/26/emberjs-native-class-update-2019-edition.html)

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

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/](https://ember-concurrency.com/)

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

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

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

Edit: Formatting.

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

------
pier25
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...](https://krausest.github.io/js-framework-
benchmark/current.html)

Also, in that link check how Glimmer fares in start-up metrics (very bad). And
it's not even the complete Ember framework.

~~~
HatchedLake721
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...](https://engineering.linkedin.com/blog/2017/06/glimmer--blazing-fast-
rendering-for-ember-js--part-2)

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

~~~
mixonic
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!

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

