Last week, Terence Lee and I caught up with Tom Dale at EmberConf to talk about FastBoot, when you should avoid native apps, and why JavaScript on the server and the browser might start to converge. Check the end for the full recording!
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.
So the thing we tried to show in the keynote is that apps are great once they're on the phone, but if you're tapping a link on Twitter or a Google search and it takes you to the App Store, and you have to wait a minute or more? Native applications are 80 megabytes - Facebook's like 80 megabytes - and everyone's complaining about JavaScript apps being 500k.
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?
So this is the tricky thing, right? You're fighting a two-front war as a mobile developer. You have all the native people who say you have to write - you need to offer an experience for the web that's competitive with us native developers - and you have old school web people saying you need to load as fast as us if you want to have a good web experience. So you're caught in the crossfire. No matter what you do, someone's going to criticize you. You either have too much JavaScript, or you don't have enough features.
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?
Things like FastBoot mean we can keep your application in memory on Heroku or whatever host you're using, and you can serve it up very fast. And that's a way of outsourcing the JavaScript runtime to Heroku until the JavaScript finishes loading on the client, and I think the last thing is taking advantage of features that we have forgotten about, or have gotten a bad reputation.
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.
Yeah, we've just never done caching very well. The whole JavaScript community has been allergic to caching for some reason —
Well, it's always been one of the hard computer science problems —
Yeah, what is it? Caching and concurrency?
Caching and naming things [laughs].
Here's the bottom line — HTTP caching, which is what most people think about when you think about caching for their JavaScript applications, is from an era where most things were rendered on the server. HTTP caching is just not appropriate when you're adopting a client-side architecture.
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 you mentioned FastBoot. Terence has been working hard to make the FastBoot experience with the new open-source Heroku buildpack amazing. And you used that to deploy ember-fastboot.com.
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.
It's pretty mind-bending — you're used to having this tradeoff on the web. A page is fast, but because it's rendered on the server to load, each navigation you have to keep talking to the server. But the FastBoot website is different. You hit it, you get HTML, but the JavaScript loads in the background. So each click after that is not having to talk to the server, it's rendered in your browser, your local machine.
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?
On a modern device, on broadband, it's imperceptible for the most part, but when you notice it is if you're on a slower connection, like a 2G or 3G connection. That's where things like FastBoot matter. And of course, not all devices have JavaScript, not all crawlers have JavaScript, and you might be on a mobile device, and maybe your connection drops and the JavaScript doesn't load - it's still nice to see the content.
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.
But the other thing I'll say about that is - Node, when it started, was just some people taking V8 and binding it to their environment that they created to bind into Unix system calls. V8 plus Unix. But what you're seeing happening is that people are starting to take Node on the server a lot more seriously, and more importantly, the process of developing JavaScript as a language is becoming more open, and there's far more contributors to it now. It used to be mostly browser vendors, but now you have practitioners, people from Node who are on TC39. I think what you're going to start seeing, because there's so much interest in running the same code on the browser and the server, is that those environments are going to become a lot more unified than before. So a lot of the gotchas that might exist today as Node evolves and JavaScript evolves, and the browser evolves, I think that the difference between those environments is slowly going to converge.
To listen to the rest of their conversation, download the whole interview here, and jump to the 14:30 mark.