 So I've been at Evernote for a year. I was hired to do Sketch Touch, and we were brought in to the Microsoft Early Development Program. So we've actually been running Windows 8 on my personal machine for a year, last February is when I started. So I've been through all the developer preview, all the API changes, sort of all of the muddy water, and come out clean on the other side. And there's lots of awesome stuff about Windows 8. There's lots of awesome tutorials and getting started type things. So the purpose of this talk is not to tell you how to make a beginner's app in Windows 8. There's much better stuff that you can find online than what I'll give you. What I'm hoping to sort of do with this talk is sort of tell you some of the things that you're not gonna see in those tutorials, like from the real world. Sort of some of the stuff that you're gonna experience, some of the stuff you're gonna need to know to actually make an app that's worth using in the Windows Store. And if you love JavaScript like I do, it is a really awesome environment to write code in, because this is really what I consider the first sort of full featured environment where you can do almost anything, your heart desires in JavaScript. I did not know anything about Windows 8 prior to joining Evernote. I had installed it and kind of messed around with it, but I hadn't really done a lot of Windows development. I'm not an old school Windows person. I did the web stuff. I did the ASP.NET, MVC at various jobs, but I have a background in PHP, but my personal passion is web development. My personal passion is JavaScript. And so you don't have to be a Windows person to do this stuff. And that was the whole reason they did that, was to bring in, I think, people with my background. So let's get started. Well, before we get started, the last little bullet point there, dev.windows.com, that is sort of the starting point, awesome resource, tons of good stuff on there. That's where you go when you get stuck. Okay, so when your apps are running on Windows 8, they're officially called Windows Store apps, to my knowledge. And so your Windows Store apps obviously can be written in lots of different languages. And the way that they'll be sort of executed by the Windows operating system is different for every language that you write it in. JavaScript specifically, you're just running an IE10. Sort of the bootstrapping process, the app launching experience is kind of handled by the operating system. You'll just get hooks into your app, sort of like different events that your app is being launched and shut down and suspended. But mentally, you could just think that you're writing an IE10. It is literally the IE10 rendering engine. And you're probably thinking if you're not, like a Microsoft person, like crap, IE, this is gonna be a nightmare, not IE10. So IE10 is standards-friendly, very awesome. If you haven't tried it out, you should go to this ietestdrive.com. You'll probably be impressed by what you find there, really cool stuff. But it's IE10 plus a little bit. So you're gonna have access to some extra host objects, right? JavaScript, the language itself, the ECMAScript spec, specifies certain what they call built-in objects. Those are like your array constructor, your function constructor, your regex constructor. And then the environment that your JavaScript code is dropped into will provide what are called host objects. So most people have mainly written browser apps. So that's a window, that's document. Those are like the globals provided by the browser. And those are all there. But then you'll find extra host objects in IE10. And those will be sort of the native operating system hooks and the native APIs that you wouldn't normally get in a browser. So most of those will be found under a global called Windows with a capital W. And we'll get into that. But the Windows global variable that's gonna show up in your app will have a large hierarchy of object space that will give you access to all the device hardware, the sensors, the navigation, all that kind of stuff. And the second point to make is that your app can now run in multiple contexts. So you're running in the browser, but you have access to stuff the browser normally wouldn't like the user's sort of personal data, the file system, some of the hardware details. And so your app can run in what's called the local context or it can run in what's called the web context. And there may be other sort of caveats with those two contexts, but they have sort of different purposes. So stuff you can't normally do on the web, for example, like cross domain AJAX request, like without the support for cores and that kind of thing, you can when you're running in what's called the local context. So your app, you can just make an AJAX request to google.com from your app and you're not gonna get blocked, you're not gonna get kicked by the OS because you're running like a native app. So you get extra goodies like that kind of thing. But you can also specify that certain chunks of your code will run in what's called the web context and then you'll get it just like you're in a browser and it's like your cross domain AJAX request will be blocked and so you might say, why would I ever opt to run in a web context whenever my local context gives me more options? Well, in the local context, you do have some restrictions. For example, you can't dynamically inject script tags into your DOM and there's sort of all these underlying security reasons for why Microsoft may or may not allow you to do certain things. It's all in the interest of protecting the user, but just know that your app may run in two different contexts. So this thing called the Windows runtime, what is it? So for a long time, Microsoft had a native API called Win32. You may or may not know what that is, but that was sort of the native API for dealing with Windows specific operating system stuff. And then came along .NET, which was an entirely new API, but it was a managed code API, right? So your .NET code would run sort of through this intermediate sort of jitted, you know, compiled thing on a dynamic layer called the CLR. If you don't know what any of this stuff means, it doesn't matter, but the bottom line is there's now a new thing called the Windows runtime. This is a new native API. This is not a managed code API. And the cool thing about this one is that these are JavaScript objects in your application. So this is the Windows operating system. This is the real deal, the whole, you know, the whole kid in Kabuto with some restrictions, but like this is lots of really cool APIs. And generally, you can just think that it's everything in the Windows namespace. So it's windows.whatever in your JavaScript app, that's gonna give you access to lots of cool stuff. Okay, second point. The Windows runtime, which by the way, they also call WinRT. So if you've heard that term sort of floating around, the WinRT is this Windows runtime API. Okay, async. So almost every method that does something significant that could potentially take, I think they've said 50 milliseconds, is only exposed as an async method. So very similar to Node.js in that respect, although it uses a different style than Node.js. So what is async? I mean, everybody may be very, you know, differing sort of skill level in here, but is everybody familiar with async style programming? Raise your hand, yeah, nay? Okay, so in Node.js, for example, when you write some async code, you know, you call a method and then you pass in some arguments and you pass in a callback and then your callback gets executed whenever the method is done. All of the async in your JavaScript apps in the Windows Store will be done using a promise style async stuff. And so I'll pull up my IDE and we'll walk through a little example there, but it's a different style of async programming. And so if you wanna do it, if you wanna do this Windows Store thing, you better learn it. And we'll go through some examples. Okay, and then just in general, you know, the whole purpose of this Windows runtime, these are the extra host objects that let you, you know, talk to the operating system. Okay, so then there's this secondary thing provided to your app called WinJS. So WinJS are, it's like a general purpose front end framework that Microsoft has provided. And so this is not really OS specific stuff, but these sort of package components, it's just like any of the front end frameworks out there. This one specifically will make it look like Windows 8. So, you know, this kind of thing, you know, these grids and these animations and all the tile looking fields, so all that kind of thing. It just kind of comes out of the box with the WinJS style thing. So if you're looking to make a Windows 8 app without a lot of effort, it might be a good idea to use the WinJS components. A couple of points about these, most of them are actually reusable in just a normal browser, right? So if you want to just write a generic web app, which is sort of a big advantage of writing these native apps in JavaScript because in theory, they should be translatable to a browser and you should be able to make both sort of a native and a web version of your apps using the same code base, which is sort of what we're doing at Evernote. And there may be some anomalies and some tricks to getting that to work right, but in general, you can think of this as just a pure front-end framework. What else comes out of here? So another thing really cool that Microsoft has done with the framework that you may not have had to think about before is that they've sort of unified different styles of pointer events. Like this machine that I'm on now, this is a touchscreen laptop, right? So I got my finger on the screen here. So, you know, when you're writing web apps, you're generally not thinking that somebody's going to, you know, both touch the keyboard and the screen at the same time. Or you don't have to think about, you know, handling like a stylus and a mouse click at the same time or things that like haven't really come up in traditional web development. But right, lots of these machines are hitting the market and Microsoft has something called like MS Pointer categories of events. So they sort of unify all the pointer hardware in sort of one event structure. So you'll get an event like, you know, MS Pointer down, MS Pointer up kind of thing. You know, while your code is running and that could mean a stylus, that could mean a finger, that could mean a mouse click or whatever. So you don't really have to think about that. Cool stuff. Okay. So now let's get into sort of what's gonna happen while you're writing these apps. So the first thing that's gonna confuse you or confused me was the navigation model. So the way you write these apps, and I'm not gonna like sort of do too much live coding here, but let's give it a shot. So if I open up Visual Studio, I don't know how easy that's gonna be to see, but I'll zoom in when it's appropriate. So I'm just gonna come out of the box. This is the free Visual Studio Express. I'm just gonna make one of the pre provided template apps from Microsoft. So if you just come in here and say new project, there's a templates, JavaScript, Windows Store style apps, I'm just gonna hit something called the grid app. And it just gives you like a little CSS, I don't know if you could see it, CSS images and JS folders on the right. And then there's a folder over here called pages. And it's just folders containing HTML, CSS and JavaScript files, really indistinguishable from just a normal web app. And over here, here's kind of like the bootstrapping default.js that it sort of generates for you. Don't worry about all the details of all this. That's not the point of the talk. It's that when you run this thing, it's just running in the browser. You're gonna be able to sort of inspect the DOM as you run this guy. And at some point in your app, you're gonna sort of wanna navigate between two of your HTML pages. And in a browser, so what does a browser do when you navigate between two pages in the traditional sense, right? The whole browser sort of tears down the whole in memory DOM and everything and sort of brings in new HTML, new JavaScript, clears out your global context and sort of reconstructs the whole environment with every page refresh, right? In this guy, that doesn't happen. So this is just the default app. I haven't done a single thing. This is just the grid template. And it kind of looks like the window start screen or whatever, so this is running in the grid. But this is just the HTML page that's defined back in Visual Studio here. So if we come back here and look at the default.html, you see that it's including some scripts. It's including some CSS. Looks just like a webpage. And then it navigates to a group page. What? Let me, sorry. Let me get back to the app. So you see these groups. This is just how they do the app. But if I click on group title two, it goes to this HTML page. So group detail would be this HTML page here. So what I just want to show you without digging through all the HTML here is that there's two HTML pages defined in the project. And both of them, if you look sort of at the top of them, they're both full HTML pages. This has a doc type, has an HTML, a head tag, a body tag. And when I navigate to the next one, it has an HTML, a head tag, and a body tag. And so you as a developer, your natural instinct is gonna tell you that it will clear out one of those HTML pages and it will bring in the next one. When in reality, that's not what it's doing at all. The first HTML page that gets loaded into your app sort of stays there forever. And then there's navigation code that's written in JavaScript by the Microsoft libraries. So when I navigate it to that group page, what it was actually doing is it goes in this group detail page and it looks at the inner HTML of that head element and it will look for sort of the diffs between that inner HTML and the existing head element on the page and it will attempt to merge any missing script elements into the page and any style sheet elements into the page. Not obvious to you at all. But it does have some maybe unintended consequences. So this is sort of the in the trenches part, right? So like let's say you have a JavaScript file and during the parsing of that JavaScript file, let's say you have like a console.log statement or something like that. That JavaScript file is only gonna be parsed one time. So if you navigate to that page the first time, that console.log statement will be executed. But now that that file has been parsed, if you navigate away and then navigate back, it's not gonna reparse your JavaScript file, right? So just be cognizant of the fact that your JavaScript files that you include on an HTML page are actually only being parsed one time. Obviously you can call the methods and stuff that you provide on them more than one time, but it's gonna behave differently than a webpage, whereas if you navigate to a page every time, the JavaScript gets parsed every time, right? So it's tricky. So that's what it does with the head element and sort of has those sort of weird side effects. With the body element, it does something very similar. I won't go into all the detail of how it works, but you could sort of imagine it taking sort of the body element, inner HTML, and sort of removing that from the DOM and then looking at the inner HTML of the page you're navigating to and then injecting that. So if you're not careful, you could sort of leave a trail behind. If you're starting to put markup in weird places or you're assuming elements are gonna be left in place inside your body element when they're not, the bottom line is assume that once your app is launched, that DOM is in memory for the entirety of your app. It's never gonna go away. It's only gonna be manipulated from that point forward. So let's go back to PowerPoint. Okay, just the first bullet point in orange up there. Your pages are not served through the HTTP protocol. Because the way the apps work, right, is the user downloads an app from the store, all the markup and resources, everything is locally packaged on their disk. Whenever they navigate, quote unquote, to the first page, it's not requesting those bits through HTTP. It's requesting it through a Microsoft protocol called ms-appx. So if you actually did a window.location inside your app, you're gonna see the scheme or the protocol on the location as ms-appx. And it's that exact thing that puts you in the local context like I was talking about earlier. Now if you load something in an iframe, an iframe, you know, you could load Google.com in an iframe, obviously that will be loaded with HTTP. And so you could see how you could quickly get in a situation where you have different frames running in different contexts sort of within the same app window. And you could even load your own code in an iframe through the local context or through the web context, depending on if you address it, like the iframe source as HTTP or ms-appx. So you sort of have control over what you wanna load in which context, but be aware that everything is not HTTP. And we could do a whole talk on sort of the differences between those, but we don't have that kind of time. Okay, so promises. Let's do a time check. Okay, so what are promises? Promises are really, really a cool thing, but there's something that you really need to buy into to really feel the power and the advantage of programming in this style. So I'm not gonna give a whole sort of like, you know, sample project with lots of promises, but I'm gonna write up a little bit of code just to demo sort of what's going on with these guys, right? And so the purpose of promises, and why are they called promises? Well, that's typically like what the name of the object is because it represents the promise of an async method to eventually finish, or a method, which in theory doesn't have to be async, but you know, in general, this stuff is used with async methods and the way that you'll see them sort of manifest in your Windows 8 app, inside that Windows namespace, you're gonna see lots and lots of methods that end with this async, this capital A async. So it might be like create file async. Whenever you see something end in the word async, one of the methods, that means it's going to return a promise, which means that if you wanna wait until that method is done, you have to use the promise style of waiting. So what is the promise style of waiting? Let's go back to our app. Okay, so here's this default.js. In this file, I know, because I've done this a million times, but like when you bring up that template file, this is just sort of the bootstrap code that handles the launching of your app. So you don't need to know for purposes of this talk, like every detail in here, but all you do need to know is that your app is listening for an event called activated, which will be raised by the Windows runtime. That means your app has been brought to the foreground, and it can be brought to the foreground in more than one way, like somebody could share to your app, somebody could resume it or whatever, but let's just assume that it's being launched. So when your app is launched, I know whatever I put here, this is sort of if the activation, if the activation kind is launched, I know this code is gonna run. So when I launch the app, whatever I put here is gonna get run. So in Visual Studio, you'll get some, you get some IntelliSense, which is helpful. So I'm gonna type when does, you see that namespace there, then I get lots of stuff. So one of the namespaces is called storage, and this is sort of like file writing, you know, all the file system stuff. So there's a storage API, and it has an object called application data, which represents the current user's application data. It's kind of like a static class, so it has this current method, so this is like the current user or current property, this is like the current user's application data, and then it'll have something on here called local folder. And if you see its description of this property is, it gets the root folder in the local app data store. So somewhere on the disk, wherever a user installs an app, you're allocated a little directory structure on the user's disk for their local data folder. So this is their local data folder, it represents a folder object. Okay, now this has a lot of methods on it, and most of them are async. If you can even see in the IntelliSense there, you'll see a lot of async. I'm just gonna pick one called create file async. And so that's what the methods will look like. They'll end in this async word, and then they'll take different arguments. So this one is just saying pass in a string, that's the name. I'll just say like file one dot text, just like an empty text file. Okay, so what did I just do there? I just created a file, but it's an async method because all the file IO stuff could potentially take longer than 50 seconds, so they wanted to make it async. So if I write a line of code, and actually since I had to zoom in so much, I'm just gonna do this, I'm just gonna make a little var here, I'm just gonna say local folder. So I don't have to type out that whole window's namespace. So let's say the local folder is this guy. Okay, so if I put a line of code right here, you know, like console.log, is it done? So the answer is no, right? It's guaranteed to be no because all this create file async did was it kicked off this file creation code. And the natural way JavaScript works is it's gonna sort of loop through all of your code line by line until it has no more events to process, and then we'll say like the JavaScript event loop makes a turn, and then it's gonna listen for more events. And when it finally listens to the event that says the file creation is done, then you're gonna get a callback on create file async. And so the way you do this in Windows 8 is you say create file async dot then, and then you give it your callback. And you just pass in a function here, and there you have it. Now in your callback, inside this then method, the return value is going to appear here. So this is gonna be file one here. And so if this style is not familiar to you, then you're gonna need to get familiar with it because this is the whole Windows 8 programming experience in JavaScript. Lots and lots of this kind of stuff. So I say go do this async thing, then when you're done, I pass in an anonymous function, you can pass in a reference to a function somewhere else, and then the return value from the async operation comes in as an argument of the function. So what happens, so you quickly can imagine that this can get tricky after a while, right? We can ask questions, go ahead. It's the object that represents the physical file on disk, right? And it's not gonna exist, right? Right, so it's like this. Yeah, it's like this, right? This is what's really happening. When you call create file async, you get this promise object. The promise has an API, has a method called then, right? And whatever you give to the then method is not going to be invoked until the file is actually done being created on disk, right? And so every time I call create file async, I'll get a new promise. So I could do it for file two, file three, and file four. Go ahead. There's some intelligence, but the documentation is excellent, you know? You go to the dev.windows.com, the API is super. Yeah, but I mean, it's very, very like, not a big deal. I mean, I've been doing it for a year. Maybe it feels like a big deal, but this is generally like, this is generally a problem in any sort of async programming, right? It's tough, you know, because you actually have to execute the code to sort of know where the arguments are going. Well, you know, whenever I, if you saw whenever I started typing this guy out, right? So when I did, sorry, dot create file async. Yeah. You see this guy? You see this storage file in sort of angle brackets there? It's hard to see, right? This async operation, I don't know if you could see that. That's the return value, right? There's never multiple arguments returned. Promise always returns a single argument. So valid question, right? Of a single type. What's that? No, no, the promise like contract states that you have a single, the return value is a single value. If you need to return more than one value, you just return an object, right? With lots of values. It's always one argument. Yes, right, right? It's like the common JS promises slash a spec. If you read it, it's very clearly laid out. It's a short spec, super short, right? It's like the contract states all, all promise callbacks need to return a single argument, not the promise that's being returned. This stuff gets tricky to talk about in words. That's why I put it in the, because you just start saying promise, promise, promise over and over again. But yeah, so if I say create file async, you'll get it there in those angle brackets, but I thought you were asking where you get it after I write the dot then. Like when I'm down here and I write function open per inch, you're not gonna get the intelligence at that point in the IDE. You'll get it at the point where you invoke the async method. So you very quickly, we don't have to go into too much detail, but you can quickly sort of chain these guys, and this is the point, is you do this kind of thing with them. And so let's say I wanted to create three files, but I wanted them to all be dependent on the creation of the previous one, that the style is inside the callback to your promise, you return another promise. So I can just do it over and over again. And if I do it this style, and I don't know, you gotta bend your mind a little bit, right? But what's happening here? So why would I do it this way? Because now I know that file two will not even begin to be created until file one is done being created, and so forth. So this sort of like is a good way to chain asynchronous things in a way that's very deterministic, but it can get confusing and it can be tricky when you're debugging. So those are just the other, the last point I wanna hit is when you're debugging this thing, you gotta put your break points sort of inside the callback here. You put it inside the code that's within your callback because you're gonna jump sort of through this as you, that's sort of like the progression of your code. You'll get used to it when you start doing it, but if you haven't done this before, your natural instincts are probably not gonna tell you to do it this way. You'll get used to it. It's the same pattern over and over again and you really gotta think about it, but this is just sort of, will save you a lot of time if you just do it this way. Okay, let's go PowerPoint. Oh, wrong view. Sorry guys. Oh! We're good. Let's go again. Okay, we're not good. I apologize. Okay, I'm gonna talk about those more at the end. Time check. Okay, we got 10 minutes. Okay, same code in a browser. So a lot of times what you're gonna wanna do is reuse the code you write because you're gonna put a lot of cool stuff in here. Because the environment forces you to write in an async way, you're gonna get a lot of natural advantages from that is you're gonna be forced to write very responsive code whether you want to or not. You're not gonna be able to block the UI for any reason. I mean, anything that I think Microsoft said will take potentially like in the 30 to 50 millisecond range is gonna be forced to be done async, so you will not be able to sort of freeze the user experience on the UI thread. But then again, a lot of these async APIs, they're not W3 standards. And so what I would say is whenever there's a standards API that does the same thing as the Windows API, opt for the standards if you're planning on reusing this thing on a browser, obviously. But be careful because some of the WinRT things are like faster, because they're on the platform and more tightly integrated. And you gotta kind of take those on a case-by-case basis. We found some interesting things with like the canvas element. We do a lot of 2D graphics type stuff, things that could potentially be slow. And so what we personally did at Evernote was we kind of just wrote like a thin abstraction layer that just sort of depending on either the build or some runtime detection stuff says maybe we're gonna opt for the standards or the Windows version of this API. But sort of the core logic of the code is just expressed using like an intermediate sort of abstraction or sort of an intermediate object that you would use that sort of either calls one or the other. Other things that you're gonna wanna watch out for, you're gonna do a lot of stuff with gestures in your Microsoft app. So you get all the cool stuff, the pinch zoom, the swipe, the inertia, you kind of flick the thing and it kind of flies across the screen. Lots of cool gesture events. You'll get like gesture start, gesture manipulation events and pinch and all that kind of stuff. There are no W3 standards for gesture events yet. There is the W3C has actually accepted the Microsoft proposition. The MS pointer events that I talked about earlier has actually been now formalized in the W3C. So the pointer events will be unified but those are all for a single pointer. Anything that involves like five fingers on the screen, there's no W3C thing for that. So if you kind of app, if you write an app that sort of depends on a lot of that stuff, be careful because that's a tough solution right now in browser world. If somebody writes a library to handle gestures, that would be an awesome one to put on GitHub. I think some people are looking into it but I haven't found anything that's good. And then be careful with file system stuff. It's kind of mixed support across browsers. There's actually multiple file APIs in the W3C. There's one for reading files, writing files and then like accessing the file system and sort of the folder structure of the user. Not all three of those are implemented in any browser to my knowledge fully. They're all kind of piecewise put together. So the same suggestion there. If you're writing code that you're gonna use across different places, sort of make your own intermediate object to abstract that stuff. And then this is my last slide and we can do questions. These are gotchas that I personally ran into. So your source code will be packaged into your app. Obviously it's a JavaScript app. Your source code is not being compiled. It's not like you submit it to the store and then they build it into byte code and deliver the byte code to the client. Your source code is delivered to the client. So at a minimum you want to at least obfuscate, minimize, you know, whatever, minify it. You know, the directories that it's installed in are difficult to get to and the person has to know what they're doing but you know, obviously this is not, this is just like a website. So don't put personal information in your source code in JavaScript. Quick caveat to that one. I didn't even go over this but there's so many things. It is possible in your JavaScript apps to call into native code. So if somebody writes like a library in C++ you can actually invoke those methods from your JavaScript code if it's packaged the right way by the library builder. Something like that might be a good place to put sensitive information or something like that. That's one way around that. Yeah. Right, it's a case by case. There's no like guaranteed, you know, thing but. Yeah, yeah. So, you know, just be aware. These things to be aware of. Localization. A lot of web developers don't ever think about localization. Don't do multiple languages but super good idea just from the very start. Don't hard code any strings into your app. It's very simple to use the localization stuff from Windows 8. You just simply call a method that looks up something in a strings file that you just include with your app. So if you just do that sort of from day one and maybe you only have an English strings file for the lifetime of your app. If anybody ever wants to write another strings file it just all works. So think about that from day one because that can be painful when submitting to the store if you want to submit multiple languages. There's something called the WAC. It's a Windows application certification kit. It's just an app. It's a thing you can run locally that will inspect all of your source code and make sure it's all ready to be packaged to be submitted to the store. If your app fails the WAC locally it's gonna fail the submission so don't even waste your time. Know what it is when you're building these apps and run it through there. Little things like all your source code files must be UTF-8 encoded with the byte order mark at the beginning. Things you normally don't think about probably. And you'll get rejected from the store for little things like that. Follow the design guidelines. This has nothing to do with JavaScript but Microsoft has a very extensive set of web pages that show you how you need to design your app, where the buttons need to be, what they should look like, sort of how the animation should work. If you break the design guidelines you will be rejected. Don't try and bend the rules. You can't really put one past them. And then no clever tricks. Since you can call in to native code from your JavaScript app in theory you can do some crazy stuff there, right? If you know what you're doing you can use the PNVokes, you can do sort of stuff that to call APIs that would normally be considered out of bounds or off limits by the app store. And so even though technically you can accomplish something through your app since you now have access to the OS even if you can do it they'll detect it in the store submission process and you'll get bumped. So these are just things to save you time. These apps are super cool and I've had a great time building it. Ours is called Skitch Touch. Go check it out. You can see the kind of cool stuff you can do with these apps but you've got maybe a few minutes, I don't know. That's all I got. I don't think anybody's in the room after me so we can keep talking if you want. Thank you very much. Thank you.