 So, hello, I'm Godfrey. You can find me on the internet as a change in code. You might have come across me on the internet as a Rails core team member, or I've also been making contributions to Ember lately. And like Leah said, I worked for a local company called Tether. You might have heard of it. In fact, I recently, like Leah said, I recently moved here from Canada, and Leah told me, oh, it would be great if you can do a talk at Ember Meetup because just, you know, move here from Canada. So I said, OK, great. I will talk about Canada. So I moved here from Vancouver. It's a very beautiful city. If you have not been there, you should find some time to visit Vancouver sometime. This is a picture of Vancouver downtown. As you can see, we have an amazing health care system. So there are a lot of five-star hospital buildings in downtown. And Canada is also one of the largest country in the world. As you can see, we are ranked number two right after Russia. As a result, we have a lot of land. And for example, our parking lots are very wide, as you can see. If you're familiar with the parking spots here, you probably won't believe me that this car is parked. So I took another picture with another angle so you can see there are no one in there. It's actually parked there. And of course, it will be pretty bad if I just show people's license plate on the screen so I make sure I blur it out as you can see. We also have very advanced technology. We invented the original smartphone. And lately, we have been working on self-driving cars. You've probably heard of it. When it comes to self-driving cars, there are a lot of moral issues involved. Because if a dog runs out to the road, the car will have to decide, should I hit the dog or should I pull to the side and maybe kill everyone in the car? So that's some very complex moral issues that programmers today have to deal with. Fortunately, we already have very advanced technology for dealing with accidents on the road. So that's our latest contribution to the technology. And you can expect a lot more from the Canada technology sector going forward. So that's basically all I've prepared. But today, I found out it turns out they actually want me to talk about Amber. So I've prepared a little bit about Amber as well. Literally, I've been working on the thing that I'm about to tell you up until two hours ago. The core request was just merged two hours ago. So I only have two hours to prepare this. So please forgive me if it's not very good. But OK. So the thing I want to talk to you about is fast food and beyond. So traditionally, when you think of Amber, you think of something like this, right? Like this is a skylight and app that we have been working on. But basically, it's like a full page app that takes over the entire page. And it's interactive and you transition within the same thing without having to reload and stuff. And that's great. And that's how Amber 1.0 works. You basically have a script tag on your page that loads Amber and then loads your app. And then Amber waits for a DOM ready. And when DOM ready comes, it boots your app. And your app takes over the entire body, usually. Or maybe you can restrict it to a container diff in your app. But basically, it waits for DOM ready and boots the entire app. And it just takes over the experience from there. So that's what you want most of the time, right? Like a lot of people call it single-page apps or we call it ambitious web applications or whatever. That's basically the primary use case of Amber. And basically, it's like, take over the DOM. We have one true app. Let me do everything. I'll take control of the URL, the DOM events, and everything else. Thank you very much. But it turns out that this is what you want most of the time, but this is not what you always want. So for example, in testing, it would be pretty terrible that you need to test your app and you load your script tag with your app and you had your Q unit harness in there and you load it and boom, like your app took over the entire screen. You can't test it, right? So and obviously, since the very early days, well, Amber itself has a lot of tests, right? So Amber has to test itself. So you solve this problem somehow. And later on in the one point, it's really serious. It also adds a lot more like the ecosystem also caught on to the idea of testing. So that was a problem that needs solving. So basically, you need an emergency brick to stop Amber from like, please stop, please don't take over an entire DOM. I have stuff to do. And that emergency brick is app.setup for testing. If you have been doing Amber testing for a long time, you probably have typed this in your app many times. If you are more recent to the ecosystem and you're using something like Amber CLI, it probably does that for you, but you have to call it somewhere. So basically how it works is you have your script tag for Amber and you have just script tag for your app. And then at some point, you call in testing mode, you call app.setup for testing. And it's basically, actually never mind, I will take it over from here. And instead of waiting for a DOM ready and booting the app, basically, before you run every test case, you would, oh, I have a setup function. Let me boot the app and then append to a fixed area in the DOM. And then when the test case finished, I will tear it down myself by calling app.reset. Again, if you have been doing this for a long time, you probably have typed off that. Lately, some advancements in the CLI ecosystem probably means that it can hide some of these from you. But fundamentally, this is how it works. You have one true app that you can boot and you can have one at a time. And you can call reset to try to put it back to its original state. And that works most of the time, but it's pretty difficult to pull off. As you can imagine, there are a lot of things that your app could be doing in between this step and this step. And having to unwind all of those things when you call reset could be error prone to put it mildly. But anyway, so that was the testing story. And that's the solution the Amber community have improvised or developed to solve the one scenario where you don't want the one true app, which is testing. And it worked out pretty like there are problems, but it worked out OK for the most part. And then later on, there came fastboot. So what is fastboot? So it turns out every once in a while, search engines like Google might try to index your sites. And if you build your app with Amber that requires JavaScript and up until somewhat recently, Google doesn't actually know how to execute JavaScript when it cross your website. So unfortunately, that basically means you cannot return anything to Google, and Google cannot understand your sites, which is perhaps important if your blog website or if your news outlet. You might actually want people to be able to search for your stuff on search engines. So what you actually want is when Google talks to your web server and asks for a page, instead of just returning a blank page, you actually want to somehow return the HTML content of what your page would look like if you have JavaScript enabled. There are other use cases, like there are other places where this is beneficial, like if you're on a slower device, it might be good to return the render page to your phone and then wait for the JavaScript to catch up and then make it interactive. For now, let's focus on the SEO use case. Now, there are a lot of challenges involved with fastboot, like you have to somehow figure out how to run Ember in a Node.js or on a server-side environment that isn't actually a browser. So we will sidestep all of those problems for now and we'll focus on a very specific part of that problem. So you could imagine if you somehow figure out how to run Ember on the server, you could do something like this. When a request come in from the browser or from Google or whoever, you can boot a worker, which basically makes a sandbox environment like a browser-like environment and then you load Ember into a browser-like environment on the server and you boot your app and you render a page, extract the HTML, return it to the browser, return it to Google or whoever and then you destroy that worker. So this is obviously pretty costly because for every web request that comes in, you have to bootstrap a sandbox environment, load Ember, and all the things, which is presumably not very cheap. You can do something a little bit better. You can, for example, you can pre-boot a worker and then you can load Ember into it and you can boot your app and wait for a request to come in. When a request come in, you can render a result, extract the HTML, and then you can call app.reset like how we do it in test, really. You can try to reset the state of your app back to where it is. So now you're ready to serve the next request that comes in without having to boot your app and load Ember. Sorry, you still have to boot your app on every request, but you can avoid loading Ember and bootstrapping a browser-like sandbox environment for every request, which is roughly how Rails and a lot of other web framework works. But there is a problem. So rendering this page might not be cheap. So for example, you might have to make five or six Ajax calls to get all the content to render this page, and that could take perhaps like 100 to itself milliseconds. And while all of that is happening, your worker cannot serve other requests. So if you have a lot of visitors to your site, you would have a few workers or a lot of workers standing by, just in case there's a lot of requests flooding in. But there are actually something you can do better because we're running in JavaScript. Like if you have written any apps, like our server-side apps in Node, then you would know that usually you won't have to do this or you don't need a large number of workers because JavaScript is actually pretty good at handling, like doing multiple things at the same time, while the Ajax request is happening and actually do some work to prepare for the next request and fire off is Ajax request and do a lot of stuff concurrently or it feels like it's doing it concurrently. So because we're running Ember in JavaScript, it feels like we can take better advantage of that instead of having to boot many workers to process the request. So ideally, this is what you want. Basically, you would put a sandbox environment and you would load Ember to it and load your app into it. And for every request that comes in, you want to boot an instance and then use that instance to render. And meanwhile, you can boot many, many instances within the same worker process and serve many requests at the same time. They were just like when one request is blocked by IO or Ajax request, I would just use the CPU time to process another request. And it can do a lot more work with a lot less workers. So that's basically the goal. And in Ember 1.12, Yahuda and Tom and then did a lot of work to make that happen. So basically, the result is instead of having one thing called Ember to application, they split up into Ember to application and Ember to application instance, you might have encountered this concept if you have been using initializers. In that release, you have to break your initializers into application initializers and instance initializers. And they do slightly different things. But the way to think about this is Ember to application is basically the blueprint, or since we're JavaScript programmers, it's basically the prototype of your application. And instances are the concrete thing you create to do your rendering and routing. In other words, all your application states live in the application instance. And the application itself is basically just like a skeleton step. So that happened in Ember 1.12. But there aren't any ways that you can take advantage of that. So from your perspective, perhaps you're just doing a lot of work for apparently no reason because you can't actually make those application instances to yourself. There's no public API for doing that. And frankly, you might not really have any reason to do that anyway. Because if you're using Ember today, you're probably in the one true app mentality. And you just have one app on the page. And in 1.12 and beyond, basically how it works is when on DOM ready, it will boot your app. And then it will boot a default instance for you. And it's all transparent. So from your perspective, it's basically still doing exactly the same thing. And now the reason that this actually happened is, as I said, to prepare for FastBoot, which is a feature that is in Canary behind a feature flag. What FastBoot did is basically they added an API called Visit. So on your application, you can call app.visit and give an initial URL. And it will boot an application instance and navigate that instance to this particular URL and resolve a promise with that instance. So this is great for FastBoot. And if we go back to this slide, you can imagine how it works. Basically, you have a worker. You load Ember. And then you wait for a request. When a request comes in, you call app.visit, whatever URL that request is for. And then it will return promise. Meanwhile, you can wait for another request to come in and go app.visit and give a URL. And it will return another promise. Whenever the promise resolves, you can finalize the request by flashing the response with the HTML. So that's great. And that's basically the FastBoot or slash application visit feature that is currently on Canary. So last week, I have been working on this feature to add some finishing touches. And hopefully, we'll be able to finalize this for the next, like not the release that's happening imminently, but the release after that. So I would like to show you some code of what I worked on last week. But before we proceed, I would like to warn you these are experimental APIs. If you use them in your app, like if you upgrade to Next Canary, they might not be there or they might be renamed. So these are strictly for your eyes only. Please don't type them into your computer. Or if you do, that's fine. But please don't quote me like three months later and like, hey, your code doesn't work. So basically, these are subject to change. And they're still in active development. But consider this a sneak peek. So the work I've been doing is in ProQuest 12394. It's called the Visit API FastBoot. Like I said, it has been merged into Canary two hours ago. So if you are really brave, you can look into that and maybe try that, perhaps. So as it turns out, I have been talking about application and application instances. And like I said today, they're only using FastBoot. And on the browser, there are no really any uses for them yet. But as it turns out, the idea of being able to build many instances of your app based on a skeleton or a prototype or a blueprint is actually useful in many other scenarios as well. So for example, testing, it would be great if instead of, let's go back to, right, so this is the API we have. Like we have today, the API is we have a global app and you can boot it once, exactly once. And then you can do some stuff to it and you can call reset to hopefully bring it back to the original state. But now that we have the concept of application and application instances, we can actually do something better. We can just like FastBoot, we can have in your browser, in your QUnit harness, you can load Amber and you can load your app into it. And on the setup of every test, you can just put an instance and do stuff like within your test to poke at the instance, do whatever, like navigate to different URLs, inject stuff in the container, whatever. And by the end of the test in your tear down step, you can simply destroy the instance and you don't have to worry about rolling back in the state on the global app instance. And there are more use cases for the concept of instances. For example, menu boot. So most of the time you're probably working on a one true app that takes over an entire page. But perhaps you have a marketing website where you want to show off your app. But in that case, you don't actually want it to take over an entire page. You probably just want to restrict that into a tiny box on the marketing page that you can play around within the demo frame. So it turns out that the Visit API is also a pretty good way to expose the primitive concept of application instances publicly. So for example, on your marketing page, perhaps you can import your app file from your thing and then you can create an app that tells you not automatically boot itself and you can point it to the demo page you have written and then render that into a specific root element on the page. And that's all using the same app that you have been working on. Or perhaps you can do multiple instances of your app on the same page. Perhaps you are making a multiplayer game and you want to add a split screen experience. You can figure out how to do that within your app. Or perhaps you already have support for network gaming. So your app already know how to handle multiplayer. So perhaps you can just render two copies of the app on the same page. Like you can make one on the left side of screen, make one on the right side of screen, point them to the same game session and then they know how to communicate with each other. Or perhaps you have widgets on your app. You have many widgets on your app. So perhaps you are New York Times where you have most of your pages server-side rendered. But occasionally you have some data visualization and stuff on the page where you need something more, something more like Ember components to help you organize your code. So is Mitch here somewhere? Oh, he's there. OK, so Mitch, you should talk to him afterwards. He's been working on a project called Ember Islands which solves exactly the same problem. There are other people on the core team that is also working on something similar. Basically the idea is to make it really easy to just render a few components on like contained area within your page. And turns out that application instance is a pretty good primitive for doing that. And perhaps we can expose more of those use cases with the Visit API. You can go to pull requests. There's one more use case. So perhaps you are someone like Intercom where you want to ship a script tag and let people put that script tag on the page and render like an app chat thing on the same page. Obviously in that case, you're not in the one true app scenario. You don't actually want to take over the entire DOM. You just want to render a little mini app that's embedded inside another app. So application instances are probably a good primitive to get us there as well. We will see how far we can get with this. So again, the pull request is 12394. And there are a lot of documentation in there. So again, those APIs are subject to change. But you can start looking at that and poking at it and give me some feedback. And that's all I have prepared for you today. And once again, you can find me on the internet as chenkingold. And thank you very much.