EmberConf 2015 - Opening Keynote

YEHUDA: Hey, so, EmberConf 2015

this is the second time we're doing EmberConf

and it's twice as big or something as last year

There are 625 plus attendees,

we didn't count everybody in here

but it looks full

and there are 625 seats in here, so, great

also Tom hand counted 25 countries

on the Excel spreadsheet, so...

TOM: Well, it's actually 24, but I consider

New Jersey it's own country, so

YEHUDA: We need the rimshot

So, Ember is actually doing really great

Ember is growing a lot in a lot of different ways

and we wanted to talk a little bit about that

just to start, so obviously as we said

there's more EmberConf attendees,

there's twice as many

every year when we decide to go with,

you know, 625, that's the number this year

we're like "are we going to be able to sell out"

and as usual it sold out super fast, right, so

great. There's more Ember CLI users,

way more than there were last year

when Ember CLI was barely a thing.

We announced it at EmberConf last year.

Way more addons, if you go to

emberaddons.com, there's hundreds

and hundreds of addons now for Ember.

There's also more apps, and I thought

we'd highlight a few of them, that

came out this year, apps that happened

this year. So first of all, Square Cash,

that's an Ember app you may not have known

about, yeah, go Square.

Heroku Dashboard, announced this year

TOM: Yeah! That is awesome.

YEHUDA: This is actually a really awesome app

I often see accolades on Twitter,

about the Heroku Dashboard,

people who may not know it's

an Ember app. Ghost switched to

Ember this year, so now it's another

big open source project using Ember.

The app Beatport, I think Tom

knows more about Beatport than me.

TOM: It's like a hip DJ thing, you

wouldn't really know about it.

[audience laughter]

Intercom.io, did a large rework in Ember

this year. Consul, which is like Hashicorp's

new thing, is written in Ember.

Customer.io is written in Ember,

and the Nest Store is written in Ember.

So a whole bunch of new apps that you may

have heard of that are written in Ember

and this is actually something that maybe

doesn't get captured that effectively

when you're looking at some random trend

graph that someone's passing around

is, how many really big apps end up

being written in Ember? Ember's really

competing in the big app space, and

we do really well in that space.

TOM: And, probably the biggest thing for me,

the most awesome thing, is seeing the

number of meetups, spring up around the

world, that list on the Ember Community page

listing all the different cities around the world

that have their own meetups. It's just been

really heartwarming. And, actually, today

we have a special guest, here, someone

who has been spending a lot of their time

travelling the world, sharing their love

about Ember.

[laughter, applause]

Tomster.

TOM: So, we will have an opportunity, we

have a photo booth, you will be able

to have your photo taken. Alright,

have to get you a little hamster

treadmill. Alright, so say hi to

Tomster everyone, he's here!

Alright.

YEHUDA: Thank you.

TOM: Thank you Tomster.

YEHUDA: And we had a little video

we put together, just to showcase

some of the awesome meetups

we've been having.

My name is Jamie, and I

run the Ember user group

here in London, England.

Hey, my name is Luke,

and I'm the organizer

of Ember.js NYC.

Hi, I'm Kait, with the

Ember Portland group.

I'm Carsten

Mattia

Jorge

And I'm Megan

And together with the trope

formerly known as

Robin Ward, we've been coordinating

with Toronto Ember.js user groups

since about November of 2012.

Our meetup started in 2012.

We have been doing this since 2012,

I think.

We have over 500 members

and growing.

We currently have just around

400 members and are continuing to grow.

We have roughly 220 members,

but we're growing a lot.

We have been consistent,

great talks, [..]

incredible community here in

New York. I have made so many

friends and met so many great people.

We also hold Ember Hacker Hours,

where members of the Ember community

can get together, learn and hack on

Ember with other developers,

while having a chance to socialize

and get to know other members

in the community.

We've held 28 events including meetups,

project nights and hackathons.

to have you come visit us. Bye!

Ember!

[applause]

(You're on the big screen.) Cheers everybody.

Long live Ember.

[...] if I do scoot forward a little bit.

What if we do something like

where we just scooted forward all

of the team? [..]

What if we all like run by and scream

happy things about Ember?

Happy things about Ember.

Or if we just say "yay!"

Yay!

[applause]

TOM: Alright, thanks.

Leah, Leah put that together.

She sent out a request for all the little videos.

It's really awesome to see,

you know as a community run project,

to see all these user groups springing up around the world.

YEHUDA: And the next thing I want to talk about

is the core team. And, so here's the core team

today, it's a good group.

One thing that I like to talk about,

when I talk about the core team,

is just how many different groups

are represented here. It's not,

one company that does most of the work.

It's really a bunch of different companies.

I like to think of Postgres as an examplar

for me. I like our core team to be as many,

as diverse as possible.

And today, we're going to announce that

we're adding 3 new people to the

Ember Core team.

[applause]

These are 3 new people from 3 new

companies who haven't previously been

on the Ember Core team.

And all three of them have been doing

amazing work. Martin and "mixonic"

have been doing great work on the

HTMLBars engine, which has landed

recently, we'll talk about that more.

And Edward has actually done a lot of work,

starting with Liquid Fire, which is a pretty

awesome animation library if you

haven't used it yet.

Since he's been around the core team,

he's been doing a lot of RFCs, and

work in more general areas.

So thank you, welcome to all three of them.

TOM: Yeah. Give 'em a round of applause.

[applause]

TOM: So, since last year, hopefully many

of you were here. We've been really busy.

And we made a lot of promsies in that

keynote, so we're gonna do a little bit

of report card, if you will, and let you know

what we tried, and what worked last year.

So the first thing is rapid release.

Last EmberConf, I think we were on version 1.4.

So we had introduced this rapid release train

model of releasing new versions.

But we were only at version 4.

And I'm here to report,

I think you'll all agree with me.

That model has been amazing.

We are extremely happy with the results

of having a six-week release cycle,

so we can rapidly get new features

into your hands, and you can use them

as soon as possible.

It's also been great for us,

as maintainers, because it takes the pressure off.

We know that if the feature's not ready,

we don't have to rush to ship it

in a big-bang release, we can just sneak

it into the next train.

YEHUDA: And when we started to do this,

we basically had Chrome and Firefox as models,

but now you're starting to see other projects,

like the Rust project has recently announced

that they're also going to do this rapid release

project. So it's great that we were able to do

a little R&D, to see if this thing that works well

for browser engines could work outside

of the browser space. But it's worked really great.

And here's an example tweet,

there's tons of tweets like this,

of people who go from a pretty early version

and then jump directly through many versions.

Obviously we're in a dynamic language,

JavaScript, and you can do a lot of stuff,

so you know, you may have ended up doing

something using some private API

that wasn't expected,

or doing something we didn't expect.

But for the most part,

people have a really good time upgrading,

even though we've been releasing a huge

amount of releases. And that's, that's really,

we're very proud of that.

TOM: And if you're not doing it already,

I would really encourage you,

all your Ember apps at work,

or at home, subscribe to the beta channel.

When a new beta comes out, please

test it on your app and let us know

if it breaks anything. That's really

the only way we can know and we

really rely on that beta process,

and you filing any bugs, any regressions

that you run into.

YEHUDA: We effectively rely on people

complaining a lot during the beta process

so by the time it makes it to the release process

the bugs have been ironed out.

Specifically compatibility issues.

TOM: Please don't feel like a jerk

for complaining.

It's actually, it's not a bug, it's a feature.

And we couldn't do this without Robert Jackson.

Robert Jackson has been, [applause]

Robert has been the conductor

of the release train for a long time,

it makes me a little bit nervous,

if he gets hit by a bus we should

all pack it up and go home.

It's not going to be pretty.

So thank you very much Robert.

If any of you see him out, tonight,

or during the conference,

please feel free to get him a beer,

as suggested by getrwjblueabeer.com

YEHUDA: One thing we added to the rapid release

process, and this was something we actually got

from the Rust project, is adding a process

of RFCs. So we have the three Tomster bust,

and this is the "blueprint" Tomster bust,

that represents the RFC process.

But if you look, there's a couple dozen

RFCs now that were contributed by

people on the core team, also

community members. And this is the

point where people have an opportunity

to propose new ideas, and get some

feedback before people go to implement.

One thing that's really great about RFCs,

is that not everyone necessarily has

the chops to go in and do some

deep implementation work, but RFCs

are an opportunity for someone to give

a high level idea, and get really detailed

technical feedback on feasibility.

You can throw something out there and

get people who know the area to check

you and make sure it makes sense

before you go and do implementation work.

So this is a great addition to the process.

TOM: So, we talked a little about process.

Let's talk about some of the features that we've landed.

Probably the biggest one, the one

that was certainly the most hyped up

at EmberConf last year,

was HTMLBars.

So how did we do?

Well, we landed it.

It's out. The latest released version of Ember,

now contains HTMLBars. And we're very happy.

It took a little bit longer than we wanted it to take

admittedly, but we're very happy with

the results.

YEHUDA: So the first thing that it does,

just to remind you what HTMLBars

was about, since we, I think

announced it at the last EmberConf

and it took until now to release.

So, the biggest thing that this did

was remove this dreaded syntax

and replaces it with this.

So that's pretty great.

[applause]

And that feature, that particular feature,

lands in the 1.11 beta, so if you get

the beta channel right now, you can

go and change all of your bind-attrs

in your app. I've done that in my app

and it's very, very nice.

The next big feature, and this wasn't part of the

original idea for HTMLBars, but it sort of

came along with it as Handlebars itself

progressed. If you look at existing Ember,

you'll see that there's a few different ways

that in Ember you can have a block

that has some additional context

that gets used inside of it.

So we have "each item in list",

we have "with long.title as t",

and then we have components,

which don't really have any good way

of having the component provide anything

inside of the block that you're using.

And these three ended up feeling very similar,

in programming languages, these things

are just functions that take parameters.

What we've done is unify that into one API,

which is block parameters. [applause]

You can use the syntax today, it actually landed.

One thing to note is that these block params

for components, are not just something that is

magic inside of Ember. Any component can

just yield anything.

When you say "yield day" over there,

that just means that that becomes the

block parameter for the outer component.

Right, so this is very easy, it's trivial to use,

and it basically gives you the feature that

you need and it already landed in 1.10.

So this is very exciting.

The last thing that HTMLBars does in theory,

although this has not landed yet,

is it allows you to take components

that look like this,

and convert them into components

that look like this.

That actually exists in Canary, but there's

some details to work out about exactly,

precisely how this works.

But the HTMLBars engine enables the capability

of doing this, and that's something we're all very

excited about.

TOM: It's also allowed us to have a rendering

engine that's significantly faster than it was before,

And uses less memory.

So hopefully if you've upgraded to the newest

release that contains HTMLBars,

you should see better performance

across the board and reduced memory usage.

And you should expect to see us continue

to iterate on that performance and memory

benefits that HTMLBars gives us as we

proceed through the release cycle.

YEHUDA: The tl;dr is basically just,

rebuilding the rendering engine

from the bottom up gave us a lot

of headroom to make additional changes.

TOM: And then it turns out that having

an HTML parser is useful for a lot more

reasons than just implementing the rendering

engine. For one thing, it turns out

that I am a very bad programmer,

and I malform my HTML all the time.

Unfortunately, Good Guy Browser decides

that that's awesome, and just proceeds as

though nothing was wrong, and tries

to have my back. Unfortunately,

it's not really doing me a favor.

So one of my favourite features of HTMLBars,

is that at compile-time, we can tell you

that you have malformed HTML in your app

and give you a warning before you start debugging

weird errors in production.

YEHUDA: And actually, one thing to keep

in mind about our HTML engine-- parser,

is that it's a fully compliant HTML

parser. So any HTML that wasn't an error

in the first place, that you copied-and-pasted

in, you don't have to learn a new syntax

or anything, it basically just works,

but we've implemented a parser that's compliant.

And finally, this is a thing

that sucks. Maybe if you've only started

using Ember really recently, you haven't

experienced this, but we have basically killed

the metamorph tag.

[applause]

TOM: Gone baby gone.

YEHUDA: Now the next big feature that we did,

and I remember, we had already got the inspector

working at last year's EmberConf,

but we've made a huge amount of progress since then.

So, one thing that really stuck in my craw,

a lot was I would often be using the wrong version

of jQuery or something, and just not know.

And I would be like, it really feels like the

inspector could just put an info tab that

tells me all the things that's going on.

So we did that pretty early last year

And this is something that's extensible,

so any plugin, an addon, can basically

put additional stuff into this pane

to give you an idea of what versions are running.

So this is, small, but it's something

that I've spent a lot of time failing

due to not having in the past.

Second of all, the Ember Data pane

has gotten a lot better, and this is

just you can see we've gone to the

Nest website and we're just looking

at a product here.

Basically it works really well,

so, I don't really have anything else to

say on Ember Data, other than it works,

the inspector works great.

Also the promises pane, I think was

either not working last year or barely

working, and it's gotten a lot better

since last year. If you've ever had to

deal with debugging promises,

the fact that you can go in here and see all

the promises, which ones were rejected,

you can get stack traces.

All that stuff is pretty awesome,

given that you're dealing with

asynchronous stuff that inherently

is harder to debug.

And finally,

we also have a Render Performance tab,

Robin Ward contributed this.

And this basically will just show you

for any given rendering, what happened

and what took time. So you can drill down,

and say "okay, I can see that this little

area is a thing that took 100ms" and

go and optimize that area.

And we couldn't really cover everything,

but there's been a huge amount of inspector

improvements over the past year,

including things like Firefox support,

changing the UI, having a navbar

that tells you if Ember is running

on a particular page, that you can

turn on the options, these are all great.

The bookmarklet is actually maybe my favourite feature.

You can put the Ember Inspector as a bookmarklet,

into like Internet Explorer or something,

and have it work -- or Safari.

So, those are all great.

And I just want to thank @teddyzeenny,

who's really been,

who's actually at EmberConf

for the first time year.

[applause]

TOM: First time. If you see Teddy around,

please give him a big thank you. I don't

know if he drinks beer, but if he drinks

beer buy him a beer, if not, maybe like

a tea or something. He's poured in a ton

of work and I personally benefit from using

this tool every day, so big thanks to Teddy.

The other thing that's obviously huge,

and was actually just in it's infancy at

EmberConf last year,

is Ember CLI. Which is a little bit

crazy to think about, because it's become

such an integral part of the community's workflow.

And we won't get into too much detail here, but

there are so many great new features

that have been worked on over the last year.

It's been a huge theme of people working on it,

I think the biggest thing to come out

of Ember CLI obviously has been an addon

ecosystem. Ember itself was a very

opinionated framework about how you

should build and architect your web applications

but when it came time to actually build

those things for production, wire all

your assets together. I know many

of you in the audience have personally

spent weeks in meetings deciding

which tools to use.

Steve. [laughter]

So what's really great about having

a conventional structure, is that once as a community

we agree on that conventional structure,

we can start to build addons on top of it.

And there have been some awesome addons

released over the last year.

So if you want CSS pre-processing,

like Sass, or others,

if you want to deploy to hosting,

if you want to integrate real time

data updates. All of these things are

just a single install command away.

It was stuff that took half an hour

to an hour to set up before,

now you can do in seconds.

And I've noticed myself working on

more side projects on the weekends,

because before I'd be like

"well I don't really want to spend 6 hours

setting up Grunt, so maybe I'll just

go outside instead". [laughter]

But now, in literally 30 seconds,

I can have a new app up and running

and that is a tremendously liberating

thing.

YEHUDA: And even though we don't personally like

CoffeeScript in our own projects, the fact that it's

so easy to make a CoffeeScript addon and use

it in your own projects, is pretty nice also.

TOM: Yeah. The team has been doing amazing

work to make the addon system very flexible.

So really anything you could possibly want to

augment Ember CLI to do, it's possible.

You can add new generators, new blueprints,

you can shim in to add CLI commands,

you can add test outputs, so you can

add whatever test harness you want

if QUnit is not to your taste.

It's super flexible, but

super easy out of the box as well.

So we'd like to give a

big thank you to the Ember CLI team

unfortunately there's been way more

people working on it than we can

thank. [applause]

So the next thing I want to talk about

is just testing in general. So there was

a point in time when Ember had a

reputation as being hard to test,

or that it wasn't test-first.

And I'm happy to report that in 2015,

you can just (well we did this in 2014,

now it's 2015) at the end of 2014

now into 2015, I'm happy to report to you

today, that Ember has an awesome testing story.

Out of the box we have a really simple, expressive

API for doing asynchronous integration testing.

All of these helpers are built in,

you get them out of the box with Ember CLI.

Anyone, even if they're not an Ember developer

can drop in and pretty much understand what's

going on here. And they're instrumented

using promises under the hood.

So it handles asynchrony really elegantly.

And we also have a really awesome unit testing API

this is an example of a unit test for a component.

And again, very expressive.

Handles asynchrony in a very elegant way.

And we've got some awesome plans to improve

even more in 2015.

YEHUDA: There's not much to say here, except

that it sucked that in EmberConf 2014,

Query Params hadn't landed yet, and I

remember @machty gave a big talk about

why it was taking so long, and I'm glad

that it landed early in 2014 and we now

have Query Params support in Ember.

TOM: It still surprises me how easy it is,

I'm like, "man I really wish I could

persist the sorting of this list" and it's

literally one line of code and it works.

It's really amazing. Great job @machty.

YEHUDA: We also during the last year

changed all of our internals to use

JavaScript modules, and we also now

via Ember CLI, all new Ember apps

use JavaScript modules. We were actually

really early adopters of this.

We've been through a lot of changes in the syntax,

but we were also able to drive a lot of the process

of making the JavaScript module spec awesome.

So, that's great, and really I'm very thankful to the

community for having got hitched their wagon on

to my quixotic quest to get JavaScript modules

awesome in TC39 by helping to make it awesome.

So thank you very much.

YEHUDA: I can talk about Ember Data?

So Ember Data has actually been a thing

we knew we needed from the beginning,

we needed a data framework,

and it's actually gone through a number

of different iterations.

The most recent iteration has been a fairly

big rethink that took into consideration

all the things we learned over the past few years

and I would say that the number one thing

that was problematic about all the

previous versions of Ember Data

until this one was how exactly

relationships work.

Now one thing to keep in mind,

is that on the server, it's actually very easy,

because any time you want to get a

relationship, you can stop the world,

go to your database, get your

relationship, come back to it and

do whatever you need to do.

But in the browser of course,

any data could come in asynchronously

at any time, you could make any fetches

for any data asynchronously at any point.

I think that most people start with something like this,

they start with loading all their data at one time,

and they have a Post object and a few Comments,

and of course, if all your data gets loaded at the same time,

it's very easy to do this,

you basically just say

"post dot comments equals your array"

and then you set the post for each comment.

But very quickly, when people are building apps,

they don't load everything at once, they load

something first and they get relationships on demand.

So obviously you want to start

"post dot comments equals an empty array",

and then when you get your comments

you want to go and modify it so it has the right thing.

If you were doing this by hand,

you'd have to remember to do this when

you got the comments in.

Now what about what happens when you get

a few comments loaded first? Obviously,

you don't have a Post yet, so when the

Post comes in you want to be updating

the comments so they have the right thing,

so that seems easy enough,

but what happens if you get a comment later?

Now of course you want to make sure

that you update your post as well.

So the point is, the tl;dr of all this is,

data can come at any time and people

really do expect two-way relationships

to remain in sync. And this ended up

being a large quest that took multiple years

to get right, I think largely because we just

made mistakes through a few of

the iterations, and the last effort,

which was called the

"Single Source of Truth" or SSOT branch,

that landed in 2014, and I think

that's a good starting point for us

to make additional progress.

And just in general, one of the things

that came out of that was that we always

were really trying hard to have

relationship computed properties

in Ember Data be synchronous,

because we thought people would want that,

or, we thought people would feel like if they

loaded all their data at once, at first

it would feel bad for them to be asynchronous.

What we found over time was that it was

causing more confusion than help to

let relationships sometimes be synchronous

and sometimes asynchronous,

so in Ember Data, now, relationships

are pretty much always asynchronous

and that's something that we spent some

time recently on. And what that means

is that the relationship system in

Ember Data is built with async loading in mind,

where earlier on I think we were avoiding

forcing async loading into the model,

but I think it ended up being more confusing

than it helped.

And finally, one thing that really came out

of having Ember Data at all, is that

we've formed a pretty good adapter ecosystem,

so any general purpose server like

Firebase, or Parse, or CouchDB, or Rails,

people end up building adapters for it

that you can pretty much just drop in

and do a little bit of configuration if you

need to. And that ended up being pretty great,

because it means if you just want to use

Firebase, or Parse, or any of these things,

there's something that's built-in, and

it's not a totally different programming model,

it's not like "use the Parse API in Ember Data",

it's just like "use the regular Ember Data

API and the adapter will handle it behind the scenes".

So, Tom and I have been busy with Ember,

Igor basically took over the reins of

Ember Data after we moved on to Ember

to work on Ember more aggressively,

and Igor's basically been doing the heavy lifting

there for a year or more,

so thank you very much Igor. [applause]

And finally, just in general,

I touched on this a little earlier,

But we've really been an early adopter

of ES6 features, things like promises and modules,

and that has really filtered back into the

standards process. Obviously,

ES6 you may have heard is now called ES2015,

but I think the point is that we plan to

continue being an early adopter of features

in the future, so we plan to be an early adopter

of ES2016 features and 2017 features, obviously

to the extent we think that they're stable and

pretty much landed, and the standards process

has really improved to make that something that you

can feel careful about, so we're going to keep doing that.

TOM: So that's what happened last year,

and I think you'll agree we made a lot of

pretty crazy promises, and we've largely delivered on them.

Almost everything that we said was going

to be coming in the year has come,

so hopefully at this point we have a

track record of shipping, maybe off by a couple months,

but the point is, we shipped.

And I think you should rest assured,

that the stuff we talk to you about next,

we are going to ship, and it's going

to be in your hands for you to use over the next year.

So what's next for Ember in 2015?

Well, the first one is I'm very happy to announce

that we're switching to a versioned guide system.

So going forward, (yeah!) the guides will be versioned.

And a big thank you, @trek and Brian Clifton

have been working their tushes off getting

this feature ready. So this is live today.

If you go to guides.emberjs.com, you'll see

it redirect you. Here's a lovely screenshot.

And, here's a link you can type into the address

bar of your browser.

YEHUDA: Turns out that URLs are a good idea.

TOM: As it turns out.

So we're very excited about this, because it

will give us the freedom to update more rapidly

update the guides without feeling like we may

be leaving people on older versions behind

if they happen to be stuck on an older version.

And, even more importantly,

and the thing I'm most excited about,

is that we ae bringing all the guides

up to date to use Ember CLI semantics.

So the happy path using Ember, out of the box,

is going to be using Ember CLI.

You won't have to have someone tweeting at you

three weeks after you start using Ember,

being like "why are you not using Ember CLI?

You should just use it", and you're like,

"well maybe you should mention that on the website!"

Hmm.

YEHUDA: Now that you mention it.

TOM: Good point.

So, as of last night, many of you

I thought you would all be out at the bars,

but many of you were at home

compulsively refreshing the Ember.js website.

[laughter]

You've noticed that we've removed the

Starter Package, the Starter Kit,

and now we just instruct people to use

Ember CLi, the next version, all the guides

are going to be updated to use ES6 modules,

and Ember CLI. It should be really awesome.

YEHUDA: Now the next big feature,

this is something that is still in the RFC process,

Tom and I wrote this RFC several months ago,

but this is basically just the ability to

take a piece of an application in a big team

and have it be fully encapsulated with namespaces

and everything, so that if you have a company

with a number of teams on it

and you have teams working on one piece,

teams working on another piece,

people have worked out how to make this work

in sort of ad-hoc ways, and this feature is about

making an official way to do that in a reliable way.

This is something that companies that end up

adopting Ember and have a lot of teams

have asked us a lot, pretty much any time

we ever do any consulting at a company of that size

it's like the number one feature request.

So I'm excited that this will be landing as

soon as it gets through the RFC process.