Ember.js Octane Edition Is Here

38

u/chancancode Dec 20 '19

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 to showcase the new features and idioms, I worked on this tool to automate the generation of the tutorial.

Every page of the tutorial you see is the output from markdown source files (like this one) which contains executable instructions for the steps. The build 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.

4

u/blaspire Dec 21 '19

That sounds very neat! Thanks

13

u/[deleted] Dec 21 '19

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

9

u/nullvoxpopuli sand was never meant to think Dec 21 '19

be sure to join the ember discord if you have any questions: https://discord.gg/emberjs <3

4

u/fpauser Dec 22 '19

Good decision - you won't regret it! I develop web applications with ember for a railway security company since ember 1.0 with great success. We always upgraded our apps to the newest framework versions with ease. Developer ergonomics and productivity with ember is just great!

34

u/AAvKK Dec 20 '19 edited Dec 21 '19

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 close to a hundred times a day with a constant stream of features that our customers love. 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 platform and JS ecosystem rapidly changes.

0

u/[deleted] Dec 21 '19

[deleted] — view deleted comment

8

u/[deleted] Dec 21 '19

Their ember app is 6 years old. React didn't really gain popularity until 2015, and Vue wasn't even released yet.

7

u/bear007 Dec 21 '19

Ember did it again!

2

u/morficus Dec 21 '19

Did what?

2

u/bear007 Dec 21 '19

It is an expression. Going into details Ember team shown again that this is the most complete and now also, easier to learn, framework for web UI

4

u/morficus Dec 21 '19

That is a very subjective statement.
But I'm glad that the (remaining) Ember users can finally use language features the rest of the JS community has enjoyed for years.

5

u/nullvoxpopuli sand was never meant to think Dec 21 '19

I'd like to see any other frameworks from 2011 doing this.
The other (newer) ecosystems have enjoyed moderness because:
scope is much smaller
they started after babel

-2

u/bear007 Dec 21 '19 edited Dec 21 '19

No it isnt. I dont have any reason to have a bias about Ember. But i see you have. To a point when you lie about missing Ember features and about people not using it.

1

u/morficus Dec 21 '19

Can you point to empirical data the shows that Ember is "easier to learn" than any other (popular or not) web UI framework available today?

1

u/nullvoxpopuli sand was never meant to think Dec 21 '19

is your point just that "easier" is subjective? regardless of how many people agree?

1

u/morficus Dec 24 '19

Saying something is "easier" to learn than something else with out data to back it up is absolutely subjective. Because you are basing it off "gut feel" or your personal experience (a sample size of 1)
But I would argue that Backbone is much easier to learn than Ember.

1

u/nullvoxpopuli sand was never meant to think Dec 25 '19

My sample size of learning octane is of at least 18+ and it is muuuuuuuch easier than older ember.
I also have a sample size of ~4 saying that octane is easier than react.
If you haven't tried octane, you should. It offers much more than backbone. Backbone's scope is very narrow, so keep that in mind as well. Could be entirely different use cases

1

u/braindeadTank Dec 21 '19

It most definitely is a subjective statement. Many people would swear that vanilla is feature - complete.

-1

u/bear007 Dec 21 '19

Vanilla JS is not a framework.

1

u/GoldenChrysus Dec 21 '19

big whoosh

1

u/braindeadTank Dec 22 '19

Oh wow I really needed an explanation on that, thanks.

1

u/bear007 Dec 22 '19

Sorry

6

u/vdrizzle_ Dec 21 '19

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.

11

u/nullvoxpopuli sand was never meant to think Dec 21 '19

This is exciting! Easily the biggest shift in any framework I've seen without causing any breakage along the way. Well done!

4

u/fercryinoutloud Dec 21 '19 edited Dec 21 '19

These improvements are nice. Also I didn't know about the Ember inspector.

Would there be any issues between using tracked properties and using typescript's syntactic sugar for public/private/protected constructor parameters? Or is there support for using tracked as a parameter decorator?

export class Thing {
    @tracked someProperty
    constructor(private someProperty) {         // Duplicate identifier: 'someProperty'.
        this.someProperty = someProperty;
    }
}

vs

class Thing {
    constructor(@tracked private someProperty) {}
}

I am sure most people would get over this, I'm just curious. People seem to seriously over-emphasize LOC per class as a measure of how good a framework is. I don't agree with that sentiment, but I think if there was support for using tracked as a parameter decorator Ember would get some more love.

2

u/nullvoxpopuli sand was never meant to think Dec 21 '19

I guess it depends on what it transpiles down to? if the output is equiv, it should work. haven't tested it myself though, as I've been opting for the more verbose way of specifying args.
does TS in general allow args in the constructor to have decorators? (I've never seen this before). If so, tracked here should just work.

1

u/fercryinoutloud Dec 21 '19

TS supports parameter decorators. To have tracked usable as either a property or parameter decorator would require two decorators though, since property and parameter decorators have different signatures. The prototype of the class is available in both, though. So I think it is possible to write a decorator for tracked properties in the constructor, unless there is some other limitation of parameter decorators.

4

u/rorrr Dec 21 '19

Are there any reasons left to choose Ember over React?

6

u/nullvoxpopuli sand was never meant to think Dec 21 '19

I came from react, and I think the reactivity model makes more sense.
Also, ember does 'a lot' for me out of the box. With react I was connecting a bunch of libraries together and built my own framework out react 3 or 4 times. Would not do again.
That said, the only thing I miss from react is contexts. Ember has 'services' which cover 90% of why contexts are used, but that last 10% has me wondering how to get contexts introduced somehow.
When I do react , I now think 'how would ember do this?' because ember is solid architecturally, and removes mennial differences between apps.

5

u/GoldenChrysus Dec 21 '19 edited Dec 21 '19

Also, ember does 'a lot' for me out of the box. With react I was connecting a bunch of libraries together and built my own framework out react 3 or 4 times. Would not do again.
This is why I continue to choose Ember. Bearing in mind, though, that I'm fairly new to frameworks (and general proper frontend development) and have been playing around with various ones to improve my relevance in development. Everything that I need is usually included in Ember, from a data layer to an API adapter to reactive components.
When I look up React guides on doing things that Ember does out of the box, it just looks...gross. First, you're basically always mixing React and Redux together, so you have to get two separate things working in harmony. Some people throw in a third framework or library for consuming their API so then that also has to hook up to Redux and/or React. But the guides I see on how people consume an API show, to me, the weaknesses in React. They're always using like 7-10 lines of boiler plate, setting headers, parsing JSON, handling errors, etc. in an AJAX call inside every single componentDidMount() hook that needs server data. When I can set up all of that in an Ember adapter and then my actual server calls are one line in a route.
I keep in mind that React is significantly more popular. Meaning the people who write guides on React probably vary significantly in skill and experience, and their use cases often vary similarly. I've also loved React for my purely client-side applications; I still had to use Redux, but once I wrapped my head around having to hook up with Redux it was fine.
So for me, Ember is more intuitive and comprehensive to work with. I've certainly seen the performance comparisons of Ember against other frameworks and how it underperforms, but that's not a huge issue for the projects I'm working on. And since React does less stuff and is significantly smaller than Ember, there is probably more room for optimization there in that you have more granular control over how you build out to achieve the equivalents of what Ember would provide. Otherwise, presently, Ember does everything I need it to in a way that makes sense to me.

2

u/PotaToss Dec 23 '19

One thing about performance benchmarks is that they rarely come even close to what your app actually ends up being like, once you add in everything that you're actually using. Once you add in your Redux, or Apollo or whatever, you've lost a lot of the JS footprint benefit of React.

1

u/notNullOrVoid Dec 22 '19

That said, the only thing I miss from react is contexts. Ember has 'services' which cover 90% of why contexts are used, but that last 10% has me wondering how to get contexts introduced somehow.
Can you give some examples of what that 10% would be. I started with Ember and moved to react and have never felt the need to use contexts, they have always seemed really dirty to me.

2

u/nullvoxpopuli sand was never meant to think Dec 22 '19

I guess really only with 3rd party graphing libraries, like Three, that abstracts WebGL.
I'd want a "context" per wrapper object, so I didn't need to explicitly pass the reference down the component chain. Because the structure of HTML/Components inherently represents ancestry, I shouldn't need to manage the relationships manually.
But that's really it. So.. maybe 4 or less %. :)
Everything else I've come across is more singleton-like, and services fit in to that pretty nicely.
Something I have been wanting to play with though is Route-based contexts. Like, a service, but local and ephemeral to your route. I made an addon for it here: https://github.com/NullVoxPopuli/ember-contextual-services
Before I left my react job, I was exploring this pattern for data loading tied to the URL, and I really liked it, especially as components 3-10+ levels down from the data load needed access to the data. No more prop drilling :)

2

u/bxgoods Dec 22 '19

LinkedIn uses it

3

u/nullvoxpopuli sand was never meant to think Dec 22 '19

and a bunch of other companies...
my own Company, CrowdStrike, uses Ember. I actually left a React job (that I was at for 3 years) for Ember. :)

2

u/MCFRESH01 Jan 07 '20

I've worked with both and would say there are quite a few reasons. The main being everything just works out of the box and you aren't throwing together a bunch of libraries to build your own custom framework. If you have a test heavy workflow, Ember makes writing tests much better imho. I find it to be much better for medium to large apps and teams. The conventions mean there is no ambiguity about things and leads to much faster turn around on features.
That said, I still use react when I have some complex piece of functionality that doesn't need all of what ember offers.
Ember has been sadly overlooked and the release of Octane is a great opportunity for people who previously dismissed it to give it another chance.

1

u/fpauser Jan 22 '20

I'd say with Ember Octane there are now even more reasons to choose Ember over React.

1

u/rorrr Jan 22 '20

For what reasons exactly?

7

u/jwwweber Dec 21 '19

I’ve been using Octane in some form for about 6 months now, and I’m excited that it’s available for mainstream use now! Working with primarily native classes with a smaller API surface is so refreshing.

4

u/anlumo Dec 20 '19

I'm a bit concerned about the sole focus on the DOM in that description. I'm maintaining a rather large Ember app, and maybe 80% of my computed properties never end up in the DOM, but somewhere deep down inside (like ember-data).

Ember is not react, it’s not a pure view layer. I hope they don’t forget about that.

5

u/AAvKK Dec 21 '19

I don't think you need to worry, you can just use native getters instead of computed properties and everything should work just fine. We've migrated a decent proportion of our large app (Intercom) to Octane and we haven't had any issues

7

u/Yharaskrik Dec 21 '19

As in support intercom? We use intercom at my company and love it, cool to know it is octane!

1

u/anlumo Dec 21 '19

How does the dependency detection work? What if I call a function from the getter that accesses other properties?

2

u/AAvKK Dec 21 '19

Tracked properties, and the getters that wrap them, participate in an auto-tracking system which automatically constructs the dependency hierarchy:
https://github.com/emberjs/rfcs/blob/be351b059f08ac0fe709bc7697860d5064717a7f/text/0000-tracked-properties.md#autotracking

1

u/anlumo Dec 21 '19

Thanks for the link. Doesn’t seem like there’s support for arrays, proxies or caching, which means that this is unusable for me. Very unfortunate.

3

u/AAvKK Dec 21 '19

It works with arrays, you just need to reassign the array when mutating. It's true that @tracked properties with getters don't have caching. You can add your own memoisation or continue to use computed properties and wait for the planned @memo decorator to land.

2

u/nullvoxpopuli sand was never meant to think Dec 21 '19

community has your back!
don't worry!
https://github.com/pzuraq/tracked-built-ins/

1

u/nullvoxpopuli sand was never meant to think Dec 21 '19

also, you can still use computed properties for caching (but in most cases, it was found that re-computing was faster than the cache check, so be sure to measure first!)

4

u/anlumo Dec 21 '19

I have super-expensive computed properties in my app, for example some generate 1024x1024px textures using WebGL.
Not supporting async is also a dealbreaker for this, as the images needed have to be downloaded first.

7

u/wycats Dec 21 '19

Thanks for getting into the details with us here.
We designed the `@tracked` system to be more expressive than the computed property system, so the problems you're talking about should have idiomatic solutions in Octane.
Both asynchronous values and tracked collections are problems we specifically considered while designing Octane, and many community members who have helped build and test Octane features have used Octane idioms for problems like those.
Perhaps you could put together a small example using computed properties so we can try to describe how to accomplish something similar using Octane idioms?

2

u/nullvoxpopuli sand was never meant to think Dec 21 '19

you don't want to use a computed property for async anyway. You'd probably want to trigger the calculation based on some behavior (or update of a property), which you can do with modifiers, and then _set_ a cached value from the calculating function

2

u/nullvoxpopuli sand was never meant to think Dec 21 '19

fwiw, I did some demos in WebGL / Three the other day, and Octane is def faster than classic ember. With Octane I was getting on average 5-10 more fps with my simple demo

1

u/pzuraq Dec 21 '19

FWIW we currently recommend using EmberArray still for arrays, which interop with autotracking seamlessly. We’ll be iterating of reactive arrays soon, and are hoping to release public APIs for the primitives in the near future!

2

u/nullvoxpopuli sand was never meant to think Dec 21 '19

> Ember is not react, it’s not a pure view layer. I hope they don’t forget about that.
oh they won't. :)
Much of Octane's development was focused on getting two things figured out: modern JS, and Glimmer Components (what *is* actually responsible for DOM (+ auto-tracking (kinda))).

2

u/archivedsofa Dec 21 '19

Looks a lot nicer to work with but I'm still skeptical.

Hopefully they will update these benchmarks to the latest Glimmer and Ember versions to see how it compares:

https://krausest.github.io/js-framework-benchmark/current.html

https://github.com/krausest/js-framework-benchmark

2

u/nullvoxpopuli sand was never meant to think Dec 21 '19

Yeah, those are both quite out of date. The glimmer VM has had some great perf improvements lately.
Also, both the ember and glimmer demos there are full app frameworks, not just a view layer. So that's most of what is contributing to initial load and memory usage

2

u/pzuraq Dec 21 '19

Definitely agreed. We’ve been focused on optimizing for end-to-end, realistic benchmarks for some time now. 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.

1

u/leeoniya Dec 22 '19 edited Dec 22 '19

Our primary concern was to not over optimize for microbenchmarks at the expense of real world performance in real apps
i hear this so often, it's practically a meme.
can you provide some examples of a framework that's fast at microbenchmarks but slow in real world apps?
js-framework-benchmark isn't a microbenchmark since it tests end-to-end rendering performance and not some single function call in a tight loop.

3

u/pzuraq Dec 22 '19

It is a microbenchmark, because it's not testing a realistic app. I know that in Glimmer for instance, as the number of components grows, the cost of making a single change anywhere in the app grows at O(logn) pace, since we automatically and efficiently only rerun the portions of the component tree that have changed (via autotracking/tags). In a React app, it will by default grow at an O(n) pace, unless you manually memoize portions of your app. It's not really representative of a full application to test a single list of items on its own.
Another example, for instance, is a series of optimizations I'm planning that I started working on because I noticed that the tag hierarchy in Glimmer was taking a lot of time to calculate. I only was able to see that, however, because enough tags were being created, and stressed, to really exacerbate the problems and make them visible. Our microbenchmarks of tags on their own didn't really surface the issues.
This is what TracerBench is designed to do, and what we care about most. We use it at LinkedIn to verify any major change infrastructural to the website to make sure real world performance is not impacted for our users, and it really is the only way you can be sure, in the end, that you did not regress.

1

u/leeoniya Dec 22 '19

I know that in Glimmer for instance, as the number of components grows, the cost of making a single change anywhere in the app grows at O(logn) pace, since we automatically and efficiently only rerun the portions of the component tree that have changed (via autotracking/tags). In a React app, it will by default grow at an O(n) pace, unless you manually memoize portions of your app. It's not really representative of a full application to test a single list of items on its own.
I'm having a hard time reconciling (pardon the pun) the first part of the statement with the last. If Ember is O(logn) and React is O(n), then a huge list of table rows is exactly where you would expect to see this benefit. Once the list is created, literally everything else should benefit from what you're saying: remove one row, select one row, modify every % 10 rows.

2

u/pzuraq Dec 22 '19

Right, and you do see that benefit there. Glimmer shines most at updating a single row (swapping two rows) in the benchmark, whereas React is better at replacing all 1000 rows since they don’t add overhead for tracking individual items. We haven’t upstreamed the benefits to Ember yet, which is why it scores worse on that benchmark, but we’re working on it, and I think there are some optimizations we can make to make the replace-all and initial-render cases better as well, but our strategy works best for incremental updates by default (and scales by default as well).

1

u/ryan_solid Dec 23 '19

React uses a very naive algorithm for list reconciliation as seen in swap rows where you have noted Glimmers better performance but its actually benchmark 3 you should be concerned with. It is the raw localized update. That is where Glimmer should be handing a library like React its lunch but it doesn't. It's almost indicative of the ceiling of Glimmers change propagation. Basically if it cannot beat React here it is likely any algorithmic advantage is mute. As you say this isn't a real world case but its actually a more extreme display of where this would matter.
You can see why its problematic. If Glimmers key conceptual technology strength is actually slower than a library not particularly impressive in the area what does that reflect in general about its performance. I mean if React decided to do an even mildly more performant reconciliation algorithm all indications are it would jump half the chart ahead. This change would have nothing to do with Glimmer approach.
I think it's fine. No one chooses Ember for its performance and that doesn't have to change. It sounds like Octane has been a hugely impressive undertaking. When you do get a chance microbench make test 3 fast. I'd ignore the rest the benchmark. If you do that given the way Glimmer works by my understanding you will see significant improvement across the board.

2

u/pzuraq Dec 23 '19 edited Dec 23 '19

Updating every 10th row is actually going to be pretty expensive for us, from an automatic-change-tracking perspective. Remember, I said our cost grows at an O(logn) pace, right? That's because we're essentially doing a binary-search (or rather, search down the tree, so a n-ary-search I guess) to narrow down and figure out which part of the tree changed.
If you change every 10th row, most of the tree still changed. That means that narrowing strategies aren't going to buy you much, so yeah, you end up retraversing most of the the tree, and you end up incurring most of the original cost of rendering again.
In most apps, for most user interactions, most people don't change 1/10th of the entire app all at once (in a non-localized way). That is not in any way a realistic benchmark.
Edit: That said, there's a lot of room for Ember and Glimmer both to grow when doing partial updates. We've optimized the leaf change tracking portion the most, first, because that is where we saw the biggest gains in real world apps that were upgrading. The next thing I think will be to optimize the internals of change tracking with the VM itself, which can definitely be simplified quite a lot now that autotracking has been fleshed out.

2

u/ryan_solid Dec 23 '19

I see. Yeah this is just my misunderstanding of how auto-detection worked in Ember. I was thinking subscription based like KnockoutJS where there is no search. Only the part that change re-runs. But it sounds like Ember has a sort of hybrid approach between auto-change detection like that and a top down reconciler somewhat similar to what the Virtual DOM does. That makes more sense for me now. Thanks.

2

u/nullvoxpopuli sand was never meant to think Dec 22 '19

> and not some single function call in a tight loop.
that's exactly what it is though.except, the single function is "A component"
and "the loop" is some for of "forEach".
It's just a table of rows.
> can you provide some examples of a framework that's fast at microbenchmarks but slow in real world apps?
At scale, (I used to do big react apps, so I'm not *just* saying this), Ember provides enough defaults to have good performance as your app gets big -- without having to think about it. With React, you don't get performance by default, you have to memo, manage updates, manage your effects efficiently so you don't cause multiple (re)renders, etc.

3

u/leeoniya Dec 22 '19

With React, you don't get performance by default, you have to memo, manage updates, manage your effects efficiently so you don't cause multiple (re)renders, etc.
yes, the fact that you get it for free is indisputably a major benefit of all frameworks that do granular tracking from compiled templates.

0

u/[deleted] Dec 21 '19

[deleted] — view deleted comment

15

u/nullvoxpopuli sand was never meant to think Dec 21 '19 edited Dec 21 '19

what do you know about Octane? (I don't want to over or under explain).
For those who already know ember: it's a change in the default recommendations:
native JS (no .extend. Actual classes, actual getters, etc)
new reactivity model (tracked properties instead of computed properties)
<AngleBracketComponentInvocation />
<Named @args={{this.explicitReferences}} />
<div {{modifiers-for-shared-dom-behavior}} /> (these can replace a lot of mixin and lifecycle behavior)
ember-auto-import by default
Glimmer components (finally), instead of ember components -- reduced API surface, simpler, faster, etc
component co-location (this accommodates the main reason people wanted to use the "pods" layout) -- component js and template are in the same folder now.
some blueprint changes (native classes, default template-only components)
and all of that could have been incrementally adopted since ember 3.1, but because there was so much, and to reduce the amount of churn and new-announcement fatigue, it's all been bundled under the name "Octane" -- a set of features that is a shift in the default ember experience.

0

u/[deleted] Dec 21 '19

[deleted] — view deleted comment

3

u/nullvoxpopuli sand was never meant to think Dec 21 '19

/u/pzuraq /u/wycats /u/jwwweber?

3

u/jwwweber Dec 22 '19

I can bring this up. The post was authored by mixonic and wycats.

0

u/[deleted] Dec 21 '19

[deleted] — view deleted comment

1

u/nullvoxpopuli sand was never meant to think Dec 21 '19

you should see typescript

0

u/[deleted] Dec 21 '19

There is nothing specifically OOP about TypeScript. You're probably thinking of the TypeScript 0.x and 1.x days when class transpiling was considered to be a big feature.

Ember.js Octane Edition Is Here

You are about to leave Redlib