 Oh look at that, hi, hi Boaz, we're supposed to introduce ourselves now so we'll do that. I'm Rebecca Murphy and I'm a JavaScript developer at Boku and I'm here with Boaz, go for it. What's your Twitter handle Rebecca? My Twitter handle is rmurphy with an EY, your Twitter handle BoazSender. My Twitter handle is also my name, BoazSender and that's Ricky. I'm also a JavaScript programmer at Boku and I'm very excited to be hanging out with you today Rebecca. We are, we are, Boaz is Evan Boston and I am in North Carolina and hopefully the internet will hold out for us this time which it didn't so much last time but I have faith, I have faith. So Boaz and I are going to talk about a bunch of things today but we want to start by just talking about an app that Boaz has been working on at Boku and a little bit about sort of like Boaz, you've been doing development recently for Boku but before recently what were you up to? Yeah, so I mean my background or my career has been as a web developer and as a JavaScript programmer but for the last couple years I've been sort of like doing business management and more sales so this is my first time, I mean I kept programming on the side and sort of having fun, it's what I really love to do, it's been my hobby when I go home but this is the first time in about two years where I've actually been committing code, a year and a half, I've been committing code for Boku and it's awesome. And you're like a giddy school girl about it, you're really not doing it justice because the last time we talked about this. I don't know, there are not words to describe how great it feels to be writing software again, it's why I'm at Boku, it's why I care about, it's what I love to do, it's my craft and so to have gotten disconnected from it was hard and so I don't know doing it again it's just like there are no words to describe the feeling that I get when I solve a problem. In a complex JavaScript web application it just feels really good. It feels like JavaScript. Are you trying to get over the Boaz? I was trying to wombinate, yeah. Good try. So what is, so you've been working on this app that you're working on a web app, so what would you tell us about that? So we have, one of our customers at Boku, one of our clients, hired us to build mobile web app developer tools for their web development content team as well as implement the first mobile web application using that tool chain. And sort of along the way knowledge share and sort of like lightly train the team on the workflow that we're establishing. And so that's been a lot of fun because I get to sort of jump back into writing code for Boku using the tools and the workflows and the best practices that have emerged at Boku while I've not been implementing web applications. Sorry. Sorry, I didn't hear what you said. Well, we did it, the internet. Rebecca, did you accidentally leave the internet? Oh, we lost Rebecca. So has anybody heard any good jokes lately? How about the one about the Google Hangout? Oh, we've got somebody back. No, I think I was invited in. Let me think of an appropriate joke. Do you all follow Rob Delaney on Twitter? He's pretty funny. Yeah, the guy, he's got these great one liners. A couple of months ago, a couple of weeks ago, he said something along the lines of like rough day, my cousin Joel caught whatever the heck it is that makes you wear those five toe shoes. And I thought that was really funny. He doesn't think it's funny because he wears them. Are we getting Rebecca back? She has lost connection to Google. One of the big issues with North Carolina. Oh, she's back. There she is. Hey, Rebecca. Hi. I hope that I didn't look the same person on other people's screen as I looked on mine. It was kind of like that. It was bad. Anyway. Yay, internet. I was asking you what the stack is that you're using for this. So I'm using sort of what's kind of starting to emerge as a tool chain and stack that a lot of people who are at least five or six of us just built around backbone boilerplate and backbone boilerplate build. So backbone boilerplate is a collection of, it's sort of a, we have a blog post about it on a book web blog. Maybe we can put it in the show notes. But it is a sort of file system structure and conventions for, you know, where to put your templates and your layouts and your views. As well as some boilerplate code for doing common things that you would do inside of a web application. It also comes with require.js and a boilerplate require.js config and a whole sort of control flow for your application for dependency management and moving around. How are you, I'm just going to interrupt you. How are you finding require.js? Especially if you've been kind of tuned out of the development world while all these dependency management battles. I totally missed the dependency management battles of late 2011. You were like, I'm selling shit. I'm closing deals with dependency management. Not the main news. I mean, I guess it's been a longer conversation than just last year or so. Yeah, I never really, I had used require, but I never understood the API. I finally got the API and how it works after about two days of this application working on right now. When it clicked, it was like, yeah, it was really wonderful. It was really empowering for using background boilerplate as well as, you know, organizing my code well. I would say I was definitely in the dark with background boilerplate before I understood the require API. Yeah, yeah. So what is this app? I know you can't tell us what the actual app is because privacy in the NDAs and things like that. But can you tell, I know all the answers, but I'm going to make you tell me what it is without telling you what it is. So app is sort of a content centric mobile web application. And this is like, you say mobile web application is running in the browser. It's in the browser. We're very lucky to have a customer that really wants to build mobile web applications. And so what I'm working on or what we're building is, you know, would be, I think if this was on the desktop, it's kind of funny the idioms that emerge. But if this was on the desktop, I think it would probably be a website. But there's a little bit more integration with the device, right? Because, you know, we need to keep track. There's a little bit more integration of the device and it compels our customer. It tells us to sort of describe this as a content centric mobile web app. Does it work when you say app? Does that mean that it works offline? What does that mean? Yeah, it works offline or, yeah, our work in progress is working offline. It's using your location. It's when you're on an iPhone, if you save it to the home screen, it's doing all the, you know, all the right things to make it feel a bit more native to your device. Right, right. Saving all of its state and local storage. So actually, and caching all of your JavaScript resources with appcache. So actually, if you're not connected to any network, if you load this once, it will still work the same way. So it's not pulling its content down. Well, it's pulling its content down from the internet the first time, but it's not relying on the internet for the app to go from one page to the next. Right, so one of the key sort of architectural decisions that we made with the application was to bundle all the data, all the content for the whole application together and let you sort of download that in arbitrary stages. But essentially, in memory in our application, we have a single global model. That's our application state. And as we load resources in from the server, we tack them on, tack those pieces of information onto our global app state model. It's a backbone model. And that model is itself responsible for when anything changes about it, serializing itself and storing itself in local storage and pulling itself out of local storage and reconstructing itself. Reconstructing its array properties into collections and backbones and so forth. One of the nice things is you could, the way we've designed this is you could structure the entire lifecycle data for the whole application, at least what's coming from the server in one big JSON block. And for a smaller, down the road, we've done it this way, so that down the road, this mobile web app template that our customers continue to use, if you have a small amount of content, if you're under half a megabyte, you may want to do that. But for most of the larger things, like this first application we're working on, I'm projecting, I'm expecting that by the time the content authors are done writing the content, we're probably going to have five or six or seven megabytes. So map titles may be even more, because there's maps in this application. So what are you using for the UI? That's the architecture for all this. What are you using for the UI for it? Yeah, so we didn't really sort of get to the stack. We didn't get to finish the stack. I cut you off, sorry. I like architecture, so I went right to that. So for the UI, our customer has a UI design team. I created some user interface comps, and it was sort of general graphic design that executed the brand. I looked at using one of the many mobile UI frameworks out there, and I wasn't happy with any of them, so I made my own. Which I really beat myself up about. I'm like, come on, because I'm very... Well, maybe I have... We tried to be not invented here at Boku, and we tried not to reinvent the wheel, but there was really nothing that I found that was right for this customer, for their target users, for their target devices. On the one hand, and I mostly looked at... I mostly looked at jQuery Mobile, and jQuery Mobile, Twitter Bootstrap, and then I ended up looking at Sencha a little bit. jQuery Mobile was just really clunky, didn't work. The user experience on a modern phone was too poor. Like with scrolling and stuff? Scrolling, page transitions, the whole thing felt really slow, and I just felt like my phone was dying when I was using it. I understand that the jQuery Mobile support matrix is much broader than... It's very broad, and so they're supporting older devices, and so they're doing all these things. I'm not exactly sure why it behaves the way it does. I know jQuery Mobile is very ambitious compared to Sencha, which is just iPhone and Android, I think. Yeah, I'm not sure exactly what Sencha is targeting. That's an interesting question, though, as far as UI on mobile. How are you going to handle the uncanny valley of Android versus iOS? Is it going to be in iOS like UI, or is it going to be... The UI is neither, and it feels... We're taking... There's some trade-offs that we're doing. We're not doing bottom navigation. Because why do we need bottom navigation other than to make it look like an iPhone? If you throw your hands up for bottom navigation, you get iPhone 4. There's hacks for doing bottom navigation on iPhone 4s, which involve re-implementing scrolling in JavaScript and scrolling physics, which is just like I can justify the hit on the CPU and the battery to mock scrolling physics, because I'd rather just use native scrollers than be much more efficient for the user. Top navigation looks cool. Actually, I looked at a bunch of other companies' mobile web applications, and I think Lanyards jumped out at me as being really good. UI is really responsive in the quickness sense of the word, and they have great top navigation, but that's where I got the idea. As far as UI framework goes, JQuery mobile has gorgeous looking styles and themes. The big problem for me is I couldn't separate those from their JavaScript, which they need. I really would love to see a... Okay. I'm here twice now? Yeah, but in one, you look very thoughtful. This is hilarious. No, I don't want to end the broadcast. Don't do that. Thank you for putting up with us, whoever is watching this. Sorry, everyone. Are there... Do you see four people? I see four people. I'm on here twice. You are, but I think we're just going to live with it. You'll go away eventually. At least you don't look like I did, so... Are there two boys? Are they gone now? No, don't worry about it. All right. People like CSS, I would really be great to be able to set... I would really love to see a good mobile UI, CSS, just style sheet, mobile UI style sheet. There's certainly a lot of good stuff out there. Bootstrap has good mobile stuff, but they don't have the kind of UI components that I was working with. And you know, like the style sheet, I think we're pretty feature-complete on this application. Our style sheet, like our actual custom styles are 300 lines of CSS, maybe. You know, we've got normalized CSS, and then our style sheet, and that's it. It's interesting how much shorter CSS is once you have the power of CSS3 available to you. It's totally wild. And the style sheet will probably triple in size once we start supporting non-webkit. Right. So right now it's only WebKit, and so all the gradients look wrong on the Windows form that we're testing on and on the Opera and Firefox. But I mean, that's compared to, like, when I went through the jQuery mobile themes, they were just really wrong, and you had to use JavaScript to apply the styles. Right. Yeah, it's interesting. I know there's a lot of interest in jQuery mobile out there, and I really appreciate what they're trying to do, but I think in trying to serve all of those masses, it kind of ends up not as useful for more narrow needs as you might hope. At the same time, I mean, they were in the game really early. The jQuery mobile team did amazing research. I mean, I spent a lot of time on, like, you know, 2,000 word-long issues on the jQuery mobile GitHub about, like, there's one bug in Android that I was running into that the solution was discovered through the process. So it's definitely a huge amount of value to the community. Yeah. And the styles are really cool. It's good for prototyping. And it takes some way for me to, like, some good way for me to take data from the server and initialize the state of my app with it in jQuery mobile without having to construct DOM elements. Like, you know, that would be good. But I didn't really feel like making back on views that were, like, different jQuery UI components, jQuery mobile UI components and so on. Because, yeah, that's what, like, with these mobile apps where they can kind of, like, what you're talking about is an app that can basically build itself from this data, right? And that's not the jQuery mobile philosophy. The jQuery mobile philosophy is you start with HTML and enhance it. That it applies, that jQuery mobile implies is that the people who are offering the content and the views are writing HTML. Right, right. So it's... Sorry. It's hard to not cut each other off because we're, like, half a second delayed. With this app, you're more... Yeah, you're building it. Like, it starts out with an empty index HTML, basically, right? So there's actually no... Yes, the index HTML is completely empty and when you load that page, there's one style sheet and one JavaScript file and that causes everything to happen. Right. And... Right, so our customer is not the kind of customer that they can have people writing these HTML pages that they're putting in there to hide and show. You know, our customer is building apps that they're going to have 17 content authors, 70 content authors across their organization that are, you know, administrators, non-technical people. So, yeah. You know, and Sencha has an app builder thing like this, I think I saw. But we weren't about to, you know... We weren't... Yeah. Sencha has some issues of its own. So that kind of leads into, you know, part of what has come out of this project is this backbone route filter project that your backbone plug-in that you released. And so I wanted to hear about that, but I also wanted to talk about, like, how clients live. Like, does this client feel about the open source nature and open source being kind of a driving philosophy? Yeah. So let me talk... So, yeah, I released a plugin called Backbone Route Filter, but it was a week and a half ago now and released another minor version of it on Monday with the help of Brad Dunbar from the Backbone Project, which is kind of a rewrite with API, matching API, all the units that are still passing. I think the two users that we got didn't, you know, it still worked. It still worked in our application. So, but yeah, let me describe sort of how the flow of this application we're working on, basically the way it works, is what caused us to need this route filter. So let me describe the flow and how this application initializes itself, and then I can describe the plugin and how it fits into our philosophy and our workflow. Yeah? Yes. So, like we're saying, we have essentially no data about the application itself in the application. Everything comes from this, you know, it could be a single big JavaScript object or JSON object from the server, and that JSON object has everything from all the laying information in it for like, you know, if you wanted to do multilingual to what the first page is going to be, to, you know, what the first view that the user sees is going to be, to every other view that's going to be in the application and all the state and all the interactions between the views. And from that, we initialize a big, like I was talking about earlier, a big backward model memory that oversees the whole state and is responsible for keeping track of itself offline. And for that reason, this template is really flexible, so lots of applications can be built with it. Also, for that reason, it allows us, it makes it easy for us to build offline applications which is important for Melbourne. One of the things that you have to do when you build an application that way is you have to, for a web application that way, is you have to route, you have to programmatically build all of your routes for the application based on this data that users wrote. And so essentially the way that our router works in our mobile web application template that we're building here is it's just a single wild card route that looks at where the user has routed to and parses that apart and tries to figure out what content to show. And for those of you, so we're using the Backbone Router to do this and the Backbone Router works like every other router. For those of you who haven't used it, you know, you essentially have a routes table with handlers for those routes and those handlers for functions where you handle your route. And that handler function is, you know, it's a callback that gets information about where the routers tries to match it and do the right thing. I was just going to pause and say, so in a normal app where you aren't building the app from a JSON file, then you would have like a home page route and a user's route and a route for an individual user maybe or that sort of thing. You can initialize a user's list to view it around what you initialize. You know, we'll get an ID password using slash user slash one and pick that ID and it will go find that user's data and initialize it. But here what you're doing is, we just, you need a route that just handles arbitrary content. You don't really know what the structure of the app is when you, like you can't write a route. You don't want to write a router for every single app. You want to write one router that works for all apps that use this data structure. Right. And so what we've done is we've created a syntax for describing views in JavaScript objects that tell you what their content is and what kind of layout it's going to be. Types of views that map to layout names in our JavaScript app. So on our wild card route, the route comes in, it looks for a page. If it finds the page based on the route, it says, what is your layout? And, okay, that's your layout. I'm going to look for your layout in my views table. And I'm going to initialize a view using the page data that was found based on the route. And I'm going to just initialize that path. So that's really, really elegant and our router ends up being 31. So you have a page, a page of content that says, hey, I'm a user page and then it goes and looks up what views to use for a user page. Is that kind of the... Right. So, well, I'm a user. I have a page that's coming in. Here's all my arbitrary data. And my layout is user profile. So we have code in our router that says, okay, this is the page. We got the page. What is this layout? Okay, it's a user profile layout. Go and get the user profile view and instantiate it passing in the page that we just got. And... And so this is cool because once you make this work for... One. One app. This will work for all apps. It doesn't... So we built this one and we built like six different kinds of layouts for the dealing of the first app we're building. But then anybody who wants to, you can just go and write a background view module using like, indeed. Right. And... And it would be available in that big views table then. And it could deal with... So they could just write a background view, AMD module, and a template for that view or use an existing template that we already have. And you have a new layout type that somebody can declare and it just expects certain properties to be on the page. Right. But, so this is all great, but what happens when somebody navigates to a page that doesn't exist? What do you do? So... In order to deal with that in our route filter, what we wanted to do was have a... Basically a pre-filter for that wild card route that would run right before that route was going to try and run and figure out if it was going to be possible to get the page. And then, if not, say, sorry, we can't get this page. It shows something more meaningful than either an empty page or, you know, or, you know, a JavaScript error. Right. He wasn't going to be able to throughout this thing. So this plug-in is out there. It's on GitHub, right? So this is... github.com.pl us under. I think it's the top one right now. Yeah. We'll make sure we put it in the show notes for this. And how does the client feel about releasing work that you're doing for them? So before I wrote this plug-in, I said I had, you know, probably 100-something lines in the route filter... in the router figuring out the different scenarios and what to do with them. And I had a not-found route that I would route to and all of this stuff. After writing this route filter plug-in, which lets me give up a forehand just to run before every... every route's routed, we're down to, like I said, I think 30 lines of code is much more manageable. It's much more readable. And we've abstracted the pain of dealing with this problem out into a plug-in that's independently supported that has, you know, 20-something unit tests, because it's a very small plug-in. That... and first of all, by abstracting out into a plug-in, that users of the web... developer users of our web application... mobile web application template are not going to have to see or deal with, makes the code more maintainable. So our customers are very happy about that. The fact that it's open source also brought in additional benefits. So it makes... sorry, it makes the code more maintainable and generally it makes it so that we're composing different pieces. You know, really good separation of concerns and it's just... it creates stability. It lets different people work on different pieces and the longer it's our unit tests are passing, we're good. Now that it's out for a while though, I've released it, you know, we can have to go and immediately I've got two really, like, major bugs on it for use cases that I hadn't thought. Which are uses of it that our users might want to use down the road, our developer users might want to use down the road for their other mobile web applications that they're building. And so... so I got those bugs, I fixed them and it caused me... fixing those bugs caused me to find a bunch more other bugs and I realized that, you know, and so I improved the quality and stability of the background for themselves. So now our customers' web app template and their web app is shipping much more stable than it would. So that's kind of like the amazing thing about open source, by not developing in a bubble and, yeah, our customers really got it. That's why they hired it. Yeah, so the customers are all about that. They're clients because they're just, yeah. Sweet. One thing I'll say is I would have found all of the problems if I had tried to run Backbone Rafflter against the backbone JS officially unit test themselves in the beginning. Which I didn't do. So, you know, that seems like a no, duh. There's a lot of people, but if it's not, you know, you're running the plugin, you're running a jQuery plugin, install your plugin in a page and run the jQuery unit test. Let's see what happens. That's, I don't, I don't think that, I mean, yes, hindsight, duh, but, you know, one... That was like failing, I think, zero point one free was failing like 70 Backbone Rafflter. But you know that moment of like, it works and it does what I wanted to do in all of my unit tests are passing and so, no, I, you'll get the hang of it again now that you're back in the coding world. Yeah. What's up? Somebody asked a question in Irish. Well, so Dan asked, Dan asked whether this whole Rafflter thing was public and then also Ralph, our friend Ralph Boltzman, asked for code samples of this whole, of all this route stuff. So I'm hoping that we can put together a blog post that goes out with this, with this hangout. Well, I know we will put it together a blog post that goes out with this hangout and hopefully we can point to, point to some examples of how this might work. Yeah. And I think, you know, one of the things that we're going to work with our clients to do is open source our whole template. I think that there's a lot of benefit to them to have this thing be open sourced and have a lot of people be able to support it for them and with them and using it also. We've also, I think we've discovered a lot of really good best practices as we're working on it and so I'd like to see that happen so, you know, maybe, maybe this winter. Yeah. Yeah. So we're working on it, Ralph. Parts to you too. And Ralph, there is a gist that I made for Derek Bailey when he said, oh, why would you ever do that? Why would you use a before filter in a really constructive way? I think so. And so I made a gist. Wow. I made a sample background router use case and I'm pasting entire scene. Cool. And we'll link that up once we put this out there. So I went to ship gears a little bit. I didn't geek out on that architecture stuff all day, but we've talked for 35 minutes already. So I wanted to switch gears a little bit and talk about, you know, you're building this mobile web app, but there's been a whole lot of discussion in the last few days about the future of the mobile web and the future of HTML5 and is it a viable platform for app development? And so it all sort of started. Paul Irish posted a question on Google Plus sometime last week just saying, like, how do we convince people that there really is basically an existential threat to the web as an app development platform? And there were a lot of good responses on that. And then, of course, we had, you know, before Paul posted that, Facebook had announced that they were basically ditching their HTML5 app, but then Zuck doubled down with his much-taken-out-of-context quote about how HTML5 was the biggest mistake he'd ever made. And so there's been a lot of talk about, like, what's going to happen to the web in the face of all this competition from... Yeah, well, I don't think so. That quote from Mark Zuckerberger, I think, was taken out of context. It was, yes. And I think he probably misworded what he meant to say. I don't think he actually thinks that HTML5 was a mistake. I think Facebook just made a bunch of mistakes. And just because they made those mistakes on the web doesn't mean it's the web's fault. Well, the flip side is you've got Twitter saying that they're going to stop developing their native Mac client and start to send people to the web. So... One thing I don't understand is how come neither of these companies can make, like, mobile web experiences? Like... Yeah. That's one of the things that one of the commentaries on Paul's post brought up is that, you know, for whatever reason, it seems to be hard to do this. It seems to be that there are not enough developers who know how to do it well. Yeah. But, you know, you figure that Facebook and Twitter, like, of all the developers there are who know how to do this well, Facebook and Twitter probably have most of them. Yeah. I think there's just got to be some kind of institutional arthritis or, you know, lethargy or something in preventing those talented developers who are our colleagues from releasing a good mobile web experience. I mean, I've been a sales guy for the last few years and I know how to make a stable mobile web. Well, yeah, but you're dealing with... Like, the app that you're building right now is not dealing with a whole lot of transactions. Right. Yay, Boa's frozen again. Or else I did. Oh, it is Boa's who's frozen again. Maybe they lost internet at the office. This is, like, exactly when they lost internet at the office last time. Maybe we shouldn't be harassing people. I'm here. Come on in. You hear me? Rebecca has joined. Rebecca! Are we on the air? Yes, we are. Greg Smith, Ralph Holtzman. Can you hear us? Hi, Jordan. Hi, Rebecca. Alright, talk about existential crisis. So, are we having an existential crisis for the mobile web? Is that what we're talking about? I think so. Ralph was wishing that Adam would come on and tell a joke. The humidity is, like, crazy. I mean, talk about an existential crisis. I mean, come on, it's full. What's going on? Does your mother know that you're talking about Facebook and Twitter like that? Oh, no. So, um, yeah, I think that probably the best, my favorite comment from Paul's, like, existential crisis post was that whoever it was that said, you know, I think a big issue is that the mobile web is, you know, the open web is built by committee, whereas, you know, native platforms are closed proprietary environments where people can just be incentivized by whatever it is and move quicker. Yeah, that was Paul Kinlan, and he said, my view of this is that consensus is driving the web, and consensus is the antithesis of ambition, execution, and speed. Well, I don't know if it's the antithesis of ambition, but it certainly is known to be the antithesis of speed. I think there's a lot of really positive things that come from consensus. But I'm not sure how I think part of the way that consensus is reached today for the open web is a little bit contrived and a little bit unhealthy. So I think that is probably, a walker to, you know, getting there. But I have no question that the open web will win. I don't think we have to have anxiety about whether or not we feel pressure. I'm committed to the open web because I believe in it and its ethics and its morality, but also because it's the right answer. I feel like it'll win, so that's why I build on it. So is that consensus though sort of part of that ethics and part of that morality? Can you have both? Can you have a successful platform and have something driven by consensus and ethics and morality? So I don't think that consensus unto itself is part of the ethics of the open web. Consensus is how we currently police that ethics and ensure that the ethics continues to be built into technology and infrastructure and the standards that make up the open web platform. I don't know if we're going to solve the systems and decision making design of the open web hanging out. It's okay, we don't have to. One of the biggest mistakes I saw in Paul's comment or in one of the comments that Paul said, Paul Irish's was like G plus-ing. I don't know what you call those. Somebody mentioned, oh, Chrome apps and Mozilla store has to show commercial viability and I think that's a real mistake because I feel like web app stores are totally skew-morphic. They're total vestiges of this old paradigm of desktop apps to sort of stretch those idioms across to the web is a mistake. There are other alternative modes for commercialization on the open web and those are the things that we need to discover and the user flow for engaging with open web software are the kinds of things you need to establish and define research in order to help the open web win. Aren't those apps stores just trying to address well, first, they're trying to make money but they're also trying to address findability which is one of the things that people say is so great about native is that you can find and read ratings and reviews and all that and that findability of compelling web experiences is still hard. I don't know what the I don't know what the answer is but if you think about how we used to find software to copy USA and I want that because I need to do this thing and then the iPhone or the iTunes App Store is the first thing that took that and was like okay we're going to apply those idioms to your phone and now we have it on the Mac desktop and now everybody wants a App Store or a marketplace. I hear that so much and I don't think that it makes sense like I don't think that using the open web and the network, the internet work and the web that's built on top of it is so similar to going into a store and buying a box of software but I think that the ways that I don't know how commercial software will work in five years or ten years but it should probably work a lot differently than Apple designed it five years ago. So Greg wanted to know if you can talk about his favorite topic which is ad support versus pay to play and how on Android you're seeing what most like on f-stores period you're seeing a lot more movement toward in-app purchases but on the web we haven't really quite figured out how to monetize anything on the web like ads kind of not so much and they make us angry and then we block them so what's the yeah, maybe you can talk about talk about I don't know exactly what the question is there but what the what the monetization strategy is for web software like I think that's what do you think Rebecca? I don't know I don't know I think that it's really easy to get Greg says the question is what the heck I think that's kind of the elephant in the room question of like how do you monetize the web you know I think what we're seeing is that the web provides a sort of standard digitization of the way that people interact with software the way that people interact with computers so in the same way that like a programming interface like there's a contract between one or two or more engineers of how something's going to work and how you're going to talk to each other and it lowers the resolution of how stuff like software can work a web browser kind of also lowers the resolution of how software can work and it makes like idioms more standard for how to find software, how to launch software and usually what you see when you create a standard is that you've reduced some complexity and you've commoditized in industries when we create standards we commoditize that technology people know how to do it it's cheaper to get done it takes less it's more highly leveraged, it takes less cycles to figure out well same with a web browser it takes less cycles once I once I'm in my web browser it becomes more idiomatic and I spend less brain power thinking about what's going to happen when I double click my desktop I haven't seen my desktop seriously like you know and so I think that there like the amount of value you can capture from a user the amount of cash you can capture from a user changes when you idiomize some of these things because you're not selling them that early stage of the experience and so we'll probably have to figure out how to capture value further down the pipeline of a user's arc in software and certainly some companies are figuring this out like Facebook is figuring out how to create value maybe not as much as their stockholders wish and Google is certainly figuring out how to create value on the web it may just be that like 10 million websites can't you know you can't just throw some ads up on a website and get rich and no one's really figured out how to charge people money for web experiences that aren't porn and so I can command a period on the New York Times home page and article pages really fast now and get around there like paywalls are not super viable on the web because there's always an alternative so yeah I don't know that's it there's so many different industries with so many different historic business models crashing together on the web and then the question is oh well how do we make money on the web like it's so complicated like a newspaper business is so different than like a desktop software business is so different than an entertainment business yeah like a news business, a content business can't doesn't have the personal data opportunities that Facebook has or maybe they do maybe they know everything we read so I guess that's very in and of itself I know that we promise to keep this to an hour and so we're just about there guys do you have anything else you want to add or talk about or promote or complain about any more jokes any more Jewish mother jokes I watched too much Adam Sandler growing up I think, no I mean you know file issues download backbone route filter file issues, grunt it and you know keep your eyes open for more of the stuff mobile web and backbone stuff coming out of Boku on my watch all the time all the time and they if you like these hangouts and stuff then tell us what else you want to see us talk about because we're kind of making it up as we go along right now and so all five of you watching right now can tell us what you want to see next I want to talk to Greg about his guinea pigs yeah I think that should get in the pipeline yeah so cool yeah thank you Becca for talking to me yeah I love talking to you Boats I love talking to you too alright it was good bye bye