So let's start with the drama, would you say Ember has declared war on native apps? [laughs]
[sigh] Yeah. Yeah, I think that's fair. Yeah. Sure. Why not? Let's go with that.
A lot of other frameworks, take this approach of bringing web technologies and dropping them into native experiences - React Native being the prime example. It seems that Ember wants to bring back the glory days for web technologies - is that right?
Yeah, absolutely. I don't have anything personal against native apps. I use a lot of them, and I think that there are a lot of situations where native apps provide a better experience. And I don't care at all about what technology you use. I care about the user experience.
I think there's this false accounting that people do. It's like how in the 50s and 60s no one ever got fired for buying IBM. And that's where we are today. No one ever gets fired for building a native app. And that means that people take the thinking out of the equation and say, "what is everyone else doing?" And everyone else has a native app, everyone else puts up an interstitial that tries to push you to the App Store, and they don't focus on the user experience.
Do you think some experiences make more sense in native than in web tech?
I think there's always going to be APIs that roll out to native first, and if you're writing a game, I think that's fine, if you need access to the hardware I think writing a native app makes a lot of sense.
But I don't think there's a reason that Pinterest needs to be a native app. I don't think that Facebook needs to be a native app. It's not taking advantage of anything you can't do on the web.
What are the fundamentals? What do we need to do in Ember to create a great mobile experience?
And so the question is: how do you bend this curve, this tradeoff you have to make? For us, that means thinking smart about breaking your application up into pieces and streaming it, effectively. And actually, Ember's pretty well set up to do that because we have a very conventional app structure that's focused on the routes in your application. We already break your application up into pages, and so it's pretty easy for us to figure out, ok well how do we break that up into pieces and only give the user what they need to see that particular page?
AppCache is the best example. People think of AppCache as a deprecated technology, and I'm not surprised, because you go on the MDN website, and there's big scary warnings — "THIS IS DEPRECATED AND WILL BE REMOVED."
But both Chrome and Firefox have officially said they're deprecating it.
They've officially stated that they've deprecated it, but if you look at it, it has incredible feature penetration, it's in far more browsers than service worker or ES6 or any of these things. ServiceWorker is obviously the future, but it's not well distributed yet. And AppCache is in something like 90% of browsers globally. In my opinion, AppCache is a little bit hard to work with — there are rough edges, it's not a perfect API. There's no question about that. But it exists, it's in the browser.
And I think there was this era, this feeling of scrappiness, in the JQuery era, the IE6 era, where you had to know all these hacks just to put a
div in the right place on the screen. And people spent hours and hours and days and days figuring out hacks to make it happen. And I think we need that spirit of scrappiness again and say, "yeah, this API sucks, but let's build tools to make it pleasant just like JQuery did."
There's no excuse if your app boots in more than 200ms, on second boot. You can put all those assets in the browser's cache, and there's no reason you should download those again if the user's been to your page before.
Well, it's always been one of the hard computer science problems —
Yeah, what is it? Caching and concurrency?
Caching and naming things [laughs].
And that's why AppCache exists. And again, yeah, it has rough edges, but I think that what we can do in the Ember community is write a bunch of tools so that you as a developer don't have to learn all those edge cases. We'll just say, write your application the Ember way, and we'll give you all the advantages of AppCache out of the box.
So the Ember FastBoot website is itself an Ember FastBoot app. It's an Ember app, running FastBoot, on Heroku, that's been awesome. We've worked closely with Terence; he was up late the night before the keynote making sure it was out and fast, and I have to say I'm incredibly impressed. It was on the front page of HackerNews for the entire day, which usually amounts to one hundred-some thousand hits, and it was just so fast the entire time.
Actually we've gotten tweets about how fast it is.
So it's really important to be fast — especially when you put fast in the name of the product.
Yeah, it would be embarrassing if —
If it was SlowBoot?
Yeah, actually — so Dockyard, which is a consultancy that does a lot of Ember projects, they just recently moved their homepage to FastBoot. And I asked them if they could do a non-FastBoot version of it that I could just compare against.
So how slow is it? Does it feel slow?
Do you think, are there other things about a FastBoot application that developers should consider when adopting? Are there other reasons to adopt FastBoot?
SEO is a big one. Another reason that not a lot of people think about is Facebook Open Graph tags and Twitter Cards — because you can add these annotations to your HTML, and Facebook and Twitter use these to create a much nicer experience when someone pastes your URL into a share box or whatever. And that requires server rendering and adding these, so that's been one really key thing.
In terms of adopting FastBoot and the migration story, I think the consensus today is FastBoot is new, you should start experimenting with it. When is it going to be something people can use in production apps?
Well, I'm personally rolling out to production very soon, and already have in several client projects I'm working on, but it is pre-1.0 software. We're going to release 1.0 along with Ember 2.7. I think we're in 2.5 now, and we do six-week release cycles, so in probably about 12 weeks roughly.
I was not expecting such a concrete date [laughs]
And the thing is that we've been working on it for the last year, and it ended up being a much harder problem than I thought, but I think we're very close, we've cracked a lot of very important nuts. The most important thing to think about when you're trying to migrate to FastBoot and adopt it is that you really have to realize is that you're now writing an application that's no longer running in just the browser. You're writing an application that has to run in Node as well, and so you have to use the unified subset between those two. There's a Node environment and a browser environment and they don't have the same things.
The DOM, for example.
The DOM is the big one, right. And actually, it ends up being OK. That sounds like it may be a fatal restriction, but in practice, Ember apps are very well-structured, and most things are within specific lifecycle hooks. On a component for example, if you write a component, a lot of the behavior you have that relies on the DOM existing is inside this hook called
didInsertElement. And so what we do in FastBoot, we just don't call it. We render your app; we render your templates, and if there's anything you do when you touch the DOM, we just don't do it.
It forces you into some best practices too.
I would say that. It definitely requires you to clean up your app. And because FastBoot apps run concurrently, you have to make sure you don't have any shared global state. And so that might be a problem if you have a messy app, but in general, it helps you justify putting in a bit of effort to clean it up.
We've almost convinced the rest of the world that that's important on the server too. We're getting there very slowly at Heroku.
Do you think that this duality is going to hurt adoption? A lot of times when you're shipping stuff to production, you take a lot of shortcuts, so more often than not a lot of these things are in many Ember apps today.
I've migrated a few really large apps, and in practice, it's maybe a couple of weeks of work for big apps that have been around for a few years. There's no question about that. I think the benefits are worth it.
To listen to the rest of their conversation, download the whole interview here, and jump to the 14:30 mark.