Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm your host Jen Simmons and this is episode 78. Today we're going to talk about offline technologies, which is a subject that I actually, like, I have been super excited about these, there's several different ones, and we'll get into it. But this is what kind of made me want to do this podcast in the first place. Offline is what I talked about with Peter Lubbers on the very first episode of The Web Ahead. We talked about HTML5 in general but also we focused a lot on local storage, offline cache, app cache, IndexedDB, stuff like that. That was almost three years ago, we're like two months short of three years ago. So I have a new guest today to come and talk about offline and give us an update of, of course explain everything from the beginning again in a way that will be different than last time, so if you missed the other show don't worry about it. I don't remember what we actually talked about specifically anyway. [Laughs] So we'll start over and talk about the current state of offline with our totally fabulous guest, John Allsopp. Hello John.

John

Hey Jen. Totally fabulous. I'll do my best. I'll do my best to be totally fabulous.

Jen

Nice. Well if people don't know who you are, you're the guy who wrote A Dao of Web Design.

John

Yeah, that's right, that's my albatross. [Both laugh] No, no, that's my meal ticket, that's why people still talk about me. That's right. Back in the year 2000.

Jen

And you were on The Web Ahead before. Episode... oh, I'll have to go look it up... I closed the window. With Eric Meyer. It was the very first Web Behind, number 35.

John

That's right.

Jen

Episode 35, where you came on the show and with Eric, talked about your fabulous career and all the many, many, many things that you've done.

John

I did. So if people want to follow up, they can go to that. But also what we talked a lot about was, in the Web Behind, well-named, was the sort of history of the web. Which is something that very much interests me. Since I like to look back and I like to look forward, like Janice. So it's great to be looking forward today. Not that I mind looking back but today it's great to be looking forward.

Jen

Well, and I think one of the overarching themes of the show and absolutely what you were writing about 14 years ago and what I'm sure you still constantly think about is sort of getting at the very nature of this medium and what it was, what we used to think it was, what it is, what it's about to be. I feel like offline fits into that. That's why I got so excited when I first learned about these technologies. Because I feel like it changes... they change what the web can be, in a way that's pretty different than what we've thought it was 10 years ago. I think. In my opinion. But what's odd to me is I don't actually see very many websites using these technologies even though they're completely ready to go and they have been for many years. So maybe you can start by talking about, ok, what is this stuff, offline... yeah, let's just start there.

John

Yeah. So first to your point, I absolutely agree, I think these technologies as they emerge over time, they change what's possible with the web. But in many ways, too, I feel like they kind of tap into the underlying kind of webby-ness of this thing that we're building. They amplify what we already have. So I like to see how they fall back in to what the web is. At the moment, in the last two or three years in particular I guess, there's been a lot of, dare I say, hand-wringing about the web's place in a sort of app world. Can the web compete with native? And really that sort of binary web-versus-native, to me, really echoes the kind of web-versus-print sort of philosophies and discussions that we were having in the late 1990s. So for those who weren't around at that time, many people criticized the web for having all these shortcomings because it wasn't like what we had in print. And some of those things were entirely valid. For example, we didn't have access to a ton of fonts. Typography was very limited. A lot of these things were very limited. But at the same time, there were a lot of things that were possible with the web that pretty obviously print didn't allow at all. The sort of fluid nature of the web that could adapt to the user's needs, whether that was the screen that we were using, whether that was the fact that their eyesight wasn't as good. Ironically, in the 14 years since I wrote that, my eyesight has got considerably worse, so at the time, you know, that was all theoretical. Now it's very practical. So I like to think of these technologies as they emerge and as we get to play with them, I like to think how do they help shape what the web can be? A lot of people, they put, "Oh, we need this technology to compete with this platform." To me, I don't look at it like that. I feel like we need these technologies to help move the web forward as the web. Not as a competitor with iOS or with Android or with whatever other platform. Because it competed with print many years ago and then it competed with desktop, you know, it wasn't as good as Windows, and now we see it... it's always competing with something, in the way a lot of people look at it. But in my mind, really what I'm interested in is discovering what it is, rather than what it competes with.

Jen

Right.

John

So, to your question, unless we want to change the question, what are these technologies right now? What should we start with in the practical sense?

Jen

So, yeah, talk about what... so we're talking about these three... we're talking about app cache, local storage and...

John

IndexedDB, which I guess is a sort of local storage on steroids in some respects. But also I include a couple of other things. There's the file API, which allows us to do some reasonably cool stuff. And there are some ways, and I think this is the important part of the process, ways of understanding whether or not the user is online right now. In a coming sense, or in a coming technology, how well-connected they are. That's something that's currently in Firefox, it's sort in a very early stage specification. The idea is that basically you can ask for the user's bandwidth and then maybe stream different content to them based on their bandwidth. Which is something that adaptive streaming technologies have been able to do on the server for the long time. But this is something we'll increasingly be able to do on the client. So there's a whole range of technologies that we can use to make a better experience for our users. That's the starting point for me. What can you do with these things to make your user's experience better?

Jen

Yes. Yes. File API, by the way, episode 14, Arun Ranganathan came on and talked about it in depth.

John

Nice. Alright, that's good. That's something that often gets a bit overlooked. And even those cool things like gives us access to the user's camera. In conjunction with the media capture stuff in HTML5, we can get images and video from the user's camera on some devices, particularly mobile, iOS and Android devices.

Jen

So will you do a quick catch-up for people who haven't heard some of these other episodes and just explain: What is app cache? What is local storage?

John

Sure. Ok. So let's start I guess with app cache or the HTML5 application cache. Which is a way of telling the browser what resources that you want to be stored locally. So when it hits a website, in your website you have a thing called a manifest, which lists all the resources that you want the browser to store locally and just use locally. They could be images, they could be JavaScripts, they could even be HTML blocks. It also lists resources that you don't want the browser to ever cache, right? They might be API calls, they might be very fast changing resources that you just don't want the browser to cache but to always refresh from the server. And it also allows you to provide some fallbacks for when a user's offline. That image hasn't been cached, do I have a fallback for that? In a nutshell, essentially what it allows you to do is to build a website or web application that once a user has visited it, they don't need to be connected to the web to use that the next time they want to use it, right? So if you want to make an entirely offline web application using it, you can. And this works particularly well in iOS and Android and tablet and mobile platforms. Because those users are sort of less likely to have this sort of constant always on, always good connection. But it also has a benefit, even if you feel like, "That's not really a use case that's common for my users." It actually helps your performance quite a lot. Because you essentially can take things like fonts, JavaScript, resources that don't change much, if at all, you know, images. And once they've been downloaded once by the browser, they just don't have to get downloaded. So the next time or any time the user revisits your website, they essentially, all these resources can be taken from the local cache and the page speed increases dramatically. It also has the benefit, and this is something when we talk about offline, I think we often think, "That's about the client being offline, that's about a browser not being connected." But remember, servers go offline, too. They go offline because something really bad happens at Amazon Web Services, by way of example, and many other places or your own host. They go offline because they've been slammed with a ton of traffic and they just can't keep up with the requests. There's a whole lot of reasons why servers go offline. So you can move more and more of the logic and the heavy lifting into the client, you don't only get the benefits when the client's not connected, you get the benefits when the server is less well-connected or not connected at all. So that's what application cache is about.

The next one that's very commonly used is web storage. And there are two facets to this which are very similar. There's local storage and session storage. And what they allow you to do is very simply store data in the browser to be reused. If a user's taking photos, for example, you could potentially keep them locally and then you might synchronize with the server at some other stage, either when the user is reconnected or even if they are connected, at some part of the process where it makes sense. There are all sorts of use cases for it. The more you think about the value or storing things locally, the better you can create your user's experience. In a sense it replaces cookies, which we've had around for a very long time. The challenge with cookies are they're not designed for this. They're always passed to the server. They're incredibly insecure because everything's passed to the server in the plain. So unless your application does all the encryption and protection, whatever's been stored in the cookie gets sent over the wire without any encryption at all. So the role here is to sort of replace cookies and replace the need to talk to the server really so much.

Jen

I feel like, especially thinking about app cache and web storage, that the original conception behind these two technologies and the way that they would work together, is that you're building the next most awesome word processing piece of software and you want it to be a website that people go to to write. But they're not always online. So you want them to be able to open up that application, the way they might open up Microsoft Word or whatever other text editor that they use. And they open it up in a web browser and they can access it directly from their own local computer, where, like, who cares how fast the internet connection is or whether or not it exists. And then as a person is writing the content that they are writing is saved in their browser, hidden away, and they're not online, blah blah blah, then later they get online and things can be synced back up. Maybe they're using their CMS and their CMS is set up this way and they don't need to be online, they can add content and then later it gets synced back up.

John

Yeah, that's a really sort of common use case, I guess. Certainly how it was conceived. But what's interesting is it brings all of these benefits even if that's far more complicated and sophisticated than what you're trying to do. That's the cool thing. You don't have to be building this very sophisticated, fully blown web application in order to get benefits from these technologies. But yeah, that's what they were, kind of, I think originally conceived of as being for.

Jen

Yeah, and I think that's part of what sort of surprises me. That even now, three, four, five years in, maybe not five, but several years in, I don't see these technologies being used more. Because I...

John

I blame Jake Archibald. [Laughs] So Jake wrote this thing called — am I allowed to use French?

Jen

Yeah.

John

It was in A List Apart a couple years back. He said, Application Cache is a Douchebag. It's kind of a lighthearted critique of the app cache. The truth is that app cache is a pain. My analogy of the app cache is it's more like Mr. Logic, which is an old cartoon character from the Vix cartoons, which some people are familiar with. But Mr. Logic is that guy who will do exactly what you say, exactly as he thinks you mean it, right? So as long as you understand what he understands about what you just said, he will do it. So the thing about app cache is, I think when people first start with it... see, logic and intuition are not the same things. And often what app cache does and how it does it is unintuitive, but it is logical. So to my mind, what people do, is they start playing with it, and they get something that should work, because from their understanding of app cache, and it doesn't, and they bang their head on the desk, and there's no, not necessarily great resources to say, kind of walk this back and get it right, and people give up. And I think this is really common. That's actually one of the reasons why I run workshops. I'm doing one is Nashville in a couple weeks. I have a book that's coming out very soon and I write a lot of articles and I talk about this a lot. Because the truth is, I think, if you spend a couple of hours really getting your head around it, it actually works really well but it's that upfront investment where unless you sort of get your head around some of the gotchas and some of the things that don't work as you might think they should, and as they probably should, to tell the truth, you're going to run into these roadblocks. It's going to seem completely counterintuitive. You're going to assume you're doing something wrong and it's not working and go away. So I'm sort of trying to hopefully break that and get people to adopt it.

Jen

Yeah. Because I do think that, of course, the kind of thing I described — that you're making a web application — is a classic, easy to understand reason to use these technologies. But I somehow, I didn't get excited by them because I want to run around and build web applications. I feel like there's so many more things that they can be used for. Like you said, performance, where you can get a head start on getting things downloaded. Where because the way app cache works, it downloads the resources that you would normally download for the very first time when you hit a page. So when you hit the homepage it automatically starts downloading all of stuff it needs to render that homepage. Just like always. And then it looks at the app cache, I think this is vaguely technically correct, and it starts downloading the other stuff. So you could sort of pre-fetch and pre-download pages that a user hasn't even gotten to yet.

John

Absolutely. Yep. That's a case that I think a lot of people don't have in mind. And there's a lot of excitement because there's some... in Chrome, there's some pre-fetch attributes and in HTML. But in fact, you can essentially... let's imagine your site architecture is you have six major sections of your site. So when people come to your, say, the homepage, or any of those major pages, the way the user generally moves through that site will probably be to go to one of the Products, Services, Pricing, whatever, by way of example. So what, as exactly right, as you can say, you can actually pre-fetch those pages so that when the user says, "I'm on the homepage but I want to see the pricing." Click, bam. It will be instantaneous.

Jen

Really fast! [Laughs]

John

Really fast. It's coming out of your local hard drive.

Jen

I mean, everybody's trying to shave milliseconds off of the download time and to eliminate requests to make downloads faster and there's all this conversation about every little millisecond. It's like, what if you got it down to zero milliseconds? [Laughs]

John

Right, exactly.

Jen

There's no faster than zero.

John

Exactly right. The thing is, we've had HTTP caching since forever, right? And actually I've got in this book I've written, I've actually got a short chapter on HTTP caching because it's still of value to some extent. And it works in a strange way with HTML5 application cache. We've sort of been able to do this for years but I think for various reasons, one of them... well, there's a few... one of them is that often we poor, benighted front-end developers aren't allowed to touch the server, right? It involves setting up how HTTP works and htaccess on Apache or whatever you're using, right? Some of these things have kind of been possible for a long, long, long, long time in HTTP but most front-end devs have kind of no idea about HTTP cache. So. Yeah. I absolutely agree We agonize over... we have whole conferences, and very good ones, like Velocity, all about performance. And yet, we've got this thing that is essentially like a bazooka for performance. [Jen laughs] It can blow... ok, so like any bazooka, you want to use it with some caution, right? And there are. Because, you know, all caching is essentially about between freshness of resource and time to download. It's a tradeoff, right? And it's a dangerous tradeoff, because you get it wrong either way and you either have massively slower performance or you have really old resources that aren't refreshed. I guess partly people worry that if they get it wrong, they'll have users stuck on older versions of their website. Because that actually, ironically, can happen with the app cache. Or they're not really getting benefits out of it, so why go to all this extra effort? But the truth is, really the truth is, I spend typically about 90 minutes in my all-day workshop, but it's not an ad by the way. [Laughs] I spend about 90 minutes on app cache, right? By the end of that, we've covered all the major gotchas. People are aware of them. People are able to build something that really works offline. It's a relatively short timeframe to invest. So I would say, if you're working by yourself, it's half a day investment to really get your head around it and start reaping the rewards. And the truth is, I think in our field, a lot of us, we're not even willing to invest half a day. We want these kind of very easy, short gratification, "I learned this thing in 20 minutes and now I can animate my webpage," right? We want this real low-hanging fruit. Sometimes I think it's really worth investing a little bit more energy. I think in this case it is, because you get a tremendous reward for doing it.

Jen

I feel like in a way it's a bit of a... it's just so unexpected. That you can even do this. That people... I wonder if people are kind of not... it just doesn't come up. Especially since a lot of decisions get made on the stakeholder level or on the designer level and strategy meetings and in things ahead of time. I feel like part of what is so exciting to me about these technologies is that it opens up a whole new class of things that are possible and other ways to approach what a website is and how a website works for the users that use it. That's what I'm not seeing, is sort of, like, groundbreaking new world-defining uses of this stuff. As I've done presentations about this, one of the examples that I give, because everybody is already at a conference and they're frustrated with internet, they're in the conference venue and the internet keeps going down or it's just very, very, very slow. And they leave and go back to their hotel where the internet is down or very, very slow and they keep wanting to pull up the schedule for the conference over and over and over again. The schedule's not changing, right? So if that website had app cache on it, then it'd be like everybody downloaded that conference content, the whole schedule, into their browser. You see conferences doing things like creating an iOS or Android app and putting it in the store so that people have, basically, the only benefit that they are using is, you can already have it all downloaded and it's all saved up inside your phone and it's not going to go anywhere. But you can totally do that with a website.

John

Absolutely. One little fun story. I ran the workshop down in Melbourne a couple of months ago. We had a group of people, a lot of them are very, very experienced. Some of whom, like, what are you doing in my workshop? I don't want you here, you're far too scary. What I would get them to do is, they'd fire up their localhost, so they're running something off localhost, a website, right? We'd build something, we add an application cache for it. During the day we build kind of an Instagram app style thing, so you can take photos and it's all offline, it all works. Yes, people, you can do all that in the browser. And then I say to them, "Ok, just kill your local server," right? Just kill it. Just kill that process and reload the page. And literally you can hear people gasp. [Jen laughs] Because they just don't believe it. They just don't believe that it's... "Hey, it's still doing everything," right? It's seriously, I think actually, it's so magical that unless you see it, your brain isn't willing to accept it. Your brain is not willing to accept. Because, look, for 20 years now, the web has required a constant, always-on connection to work. It's so deeply now, personal feeling about what the web needs. It's like someone breathing under water. Imagine if you just one day, someone jumped in and said, "Hey, take this tablet, you can breathe under water." You'd be reluctant to believe them. Look, I kind of see it on that part. It's suddenly as aspect of the web that, in many respects, has been one of its limitations, which is you just need a connection to make it work. It's not there anymore. And really, it's truly magical, right? And I agree with you. So the first thing is to get people to understand, this is possible. And then to get them thinking beyond that. "What can it make me do? What can it let me do with the web that's new and different?" But I think first and foremost, we just have to get enough people to appreciate that it works and even just using it in very simple terms to improve the performance of their sites. Even if it's not about working offline. You run up against all of these edge cases. I don't want people to sign up for my service, by way of example, when they're not connected. So, you know, there are some edge cases you have to start thinking about. What happens with this particular functionality? What's going to happen? And then you do have the challenge of synchronizing anything saved locally with the server. But there's some great stuff. One I really like is Hoodie">http://hood.ie/">Hoodie. So the guys at Hoodie who've kind of got this offline-first manifesto, have got a framework that works in the front end and the back end to basically make that almost no effort. There's things like PouchDB which is a client and server side database that basically takes away a lot of the heavy lifting of that synchronization. So there's sorts of things we saw recently at WWDC with iCloud and how awesome if you're an iOS developer to synchronize data between your iOS app and on the server, provided you're using Apple's services, yada yada yada. It's already there on the web. In a way the web's a whole generation ahead of native apps in terms of some of this stuff. It's just that we're not taking advantage of it enough. It really, I guess, in some ways it feels a bit like that late 90s period where we had to evangelize CSS and evangelize the benefits of modern standards-based development. To me it's kind of like, and one of the reasons why I've kind of focused on this so much, it almost feels like the same challenge, to get people to see that it's possible and then to see, not only is it possible, it's awesome. CSS wasn't just a better way of doing fonts and tables. It was that but it was also a whole lot of other things that weren't possible. So first we have to get people to see, it's better than before, and then we see, but it's also different. So there's two parts to this process and I think we're still very much at that, "Hey, this is possible, and it's better."

Jen

Well, and the other use case that I got really excited about is long form content, like a book. I think I've talked about this before. I worked on a project with Apres for most of, what was that? 2012 maybe? Yeah. 2012, 2013. And later a bit with Springer and with O'Reilly. This idea being, you know, let's make the eBook much, much better. EBook technology is sort of stuck in a whole lack of standardization, corporate interests are taking over, kind of weird space. It's web technology, CSS and HTML, especially EPUB 3. But the web is so far ahead. So so very far ahead of where EPUB is. So why not leapfrog over EPUB, push it out of the way, and build a book completely with web technology? But then it became this thing of like, ok, well, if we build this book completely with web technology... and look, it's awesome because you have this code editor and you can have running code examples inside the browser and this will be great. You can have animation, you can have video, you can have all these things that don't really work in EPUB or don't work at all. But then, ok, what's the reader? What's the software? Which app do people launch? And on the one hand, you could wrap it up in a web UI view and just sell it as an app. You can't put it in eBook readers because they don't understand it. Or you could just leave it on the web and put it as a website on a URL. But then, you know, you get into this whole thing about, what's the difference between opening up iBooks app or Kindle app versus opening up a web browser? A big part of it is, well, you want to be able to open that up on the plane or at the beach or without an internet connection. You don't want to download, download, download. And so we used app cache for this and we used a little bit of local storage as well to capture some settings and things. Then this little prototype got launched and one of the number one comments that we got back was, "Well, I want to save this. Can I save it? This is awesome, I want to save this. How do I download it?" [Laughs] And we just kept responding with, "It's already saved. It's already downloaded."

John

Maybe that's where you add a "save" button. Maybe that's where you actually add redundant functionality.

Jen

Or a notice.

John

Google Docs has a save button, right? Even though you don't need to save anything. [Both laugh] Sometimes I think... look, I absolutely agree. We're talking about the web ahead. There's a lot of pessimism about the web right now and the web's going to be beaten by this, that and the other, right? You know what? I'm old enough to have heard that since about 1990, right? And to be quite honest, I talk a little bit about this in one of my presentations. There's a fantastic critique of the web. A lot of people don't know — web's obviously hypertext — and there was this big conference called Hypertext, which is like... and hypertext was this really hot thing in the late 80s and early 90s. Really before the web took off, right? So Hypertext was like the big conference for hypertext, researchers and also the industry. So Tim Berners-Lee proposed a paper on WWW for Hypertext '91 and it was rejected. So even at the very beginning, people thought the web had too many limitations, it wasn't good enough. Like it's been a running, almost now a joke about the web. And look, past performance is no predictor of future performance in some respects. But I do think it's a guideline that every time people talk about how... and this has happened three or four times over the last 20 years. The three or four generations of the web is going to die because of AOL or because of iOS or because of MSN or some other three-letter acronym. And the truth is, it hasn't happened. My prediction's the opposite. I think Chromebook, that Chrome OS concept, and Firefox OS and web OS before it, that's going to happen. You know, like, apps. Apps are kind of pointless. I'll get in a lot of trouble with this. They're kind of like the save button on Google Docs. They're there because people can't imagine what it would be like without an app. Because computing has equaled apps since the dawn of the PC era, right? The PC has been driven by the concept of an executable application, right? And funnily enough, the Lisa operating system — which most people sort of think as a precursor to the Mac, if they know about it at all — it was a product that Apple came out with almost in parallel with Mac. Lisa has a document-oriented approach, where you didn't open apps, you opened documents. And it had compound documents back in 1983. So the idea that we had that computing is application-centric, that's not how humans work. We're not tool-centric. Tools are things that we use to achieve an outcome. But when it comes to computing, the tool has become our focus. In my mind, in a way, the web will over time liberate us from a very tool-centric approach to computing. And I think Scott Jenson probably talks about this better than most people. Scott, who's now at Google ironically, why I say "ironically", because I guess Google have invested hugely in things like Android but at the same time invested significantly in the browser and in Chrome OS. So they kind of have, I guess, a foot in both camps. Scott, if you just look up what he's written about in terms of... he calls applications a kind of local maximum. They're something that sort of helped solve a problem at a time and they're now getting in our way. I totally agree with that, I've written about that a great deal. To my mind, these technologies in particular, these offline technologies, are really taking us toward a place where, as you say in that great example about eBooks. We don't need an app. One day certain people are going to, like, load, "There's an eBook, it's in a URL and I'm just going to go back to it," and they're going to increasingly stop worrying about whether they're connected or not. To the point where if you're not building something that works whether someone's connected or not, maybe not entirely, and obviously it doesn't make sense in every case, but if you're not making something that basically just gives people a lot of their functionality even when they're not connected, they're going to think you're broken, right? They're not going to think, "Oh, I'm not connected," they're going to think, "This is broken. This thing that I'm visiting, this website, is broken because it's not working right now." I think bandwidth, ironically, and those issues are going to increasingly diminish in terms of us thinking that we need them. For a long time we thought we're just going to have Wi-Fi at 30,000 feet and we're going to have Wi-Fi in the subway and we're going to have Wi-Fi in, you know, Google's going to put up some balloon that's going in the middle of the Sahara. But the truth is, it's not that networks are going reach more and more places. They're going to do that, obviously. The guys from Hoodie talk about this a lot. We've been sort of predicating, when those networks are all there, the web will have arrived. The truth is, they don't need to be there for the web to still work. We've got the technology, it's up to us to come up with the patents. The approaches to designing. The development side is pretty simple, in a way. These aren't complicated technologies. It's really understanding how to create user experiences. There's a fantastic presentation that Alex Feyerke, who's one of the founders of Hoodie, did for our conference down in Melbourne recently. We'll put a link up later. It's a 45 minute overview of the sort of future we can enable using these technologies. He talks less about the technologies themselves and more about what you can do with them. I'm really excited about what we can do. I think as much as worrying about technology, we should be thinking about, "What can we do with it?"

Jen

Yeah. It's interesting because, to think about Lisa being only about... to be focused on documents and perhaps, where are your documents? How did you organize them? Oh, you want to open them now. Well, who cares if this one's going to open a text editing program, this one's going to open an image editing program, this one's going to... it's more... because what we ended up with the Mac was sort of both. You either opened your apps, your applications or you opened your documents. A lot of people didn't organize their documents very well. And here we are, 30 years later, and Apple is really getting away from documents at all and they're getting very much into apps. You're going to open Pages and when you open Pages, you're in the world of papers. You're in paper world and you can open up any of the documents that you opened in your iPad or your iPhone or your Mac, your this, your that, all in this one place, in the cloud, and they'll sync. It's like a little Disney World that you have to go into that place called the application and in there is where documents live. And people, increasingly, normal people — people who aren't as nerdy as the people listening to this show — are like, they don't know where the things are stored. They don't know where they went, they couldn't find them.

John

They're in the cloud.

Jen

[Laughs] They're in the cloud.

John

Look, to me, it's hugely backwards. Apple had this pretty amazing technology and it's very interesting that Tantek Çelik, who many people listening to this show will be familiar with, and if they don't, they should be. But Tantek worked on that extensively in the mid-1990s. And I'll talk about what it is in a minute. But Tantek then went on to basically head the effort to build the first really modern browser, which was IE 5 for the Macintosh. It was the first browser that allowed you to use CSS and HTML in the way that it really was designed, and I think really led the way forward. But what Tantek worked on was a thing called OpenDoc, and a lot of other people did as well. OpenDoc was an approach to computing where your embedded your documents in compound documents. Essentially you would have images and text, imagine like a... a simple example might be a page layout document. So there you go, you're flowing your text, you've got images in there. Now what if I want to edit that image? Well, I can kind of select and choose to edit that and then that would be edited by a component that was specially optimized for image editing. It was almost like the functionality of Photoshop but you didn't open Photoshop. There wasn't the model. It was happening in the background. But the model in my mind, my mental model was, I'm just image editing this image. And the cool thing was, you could choose your own components. As a user, you could say, I want this image editing tool not that one. And similarly you could choose your own spell checkers and grammar checkers. Whereas where we've got now is we've got these kind of walled gardens of functionality. Where if I want Pages then I've got to have everything that it does. From its text editing to its text rendering to its way of handling stylesheets, whatever layout in there, to its spell checkers and the web offers a profoundly different possibility. I think in many ways expensive computing has gotten more convenient but in many ways, worse. Because we've given up a lot of opportunity and possibility for the convenience of having everything in one place.

Jen

Well, and the real strength of the web is the interoperability across platforms and the real, kind of...

John

And between documents. What I also like, between documents and between applications. I've got an HTML document, I can edit that in anything that edits HTML. And I actually am like that sometimes. I have some text editors that I like more for formatting my HTML and other are more for marking up as I go. Because I'm actually one of these crazy people who, when I write articles, I write them in HTML. And very, very simply. In the some way other people use Markdown, I use HTML. Because what it allows me to do is essentially not just capture words and sentences and paragraphs, it actually allows me to capture, this is emphasis here and this is a citation. I've got all these macros, I can do it, bang, bang, bang, bang, bang, bang, and all that markup's there. But there are other HTML editing tools that work better than that. But what I love about the web is, that any document that we work with — whether it's image, whether it's scripts, whether it's style, whether it's content, it takes content — any document, it can be opened in anything that supports CSS or HTML or JavaScript. And a lot of people may not know, but I built a lot of development tools over a very, very long period of time. That's the exciting thing, in a way, is that you can build a better widget for editing CSS, HTML, JavaScript. It doesn't have to do everything Dreamweaver does. People can still use, by way of example, Dreamweaver, for a lot of what they do, and then they can drop in to a much smaller, specialized tool for specific things. And the workflow around that is a little bit geeky, that's certainly true, but the possibilities are extraordinary. Precisely because of the interoperable nature, as you mentioned, of the content that we're building.

Jen

It's so interoperable that you could work on a team of people, who are all very focused on a goal together. "We've got to ship, here's what we're doing, hurry up and get it done." And all of those people could use different applications to contribute their piece and nobody cares. It doesn't matter if one person is actually using... as much as everybody rants about which text editor is the best one, [laughs] the whole team doesn't have to all use the same one, every developer could use a different one, and it actually doesn't... there are no stumbling blocks. You don't trip over that at all, yeah. It's interesting.

John

Absolutely. Whereas if you look at iOS or Android or the Windows stack, the Microsoft stack, once you're working in that stack, you've got very good tools. Don't get me wrong, Xcode is really great for what it does. The .NET and Visual Studio stuff is pretty amazing for what it does. But you don't have a lot of choice, right? I didn't mention Eclipse in there, by the way, because you're forced to use Eclipse, right? To me, I guess at every level, from us geeky folks kind of playing around with the tech and working with the tech, all the way up the stack, this is the philosophy of the web that goes all the way up. Of interoperability. And it influences decisions about web technology, from what happens in the browser, in the browser's C code or whatever it's written in, all the way through what we as the front-end developers do, all the way up to the user's possibilities. That I can change browsers, right? I'm at this bank and it won't let me use Firefox, well, ok, I'll grin and bear it, use another browser just for this. This is something that no other platform enables in any way. I can pick up at home, I've got my $70 Android tablet, I can use that, I can jump on my iOS phone. You know, I don't think people stop and think just how extraordinary that is too often.

Jen

Yeah. Well, and I can open HTML documents that were written in '93, '96, '98. I cannot open Microsoft Word documents that I created in '93, '96, '98. Like, they're gone because they're sitting there on my hard drive and I have no software that knows how to open them.

John

Yup.

Jen

Unless I go find, you know, whatever, Microsoft Word '98 to open the documents from '93 and then re-save them as '98 and then go get something 2002 to open... [laughs] you know, like, slowly work my way back through time.

John

So a sort of ironic story along those lines is... so the source code the original browser that Tim Berners-Lee wrote, running on a NeXT machine in 1990, is available. So a friend of mine who's very smart and knows this stuff really well has tried to get that... essentially, in some respects it's a kind of, a very distant precursor to today's code that is running on the Mac and iOS platforms, right? Because NeXT is the progenitor to that. But there's no way because of the number... basically, this friend of mine has found it impossible to sort of take that source code and bring it up to date in any meaningful sense.

Jen

Wow.

John

Because there have been so many changes to the sort of tooling and underlying technology. Whereas if you'd taken something written at the same time for the web, yes, it would be much simpler. We can still load that page and we can still run it today. I guess that's one of the great strengths of the web, that all of these technologies are built to work indefinitely into the future and also indefinitely into the past in a sense. And tying it back into the offline world, what about app cache, right? The cool thing is, use it now. If a browser doesn't support app cache, then it's IE 9 and all those, so that's still a significant number of people but an increasingly diminishing number of people. It doesn't matter. Ok, so they don't have an offline version. Well, they're never going to have one anyway, right? So technologies like these are often so easy to use in a way that are backwards and forwards compatible. Because they're designed explicitly to be used as well as possible in that way, almost by default. I guess this is one of the great strengths of the web and why we're here on this Web Ahead. I think it's one of the reasons why it's not going away anytime soon. And why I think when we get these features, we really should think about investing in them. Because they'll have a longevity that most other things you invest in just won't.

Jen

So what are some other use cases that you've seen and ways that people are using offline technologies?

John

Well, the irony is that application cache is so painful for... I mean, for very large and very powerful use cases. There are some challenges in using it. So I know that and I know, often this has been covered in places like Velocity and so on, sticks out as is talked a bit about this. Is that places like Google search and Bing search engine, they actually... and a lot of other, to be quite honest, sort of very large, web scale teams, they use local storage as a cache, right? So instead of using app cache... one of the drawbacks of the app cache is that you can't do much with it with JavaScript. It's very declarative. You say, I want these things to be cached, I want things never to be cached, and I want these fallbacks, and that's that. There are few things you can do with JavaScript. You can force refreshes, you can swap an old cache for a new cache. But you can't say, "Right, I want you to go and find this particular resource again." So with those limitations, I know that some of these web scale companies are actually using local storage as a caching mechanism. So they'll kind of store, say, a font or some JavaScript or something in local storage and then they'll load it as part... once the page loads, they'll load it out of local storage. So they're creating their own caching mechanism. That's, I think, a case that people might want to explore. If they feel that application cache is just not the sort of thing that works for them. And then jumping into a whole technology that we haven't really touched on, which is the file API. Now, we've got these local file systems on our computers and one of the limitations the browser has compared to any other app running on our file system is that it can't — well, with some very constrained limitations — it can't read and write files from our local file system. We can't say, unless the user chooses to command-S and jump through a whole lot of hoops, it's very hard to put something on the user's file system, right? It's still hard to do that part of the picture. But what we increasingly can do is we can get files from the user's file system. So in HTML we've always had this file input element. Well, not always, but for a long time. File input element, click it and the user chooses one or more files. Problem is, until HTML5, we haven't been able to access anything about that file. It's just really, it's completely opaque to us as a front-end developer. The user can click submit and it gets sent to a server and then we do something with it on the server. But now, with file input in HTML5 and the file API, what we can do is, when the user chooses a file locally, and let's say an image file, or if they drag and drop it onto the browser window, we can actually get the contents of that file. Twitter uses these and it's really nice. So if you update your Twitter profile, if you go to Twitter and choose to edit your image, what it will do is, it will show you almost instantaneous preview based on reading the file contents before you upload. It doesn't require you to upload to display, because obviously that could be a relatively slow process. So if you go and do this, you'll find that you get a preview almost instantaneously of — well, effectively instantaneously — of the local file you've chosen to change for your avatar, by way of example. And to me, this is like a really simple but very slick use. Because one of the things on the web is we're always waiting for stuff to happen, so the more that we can make things feel close to instantaneous, I think the better the user experience is for the user and the more likely they are to use it. Now, most people probably wouldn't even think about this. But I just happen to know that I should have taken a long time when I did it recently, and it was instantaneous then because I know about these technologies and, like, ok, I bet this is what they do. So I guess, you know, if you can get access to files that people might be uploading to your site and you have some sort of site that requires people to upload or involves people uploading or pushing things toward your server. If you know the contents of those files, what can you do for them before they send the file? Maybe it's exact. So maybe you get the file, you read it's name — you can also get the last modified date — and you can know that, ok, this file, the last time it was uploaded was here. They go to do it again, you can say, "This hasn't changed since the last time you uploaded it. Do you want to upload it anyway?" Really simple things, I think, that can make the user's experience way better, given that the bottleneck in everything we do, will always be networks, right?. That's always going to be the bottleneck for us. Doesn't matter how fast they get, they're always going to be orders of magnitude slower than CPU and disk or SDD time. I think if anybody's doing something that requires quite a bit of users sending stuff to the server, I would look a lot at things like local storage and think, "How can I kind of do this stuff in the background? How can I allow the user to save locally?" Or not even save in the sense that they're consciously... essentially, "How can I store what they're doing locally and do my synchronizations in the background?" And then, "How can I alert users to things that they don't necessarily have to do?" Or, how can I allow them to preview a change like a new avatar that they're going to send, that when it gets there and it finally gets displayed on my page, it's the wrong size or because it's been resampled to be bigger or smaller it just doesn't look good, how can I do that instantaneously in the browser? Think about the single most painful part of the user experience is uploading/downloading, right? How can I minimize uploads and downloads? How can I move things to the client. So we've talked a lot about how I can save a resource once and then reuse it using app cache or local storage, right? So that's one part of the equation, minimizing the downloads. And we're all thinking about that. But uploads, typically with ADSL, which most people in the world, including all of Australia basically had, the "a" in asynchronous means uploading is generally on order of magnitude slower or several times slower than downloading. And even though we tend to do the upload bit less often than the download bit, it's often the high value stuff, right? People creating an account, well, they're uploading stuff. The more painless you can make that experience, the most likely they are to complete it and therefore the more likely they are to actually complete the transaction. Something like some ridiculous number like 50-70% of all shopping carts are never completed, right? By way of example. That's something I think people can look at using local storage for. Maybe make it all happen locally. Don't worry about it happening on the server. Make it all happen locally and just right at the end make a transaction go over the wire. I just think there's so many possibilities. Every time I think about a website that I use, I think about how moving some of the weight onto the client, minimizing some of the upload and download, would improve the user experience.

Jen

Yeah, I mean it's really sounds like there's... it's about shifting our mindset and our understanding of what a browser is and what a browser can do and expecting more out of browsers. And using the power... I mean, you're basically using the power of your computer, your phone... your user's phone, their tablet, their computer. Because I think for many, many years, the browser's really been just sort of a dumb place. It's just a dumb frame. All it can do is display. That's all it does, it just displays stuff. And then you can click buttons and when you click buttons, it sends commands to a server. But anything that you want to do that's interesting or complex, it all needs to happen on the server. But that's really shifted, that's really changed to where you can do so much with JavaScript on the browser side and the browser can actually use, match more of the resources available to the computer itself, from the computer itself. Including the things you're talking about, including things like saving in a database in the browser. There's a database inside the browser. [Laughs]

John

Actually, there are lots of databases. So there are two. There's the local storage I talked about. There are some limitations around that, generally only have about 5 megabytes. Someone asked, Impact Web Studio asked about this, we tweeted out to ask if anyone wanted to ask any questions. "How standard will 5 megabyte storage limit be in the future?" Well, that's pretty standard and I think that's about what we're going to get with local storage. So there's some significant challenges for using it for anything other than really text and a reasonably small amount of text. When I say reasonable, a whole book. As soon as you start looking at audio and video and those sorts of things, limitations. But then we have a thing called IndexedDB. And that's now with iOS 7 and more recent Android, and even, in fact, going back quite a way in Android, that's really widely supported now. So IndexedDB overcomes pretty much all of the limitations that we have with local storage in terms of performance and in terms of the size of the things that we can store. So if people... and once you've gone beyond the capabilities of what local storage has, IndexedDB allows you to store up to about 50 megabytes of a single blob of data, which you could potentially copy to multiple blobs. So that 5 megabyte limitation in local storage is pretty much for a whole domain, right? Your entire domain is pretty much restricted to 5 meg, right? Which isn't a lot. It's one photo at high resolution. So basically it's really not designed for making Instagram clients, by way of example, or Vine clients, or anything that uses a lot of very complex data. But we have a thing called IndexedDB which is there now and it's across all modern browsers and there are implementations like PouchDB and Lawnchair and some other really nice, higher level — in terms of the developer API implementation — sitting on top of IndexedDB and even giving you backwards compatibility on other platforms that don't support IndexedDB, that give you a whole lot of nicer ways of using that. And even, as I said, with PouchDB by example, makes it a lot, lot simpler to just synchronize onto the server. Makes that job really, really straightforward. So if there are things people are looking at playing around with, there are already things built on top of these technologies like Hoodie and like PouchDB, that kind of take care of probably about 90% of the heavy lifting, synchronizing client and server.

Jen

What's happening with app cache 2?

John

So, effectively there's a thing called service workers. The idea is where app cache is declarative, right? You don't have a lot of control as I mentioned with JavaScript. You essentially can do things like force an upload or get an event when a cache has been changed and force a refresh of your page. But that approach... there are certainly many people who feel like there are too many limitations in a purely declarative approach. Service workers, which is starting to land in some of the sort of canary, developer builds of Chrome and Firefox, I believe, and certainly, you know... it seems to be coming. Service workers, it's had a few names. It's essentially a way in which we can do what app cache does and more but using JavaScript. So essentially right from the get-go you could have a service worker running so that every time someone hit a URL, instead of it downloading a HTML document, the service worker essentially is like a little client-side server, if you want. That's doing all of the request. So it's almost like intercepting... it's almost like the browser engine, written in JavaScript that allows you to do all the transaction. I know that's not necessarily making a lot of sense. But essentially instead of, like, you're grabbing a webpage and then grabbing all the linked resources, the service worker gets invoked and follows a set of instructions that you give it with JavaScript to do all that for you. So, ok, go and get this resource and go and get these resources and then we're going to build the webpage. It's a much lower level request engine. We're almost intercepting how the browser kind of goes and talks to the server.

Jen

So that's what... because for awhile, everyone was saying, "App cache, awesome." Then people were saying, "App cache, really hard." As you have already described a lot. We want it to do this and that and this other thing and it doesn't do any of those things so people were saying, "Hey, we need a 2.0 version of this spec. We need to rethink this now that we have some real world experience and come out with another, more powerful, more nuanced way to handle caching files." So service workers is what's coming as a result of all of those discussions.

John

Right. But to be quite honest, I think there are cases, there are plenty of cases where service workers are going to be overkill. The first one is, it's only ever going to work over HTTPS. It's never ever going to work over pure HTTP. There are very good reasons for that. Essentially, it's about man-in-the-middle attacks. There's a lot written on this so I won't bore people. If you want to know why service workers are almost certainly ever going to work out of HTTPS, just go and search "service workers HTTPS" and you'll get a very good description and discussion as to why. My general feeling is that the web is moving increasingly to HTTPS. I think eventually only. Right now, it's a real pain to get HTTPS working and there are lots of problems in terms of... it's easy enough to use HTTPS and still get it wrong and still leave open security challenges. I think that's going to get easier. Why am I saying this? Because, well, firstly, you see the direction of things like Twitter and Facebook. They're all HTTPS-only, right? You can't use these services over pure HTTP anymore. Which I think is very good. My feeling is Google wants everyone to do this. Purely conjectural, I have no inside information, but my feeling is that Google wants HTTPS everywhere. And what Google wants they can always use some subtle engineering, such as, "We will give higher Google love to pages that are HTTPS-only." We've already seen some of this. Steering people in the direction of how they want the web to be. So even though it looks like a pretty significant challenge right now, that service workers are only HTTPS, I think in time that's not really going to be a huge issue. And in some ways, I think it's probably going to be one of the things that steers more and more people towards HTTPS. By the way, if anybody out there wants a business opportunity, I think creating an easy to use HTTPS kind of certification service, there you go. You could be a multi, multi millionaire because right now it's a real pain in the butt, right? There's a pain point, there's a prediction from someone who's made money predicting the future in the past, it's something I'm thinking about doing, but if you guys want to do it, please be my guest. There's only so many hours in the day. But having said that, I think there are use cases where app cache works fine. I don't think, "Ah, well, app cache, it's going to be superseded by service workers, therefore I'll just wait for that." I would start using app cache now. I would not be overly concerned about the limitations that people talk about. They're there, that's true, but I think the benefits are really there as well. And I think so far over the last couple of years, we've focused a little bit too much on the negatives and not enough on the positives. Because it can make really... I think you can make... maybe I was guilty of this, but in the past we focused a lot on the negatives of image replacement techniques but the truth is they sort of gave us a sense of where the web could head if we got better web typography, right? So even though there were a lot of problems with image replacement techniques, and I was very critical of them, they also allowed us to see why better web typography was going to create a better web for us. Because we could see what happens when people have more fonts and more control over typography than the web at the time gave us. So, in a way, to some extent, app cache is a bit like something that we can use to explore what will be even better once we get some of these other features. But it doesn't mean don't use it. If anything, I think get ahead. I've got a bit of a thing where people say something is not ready for primetime, that's the time you should get on board it. Because once it's ready for primetime, everyone's using it, and in fact, you're behind the curve, right? [Jen laughs] So get ahead of the curve, get on board these things, play around with them. I'm not talking about taking you six months to get your head around it and get up to speed. You know, like, so many people get on Angular or some other framework. These things take a lot of energy and time to get expert, and yet people think that's worth their while. And yet they don't think it's worth their while getting up to speed with the technology that after a half a day's investment, will actually make your website a lot better. Even though there's some cool things coming, don't use, "I'll leave app cache, I'll wait for service workers." Because they're going to be awhile and they're going to be hard work and they're going to have additional challenges like requiring everything you do being served over HTTPS and trust me, that is more than half a day's work to get up and running with, if you've never done it before.

Jen

Well, and I think it always depends what you're doing, some of the limitations. If you are building a website where the content is never going to change, then you don't have to worry about serving people a new version of the content that they've already cached. Because it's not going to ever change. Because it is a book or it is a conference website or it is something that is going to ship and then it's just going to stay there. Maybe there's a few fixes, a few error corrections and this and that but they're not mission-critical.

John

And there are ways around that and really, really simple ways around that with JavaScript as well. Maybe I should write a really simple JavaScript library which kind of helps people with that. Yeah, there you go. My book's full of this stuff but maybe just, look, here's the library, just include this one line of JavaScript and now it's going to, like, it'll pretty much fix that problem.

Jen

Yeah. Well, and some of it, too, is around workflow where you just... like, you don't want to cache the site on your own development computer while you're trying to develop the site, because then you keep making changes and you keep never seeing the changes. [Laughs]

John

Never do this, people. Do not develop with app cache turned on. Do not do it, trust me. Listen to Papa John. [Laughs]

Jen

You have to put it in another branch. I mean, that's what, it was just, like, projects I've worked on, it's like, put it in this... danger, danger cached branch. And you know, if you go over to that branch, it's going to get cached, and then when you go out of that branch, you're like, ok again.

John

I've got two little tricks you can do though. There are two little things you can do that can fix this. So the first one is, app cache, the manifest file, must be served as text/cache-manifest. That's the mime type. Now, most of the time, with mime types, it doesn't matter, right? There's only really been one case in the history of modern web developer's lives that we've actually had to worry in any way about mime types before this, right? Which was IE... which version of IE that if you served something as text/application/XML or for an XHTML document and you... remember that one?

Jen

I purge IE bug knowledge out of my head as soon as I can.

John

Exactly, right. So, this is the only other time. And you might think, "Oh, what a pain because now it has to... now we have to serve it and there's some challenges." So by the way, if you use app cache and it's not working, check the mime type that the app cache is being served with, because that's almost certainly not right. Just fix that and you're on your way. But, here's my little trick. This is Papa John's trick for working with app cache while you're developing. Serve your manifest files, create 'em, link 'em, do the whole business, but while you're developing, in development phase, just serve those files as text. So the mime type is text. The browser will download it, it just will not use it. It will not use it because it has to be served as text/cache-manifest. That's every browser, that's, I think, and I'm not sure of this, but I think by design that we could do this, right? Now, you might say, "But I can't do that because it's on the same server," and yeah yeah yeah yeah. Ok. So if you can't do that, here's another one. There's this really subtle, horrible aspect to the app cache, which we can use to our advantage. So if you go to cache manifest file, and it's got 3,000 resources pointing at all these different domains, because app cache is cross-domain, by the way, there's not a single origin restriction on it. If you're doing all that, alright, and one of those resources 404s, then the cache doesn't get built, right? Got that? So what you do is, in your manifest file, you link everything up, you serve it as cache-manifest, you do the whole business, but in your manifest file, just make sure you point at something that doesn't exist.

Jen

And it breaks the file.

John

Breaks it. Listen to me, you've got to do that...

Jen

In a way, that's useful.

John

Right, exactly. Here's the thing though. Don't do that having built the manifest once, right? Make sure you've never built manifest in the first place. Because what happens in, if the manifest has already been built and a resource is missing, then it just uses in perpetuity the old version of the manifest. It never updates it, right? So there are two little tricks — again, they're in my book — that if you're developing with app cache, it doesn't mean you have to go through and add the app cache after the whole development process. You can have it all set up, ready to go. You just serve it as the wrong mime type and then basically it doesn't get used.

Jen

So you're deactivating it.

John

Effectively. And you can turn it on as simply as changing the mime type or getting rid of that link to the illusory image or whatever file that doesn't actually exist. So that was worth sitting through the last hour alone if nothing else was. [Jen laughs]

Jen

In support, I'm looking at the CanIUse, specifically for app cache.

John

I would say the biggest shortcoming is IE 10 and up. So you go IE 9, 8....

Jen

So 8 and 9 don't support it. Opera Mini doesn't but Opera Mini's doing its own completely separate thing.

John

Right. And everything is.

Jen

It's basically supported and it works well, you're saying. It works the way it's supposed to across all of these browsers.

John

Yeah yeah yeah yeah, yeah, absolutely. The challenges people have with app cache is how it is designed. And I think it's a classic example of something designed in a vacuum. it really, really, really wasn't designed in an iterative process where... it was like, it was kind of whole of cloth by Ian Hickson. And landed as this feature. You know, as maybe HTML5 features did, although it happens less and less now. There seems to be a bit more discussion and iteration around things than there perhaps were at a certain stage of the development of HTML5. But having said that, it is a very, very useful technology. It's just a bit of a shame. We've all got to be caught up on its limitations and perhaps despite that, didn't appreciate how valuable it could be if used properly.

Jen

Yeah. I still think more people just don't know about it and they don't know... they haven't really thought through how this might change things.

John

Yeah, that's the next... so first they have to know about it, then they have to get over the limitations and the pain points, and then they have to start using it in really simple ways, I think, just to make your website faster. And then start thinking, "Ok, what happens when the web doesn't really need a connection all the time?" That is such a profound change in the nature of the web.

Jen

I mean, the web, for many people, the word "web" and the word "internet" are synonyms. They think it's the same thing. So not only is it not true that the entire internet is the web, right? There's all these other parts to the internet that are not the web, they pre-date the web. But it's also true that you could have the web without having the internet. I mean, not big picture, not the whole web and the whole internet, but you could have, I think, web experience and go to a website when you're not necessarily involved with the internet at all.

John

Absolutely. I think web OS and Firefox OS, Chrome OS, they're all sort of suggestions of where this could head. In a way, it's a good observation of yours. It's sort of almost decoupling the web from the internet. Because, as you say, the reason why people think of the web and the internet and synonymous, is because with the exception of email, and even then most people use it through the web, people's use of the web is essentially, they use the internet.

Jen

Most people don't use FTP, IRC, and... yeah.

John

Yeah. So this is really saying, the web is the way you access the resources of the internet. But increasingly it's going to be how you access the resources of the local device that you're using. So it's kind of an access later, human interface layer to your local device, as much as it is to the resources of the internet.

Jen

You know, and the other thing that I've seen, a trend that drives me crazy but I'm noticing more and more is that, these native apps, they're supposed to be so awesome and so much better and in part because they've had offline since day one and the web did not. Bit I'm seeing more and more quote unquote native apps require internet access. Where you used to open Facebook or open Twitter and you would open it to the content that was there when you last closed it and you could scroll through that content and read it, and if you were on the subway or you were someplace where the internet was really slow, your experience would still start immediately with content and then it would refresh and add new content if it was able. But now more and more these programs, you open them up and they're blank. There's nothing there. And if you don't have internet connection or if your connection is very, very slow, you won't get any content. And I'm surprised at that. I sometimes feel like, you know, San Francisco! You shouldn't be the global center of everything, That's just... the experience of the world is not the experience of living in San Francisco. I live in New York and there's no internet on the subways and you walk down the street during rush hour and the internet is incredibly slow. It's so slow. You can barely load your email. Because there's so many people hammering it. And in other countries, you have to pay per kilobit, per kilobyte, you know, you're traveling, you don't have access. Even as things get more and more modern and more and more awesome, the networks are not able to necessarily keep up. And this assumption that everybody's got internet access 24/7 is... I don't know. It's not true. So I don't know how native app developers are doing that. I don't know why they are relying more heavily on the internet when they could rely on, you know... I don't know. Create an offline experience.

John

Yeah. Look, I think it speaks perhaps... I think you're right, to some extent. In the olden days, one of the things that a lot of software development companies always insisted on was the developers didn't have the lightest computers. Because, you know, there was a time, maybe 10 or 12 years ago where, when you built software, there was a real difference. A year or two in terms of CPU improvement would make an application go from being a pretty awful experience to a pretty awesome experience. So a lot of companies would have this thing, you are not getting the latest and greatest computer because it's going to give you an artificial sense of the quality and performance that you've got. Obviously as the baseline has increased outside, CPU... increasingly applications, except in rare circumstances, aren't CPU-bound, in terms of their performance. But I guess that's been replaced with the sort of network-bound applications. And as you say, I think you're probably right. Most people that build apps are probably the most technologically privileged people on Earth, in terms of the technology they have at their disposal and that includes... it's a no-brainer to spend as much as possible on network connection. Because in the scheme of things, it's not a lot. If you're selling thousands of dollars of apps a day or week, then paying hundreds of dollars worth of network a month isn't really much of an issue. But in Australia, by way of example, it's either prohibitively expensive or essentially literally impossible to get even decent network speed in a lot of places. Just the technology isn't there. The infrastructure isn't there. So in a way, Australians are very, you know, like when we read about Americans, "Oh my god, I'm only getting like 50 megabits a second down or something." [Laughs] There are times I always laugh at, "Oh this is terrible, I'm only getting 8 megabits a second down and I should be getting..." You know, it's like, honestly. A lot of the world, and I'm not even talking about poor benighted people, most of the people in the world, even the developed world, just aren't getting network speeds like that. And I think for a long time, and I talked a little bit about this several hours ago, thank you for continuing to listen to me, people. You know, like, we had this idea that we're just going to have Wi-Fi everywhere. We're going to have Google balloons circling the Earth, more and more and more bandwidth and so we're going to be bathed in it and it's going to be free. It's not happening, right? It's getting better but that's not happening. And that's where the Hoodie guys kind of have this great quote that I start my book with, about how you have to get away, and I guess it mirrors sort of Luke Wroblewski's idea of mobile-first, when they talk about offline-first. They say you have to get away from the idea that increasingly everyone's going to have desktop-quality network connections everywhere they go with every device that they use. Honestly, it's not going to happen. Because networks will always have latency problems. At the end of the day, there's always the speed of light. Which means that our networks are always going to be orders of magnitude slower than every other aspect of our computing. So the more we can use the capabilities of the device that's in our hand, in our pocket, on our desk, whatever, and the less we have to rely on the network, certainly as a kind of bottleneck where this thing has to happen now. And we have this synchronous model of computing where I hit a submit button and now I have to wait, right? The truth, even that model alone is like, well, I'm doing my thing and yes it's going to get synchronized on the server somewhere at some point but why should I as the user have to worry about it? I'll just keep going. I'll make my note, I'll do my edit, I kind of do my image whatever, and I just keep going, and it's being saved locally and then when the bandwidth's there, when I have the connectivity, let's synchronize in the background. There are some things where real time... here we are, we're talking to each other now inside the world. Yes, offline here isn't going to work very well, right? But ironically there are times when I've done interviews like that. When I've made a local copy because the quality over the network hasn't been good enough. And then I've sent them via Dropbox or something the reasonably large recording from my side and they edit their own recording with my recording and make the final copy. So even in a case like this that we're having, people do this sort of thing offline or with an offline aspect.

Jen

Well, thank you so much for coming on the show today and talking about all of this with us.

John

It's a great pleasure, Jen. Can I get a couple plugs in?

Jen

Yes.

John

Alright, alright, so. It's reasonably late notice, it's on next Monday, Tuesday and Wednesday in Nashville, Tennessee, home of hot chicken. Which I hadn't heard about but Luke Wroblewski alerted to me to the existence to this particular delicacy, where I'll be enjoying. As well as barbecue, which I do love. So, anyway. Nashville, Tennessee, BDConf, Beyond the Desktop, very kindly asked me to come over. So I'm doing a half day workshop on these technologies. So if you're anywhere near that, get on the website, have a look, it's a whole half day in-depth on all the technologies we talked about. Not just what they do but how to use them and I give you some exercises to go away and do. And if you haven't got a whole half day, then the following day I'm doing a one hour presentation on this. So that's all in Nashville. My book on this should be out soon. It's just kind of going with the designers and whatever so it all, it'll be an eBook, but it will all be available to download and so on. And it covers all the technology in real detail.

Jen

And who's that through? Are you self-publishing it?

John

Yeah. I'm gonna... so I've done some books through various people but I kind of, we're self-publishing again after the first stuff we self-published was in the late 90s, with stuff with CSS and HTML when most of the audience wasn't born. But yeah, we're returning to that, so that's going to be available. And it's really, really in-depth. Everything you need to know about this stuff. And then later in the year, we run Web Directions. So if you're in Australia somewhere, check out Web Directions. There's an engineering stream for all their engineering kind of side of the web and then there's a product design experience track for all the kind of, you know, all the design experience, interaction design stuff.

Jen

And that's at the end of October.

John

That's it, October 30-31 down here in Sydney.

Jen

And there are several great videos of you presenting and this one of Alex presenting that were both from talks at Web Directions.

John

That's right, so that was our recent conference. Actually, one was a couple years back and one was Alex a couple of months back down in Melbourne at our coder conference. Yeah, so there's some things that really hopefully help people kind of get their head around what's possible and then a bit of a deeper dive that I do into the actual technologies as well. So, yeah. Check out the links down at the bottom of your page.

Jen

Yeah, they'll be at 5by5.tv/webahead/78 or of course you can always just go Google "web ahead", "the web ahead" and find us and find this episode and there will be a bunch of links. I put a whole bunch of them in. Sometimes there aren't very many but this week there are quite a lot. Some blog posts that you wrote as well. And so how can people follow you on Twitter?

John

I am @johnallsopp. So it's j-o-h-n-a-double-l-s-o-double-p. So just follow me at @johnallsopp. I'd love to see you there.

Jen

Nice. And you're personal website... I already closed the window, what is it?

John

Yeah, that's johnfallsopp.com. Because even I didn't move fast enough to get my own name. [Jen laughs] There are lots of John Allsopps in the world, I was surprised. So someone else got it and I'm johnfallsopp.com. But if you just search for John Allsopp you should...

Jen

Well, again, thank you for being on the show. This has been great. Hopefully people are excited and they'll go use all this technology on their websites.

John

Yeah, and please, look, shoot me questions, I love answering questions. It also helps me sort of think about use cases and the edge cases so there's a few there that I noticed people tweeted me. So do, hit me up on Twitter and, you know, happy to see how I can kind of point you in the right direction for working with this stuff. Because I think it's really important and I think it's really exciting and I think people should be using it.

Jen

Yeah. Well, congrats on your book, I look forward to it coming out.

John

Thank you, Jen, and thanks for asking me and thanks for, yeah, the chat. It's been great.

Jen

Ok. Until next week. Bye.