 So, I'm back and this time I'm here to talk about how to be lazy as developers, right? Or in other ways, right? One of the hardest things to do as a developer is of course write any application, write any UI or things like that. And then when we end up building yet another UI, so we build for web, then we build for Android, then we build for iOS, then we have to build a desktop app. So on and so forth. And each one ends up being this huge another platform, another code base that we have to maintain that we end up having to debug, having to live with for the rest of our lives. This talk is how do we avoid that? And this is a unicorn that we've been chasing for quite some time. So let's get into it. If we've seen programming languages change and evolve over time for quite some time. So you have the age old CC++, Java, Python, to the world of JavaScript, which is now kind of where we are. The kind of things we were able to do with these programming languages, the kind of UIs that we were able to build, the kind of experiences that we were able to build with each one of these has also changed over time. But what has really not changed is the ask. And in fact, this has increased over time. If you have an application like WhatsApp, you of course have to have it on Android, on iOS. Then because people love convenience, you end up having every single browser. And then you want it for the desktop as well. And if you develop this using our old practices, saying native is best, you end up having one development team focusing on Android, one development team focusing on iOS, another set of web app web developers building out for each of the browsers ideally once. Nowadays, thankfully, goodbye, IE. And then you have your desktop developers as well. This doesn't scale. It's hard. It's annoying. Keeping features in sync across platforms is hard. It's annoying. Right? And this is something that has been a myth, just like unicorns, just like the pot of gold at the end of the rainbow, just like a lot of the rings. And we actually have one code base to rule them all. And this so far has really been extra impossible, annoying, or at least really, really painful without using a ton of hacks. But what if I told you it can be done? We're actually at a point where we're finally able to do something like this, where we can share most of our code base and just focus on building out different UIs, different experiences for different platforms and share the base business logic, the logic that says, where do I fetch my data? How do I massage it? How do I display? How do I format it? All of that can actually be shared. This search, this aim has been there for quite some time. Like I remember searching for this back from 2009, which is kind of where we started with Angular back as well. GWT was the first time saying, can I use Java into it? Google Web Toolkit, you write everything in Java. It compiles down to HTML, JS, never have to change your context. Disaster, painful, but it was the first step. Node made it possible for JavaScript developers to write JavaScript for the front end, JavaScript for the back end. At least you could avoid the context switches of going from back end to front end and vice versa. And then more recently you have things like React and React Native. You have Ionic, which allows you to write hybrid web apps that allow you to write once and kind of deploy on different platforms. The problem is in most of these, what you want to build is a beautiful castle and either the path there is tortuous, takes you through multiple twists and turns. You have a lot of different code bases or you get up with one app that looks really shitty, behaves really shitty. And this is something we've been struggling with for the last quite a few years. Just the number of platforms, number of apps, number of devices have changed, the experience for developers really hasn't changed. And finally, sometime last year with native script and Angular, I could kind of see the light of the end of the tunnel. Of course, given my track record, that light has usually been a train that has come and hit me later, but hasn't stopped me from chasing after that every time. So what is native script? Native script is a platform open source, kind of like a React native for the guys who have been using React native, we'll talk about that in just a bit, but really allows you to write your application once and have it compile, build out a native iOS, a native Android app for free. So what you end up doing, and it's not really specific to Angular, you could use Vue, you could use pure JavaScript, whichever you want. It's not really tied down to make Angular, but allows you to run native Android native iOS and it's native, it's not a hybrid web app that's running in a web view or things like that, you're actually going to give native widgets, native buttons, native labels, so on and so forth. And it's extensible tons of plugins, which always make our life easier because hey, we always want that barcode scanner that Google Maps integration, so on and so forth. All of those are plugins that exist. Now you might ask if you have developed using React native, you might ask, what's the difference? Fundamentally, React native and native script are trying to solve the same problem. They're both trying to allow you to develop once, deploy across multiple platforms, but the approach in which they do it is quite different. So native script actually allows you to write native, access native APIs of Android, iOS, right in your code versus a bridge that React native uses for you. Doesn't really change much unless you have to do a lot of direct integration. Otherwise, it's pretty much the same for the most part. So this is something which could be a native script application code. The left is pure Angular components. In fact, almost nothing that is specific to native script or Android or iOS, what changes is the template. Instead of having your HTML, you end up having an XML that kind of translates to the right UI, given that it is Android, given that it is iOS. But even this is native script code and notice here that you can actually reach out and write raw Android, raw iOS code to some extent. You can actually reach out into Android, get the package manager, do stuff, which gives you that flexibility that you might not have in any other kind of solution. So you get the best of both worlds. You can write your proper application for the most part. And when you really, really have to get hacky, guess what? You can hack away at it as well. So what's the aim, right? So native script out of the box gives you a solution for writing Android, iOS. We don't want to stop that, right? We want to be able to write one code base for Android, iOS as well as web and hopefully at some point, electronic desktop, so on and so forth. When I started this last year, there wasn't a ton of support for this out of the box. So native script gave me Android, iOS apps. I didn't have a great solution for web. So what did I ended up doing was writing my own hacks around in my own build scripts and so on and so forth. So the aim was simple, right? My logic, my component code, which was responsible for fetching data or massaging, formatting it, presentation layer fundamentally needed to be shared across my application. And I needed to be able to write different views for different platforms. Got that out of the box for Android, iOS. I needed to plug in my web application into that. So wrote a lot of gulp scripts, build scripts, basically be to be able to split it apart. And then at build time, pick up the right files, pick up the right templates, put it together, kind of build out Frankenstein of sorts. It worked. We were able to launch with this. It was ugly. Even I didn't know what it did half the time, but it worked. But upgrading was a mess. Native script was going through multiple changes, multiple updates. Angular was going through multiple updates, multiple changes. It was just not very easy to maintain. Every upgrade was a week long nightmare for us. We had a great template. And then I signed up for my talk saying, look, I've got this shit figured out. Let me explain it to the world. And then come August. The Angular guys release a native script Sematic, which kind of said we can do this out of the box for you. Thankfully, the approach was the same. So what does it do? How does this thing kind of work? You're basically looking at your project, your base things, your components, your navigation, your services, directors, pipes, all of these are shared across your entire code base, across your web, across your Android, across your iOS apps. And the only thing that changes between the two are either your styling, your templates or your modules. Figuring out whether to use the native script, STTB communication or the native Android, STTB communication, so different modules, different forms, so on and so forth, or the different views itself. Everything else is shared. And just at runtime is where the magic happens. You have these different template files for different experiences. You have these different styles. When you run it is what pulls in the right things together. So when you're running your Angular web application, it picks up the right Angular web templates, the web styles, the web modules, or just together serves your web application. And just flipping the command to run the native script, which is either iOS, Android, bundling it, so on and so forth, picks up the Android templates or the iOS templates or the common mobile templates, the mobile styles, the mobile modules. And that's the only change you need to do. The command that you use to run it is really the change. The structure takes care of everything else. And setting this up is now trivial. None of my gulp magic, none of my build scripts, none of that craziness comes out of the box, use the Angular CLI to just say, create me a new application with this native script schematic. And you're off and running. Write the right templates, write the right code, and you're off and running. And you have three apps for the price of one. The naming pattern and all, I'll leave it up to that. But basically what ends up happening is you have a TNS, a native script template, a native script style, and your web HTML and your web style. And the component code is shared. You could have a separate one for that as well, but I won't get into that. Everything else, magic. Supports everything you would need. So standard routing, standard HTTP communications, local storage, all of that is available out of the box. You can even lazy load, make your application performant. So all the features of your Angular application in your Android application and iOS application out of the box as well. So that's kind of what we did. It's great for a certain set of things, but a few things to watch out for. If application size is a problem, native script adds a huge library as part of the application. It's entire runtime engine, so the application size is large. And the startup performance, which actually is now a lot better, you can actually launch your application within a few seconds. Used to be pretty bad when we initially started, but still something to watch out for. But otherwise you get a native app for the price of a web app, which is amazing. So that's pretty much my talk. Feel free to ask any questions or reach out to me later as well if you want to figure out how this shit works. Thank you.