 This is George Gilbert from theCUBE. We're at the San Jose Convention Center at the At Scale Conference. I'm with Nate Schloss from Facebook and we're talking about the mobile web. Nate, tell us a little about what you work on at Facebook and give us the little context for the talk you gave and some of the things we should know about where the mobile web's going. Yeah, so I'm on the notifications team at Facebook. A lot of my work lately has been around using JavaScript service workers to bring native features that generally only exist on like native web clients to the mobile web. So push notifications is an example of something we've recently built that it's generally a native feature but we've been able to build it on the mobile web for people using mobile browsers. Okay, so for IT, mainstream IT that is trying to filter down all this knowledge that's coming out of these leading edge companies and the practices you're pioneering, tell us some of the other things that if they've struggled with writing native apps, what are some of the other things that are migrating down to the mobile web that they should be aware of? So there's this new kind of paradigm on the web now called JavaScript service workers which are basically like pieces of code that exist outside of the web page and can kind of like they persist like native code would persist. So you can do a lot of like really interesting things. They act kind of like a client side proxy. So a lot of like the performance benefits you would get from native app by like having data on the app, you can get that from a JavaScript service worker and you also get things like push notifications and a lot of the other benefits that you would get by having native code. So you can use like if you're deciding like whether or not to build an app, if you already have a lot of skilled web developers, a good solution could be just to use like JavaScript service workers and like take advantage of a lot of native features without relearning a whole new skill set. Okay, so let me see if I can replay that in language that traditional developers might be more comfortable with. So when they built graphical web apps, they borrowed concepts that we used in the client server and even in the desktop era where you had the graphical view, you had controllers and you had this abstract thing called model behind it, like what's the spreadsheet? And then here's a view of your part of it. Would this be like a return to that where instead of having some of it over the network where you have a delay in getting to it, you're putting some of these components in JavaScript back on the client? Definitely, you can probably think of it as a bit of a controller, maybe kind of some model there too. But yeah, it's definitely like it's code that persists, it's not the view, but it's like code that lives in the background and like can run the app or website. Okay, so we know that actually Facebook had some challenges in their early implementation of mobile client using HTML5. There was some performance challenges. So what's changed since then? Because it's very snappy now and is this related to some of the technologies you're talking about that would be of relevance to others building mobile web apps? So the things we did, like Facebook rewrote the apps to be native, that's not the stuff I'm talking about. The stuff I'm talking about is more like new technologies that didn't exist back when Facebook was initially building our mobile apps. But it's things that people can do on the mobile web now to get a lot of the benefits that native apps give. It's still not everything, like you can still like make like a much faster native app, but it's getting like a lot closer to all the features that are available on native for the mobile web. Would this include access to the low level hardware, like the camera and other sensors and things like that that it's always been difficult to get to without native? So I think the long term plan is yes, service workers aren't there yet, but I do believe that eventually the idea is to get like most of the native features available on the mobile web. So it's not really like you have to go build a native app to like get everything. Like I can just navigate to a website and have to download something and still get all of the advantages I would get by like having an app. So from the perspective of IT, this would be the best of both worlds having sort of mobile app like experiences but having all the infrastructure that the web is built up over 10, 20 years like search and indexing and everything like that. Yeah, exactly. You can reuse a normal web stack and like everything that you already like know and have built and get most of the advantages you would get by having native app. Okay, very interesting. So are you pioneering this because Apple and Google don't want to or is Google doing this because they would like to return things to their sort of web native home? What's the dynamics of the different companies trying to build these platforms? So I mean ultimately like we're working with like the people who are working on the new standards for service workers and stuff like that generally just to make a better experience for users. If like the website's faster, if you like can just like load it quicker you get push notifications on it. Overall like everybody wants what's best for users and building like more like native capabilities into web browsers is going to enable that. So would we see this as a, it's almost like instead of going to WWDC, the Apple developer conference in June of every year, people would start going to this web native conference and that might serve multiple platforms. So I think they compliment, at least like with the state of the world right now they compliment each other really nicely. Like they're not really like fighting against each other. Like native apps serve somewhat of a different purpose than like the mobile web does right now. And you still can't do everything with service workers that you can do with the native app. Who knows how like stuff will evolve, but for at least like the foreseeable future like things are going to be like very complimentary towards each other. And how should we look at that complementarity? What are the distinguishing characteristics of each? So it depends. I mean like the mobile web obviously like you don't have, the barrier entry is a lot lower. People generally have web stacks. People generally like have developers who know how to develop for the web. Getting to a website is easy. You don't have to download an app. Like it's really easy from like the user and everybody involved, but you can still do a lot more with the native app. So it's there's still somewhat of a trade-off and we'll see how the lot of this plays out. And is it just as easy to access back-end services? You know whether the Google services or Apple's cloud services? Yeah. I mean a lot of most of these services already like have setups to let websites run on them. I mean they're like fairly good. So using any of these services will be fairly simple. For example, like push on like Google Chrome. It works with GCM, which most like most people already are familiar with GCM because it's like powering native push notifications. Okay. All right. So this is George Gilbert. Thanks for joining.