Programming Throwdown - Javascript For Mobile with Burke Holland

Episode Date: November 23, 2016

How to build great mobile apps with Javascript. Show notes: http://www.programmingthrowdown.com/2016/11/episode-60-javascript-for-mobile.html ★ Support this podcast on Patreon ★

programming throwdown episode 60 javascript for mobile take it away jason. Hey, everyone. We're here with Burke Holland, who's from Progress, and he's an expert at doing JavaScript for mobile, and he's going to kind of talk to us about that and how that whole process works. So, Burke, why don't you start by telling us sort of what you do at Progress and kind of a bit about your background. Hello. Yes. Well, first of all, thanks for having me tonight. This is really neat. I work for Progress Software, which is a public company that makes a lot of different pieces of software. I work in developer relations, so my job is to write blog posts and build tutorials and do webinars. And

I go to a lot of events and I do podcasts way, way, way too late in the evening. Yeah. When you're doing the folks at home, when you're doing those tutorials, when you look up some new tool or some cool new technique, and you're learning about how to use it, and you're following the step-by-step tutorial, it's written by Burke or someone like him. That's correct. All of them, yes. Even if it's not my name, it's a ghostwriter. That's correct.

That's right. Totally accurate. I've made an Android app a long time ago, and it was really bad. I mean, the idea was good, but I realized that that's kind of a special skill, and with absolutely no training, the app was just constantly crashing, or you'd hit a button, it'd kind of freeze up. And it was very hard to debug.

I just didn't really know what I was doing. So for people like us who might have done some programming on the console, maybe built a website, done things like that, how is mobile development kind of different? Yeah, that's a great question. And just sort of to baseline this, my background was originally as a web developer, but I ended up doing a lot of C sharp, because that was just the environment that I was in. So I was always in flex or something like that on the front end or web, you know, but then always, always C sharp. So I actually wrote an Android app way back in the day to early on. And it was like a pick a number app where you would just pick a number between one and 10 and it would tell you if you were wrong or right. Oh, nice. Mine was very similar. I published it to the store. Mine was a trivia app where it just,

it asked you a bunch of multiple choice questions and then it just told you if you were right or not. And even that, it was hard to do. Right, I think yours was actually way better than mine. Mine was terrible. And I put it out in the app store for like 99 cents and i thought for sure i would be a millionaire but to this day to this day i get emails from google wallet telling me that i need there's not enough in

my account for them to pay me because it needs to be at least ten dollars so it's been like i know it's how sad is that uh so yeah um, you know, has changed a lot in the past five years, but it generally requires knowing not just a language, but also a very specific operating system and then set of SDKs on top of that operating system. So for iOS, that would be, you know, the Cocoa Touch stuff, UIKit, things like that. And then on the Android side, you obviously have all the Android SDKs and then Java that goes along with that. And then on the iOS side, Objective-C and now Swift, which is really nice.

Gotcha. So how do you, I mean, if you're running a program, you're doing some assignment for school or something like that, you know, one of the things they teach you is the debugger and you kind of step through and you're running it kind of on your machine. So it seems kind of very clear how to do that. How do you do debugging and things like that when you're connected to your phone? Well, I think it depends on the tooling that you use. But I know for like iOS, you know, that has Xcode and Xcode allows you to set breakpoints and debug.

And the same thing with Android Studio, right? Which allows you to put breakpoints into your code and then to step through and debug. So both of the different platforms, you know, we're talking about the big two, right?

Offer tooling, usually free of charge. I think Xcode's free, Android Studio is free as well for people to get into and start doing mobile development. And now there's a lot of training as well. There's a ton of training for iOS, a ton of free training for Android out there. So it's pretty easy to get your hands on the developers. So they've got the tooling so mature where it feels like you're debugging on your desktop where you can kind of step through the code and set breakpoints. But the whole going back and forth between the phone is kind of all just opaque to you. It just kind of works. Absolutely. That's a really good point. Yeah,

that we have these emulators or simulators now, right? So the phone's actually on the desktop and you can simulate location and multi-touch and pretty much every device API that's available. You don't actually have to put it on your phone, which makes the loop, right? The develop test debug loop a lot faster than it otherwise would be. Gotcha. Makes sense. Cool. So, you So, most of the time when you do development on mobile, you're programming in a specific language. Like Android, the operating system itself, a lot of it is written in Java. And so a lot of the APIs, SDKs in Java.

And so to make an app, you typically do Java. For iOS, it's all Objective-C and I guess now Swift. But NativeScript isn't either of those, any of those. It's JavaScript. So what is that all about? Yeah, so I think one of the most frustrating things for people that are trying to do mobile development is that mobile development can make you feel very inadequate very quickly. And the reason for that is that you do have to know so much.

It's not just a language. It's also an operating system. It's also a giant set of SDKs. And if you are able to master that for one platform, you still have the other platform. And we don't really live in the old desktop world of the 90s, right, where you can write an app for Windows and you're pretty much good to go, right? You just kind of walk away and be like, all right, done. That's everyone. Yeah. Especially now.

Right. That is not the case anymore. So now, you know, really, if you have an app that's only available on iOS, feel like really only on iOS, come on, right? And the same thing on Android. So if you want to have a successful, especially consumer mobile application, you really have to hit both those platforms. And then the second one is that most companies today have bring your own device policies, right? So you used to have these draconian sort of mobility policies where everyone got a Blackberry and you just sort of dealt with it, right?

And you didn't complain, right? You're just glad to have a mobile phone. You had two or three or four phones, so everyone thought that you were doing something shady. Right, that's because if you were super important, you had like the bat belt of Blackberries going around you. But now, people bring their own devices because they're so personal. And so even if you work in an enterprise and you're doing mobile development,

you're likely targeting not just different operating systems, but different versions of the same operating system. So it's really, really frustrating. So the problem that NativeScript tries to solve is twofold. The first one that it tries to solve is it tries to bring everything down to a very common language that most people understand, and that's JavaScript. So, you know, JavaScript, love it or hate it, it's been around for a long time. It's not going anywhere. There's a lot of different opinions on it, but it's one of the easiest languages to learn due to its extremely forgiving nature. And it's ubiquitous, right? So once you learn it, you can write it on the web.

And then with NativeScript, you can also create native mobile applications with it. So that's the first tenet. And then the second one for NativeScript is that the same project should be able to run on iOS and on Android. And when you run it on iOS, you should get a native iOS app. And when you run it on Android, you should get a native Android app. And all of that should be in the same project so that you're only learning one set of tools, but that you can target all the different mobile platforms and different versions of those mobile platforms as well. I see. So there's, I guess, a NativeScript runtime, if you will, for all these different platforms, and it finds some way to translate your intent from the JavaScript code into native experience. Exactly what it is. That is exactly right. I don't know that I've had anyone nail it that early on before in the description, but

it's a runtime. It's exactly what it is. And basically what it does is it takes a virtual machine, so a JavaScript virtual machine. So for Android, that's V8. And for iOS, that's JavaScript core. And it takes this virtual machine. And normally, if you have a browser, like Safari or Chrome or Edge,

you have a virtual machine that executes all the JavaScript. And then that virtual machine knows all about the browser via something that we call the DOM or the document object model, right? And so this allows you to use JavaScript to actually manipulate the page or query items on the page. So the DOM, for people who don't know, the DOM is this tree,

and you can actually see it. If you go on any website, you can do view source, which, how do you do it in Chrome? In Chrome, you go view, and then developer, and then view source. And you'll actually see this,

you know, it has just an HTML tag. That's the root. And you can actually drill down, you know, it has just an HTML tag. That's the root. And you can actually drill down. There'll be a head tag and a body tag. And the body tag will have more tags. And everything you see when you go on a website is part of that sort of tree of HTML. And that's called the DOM. And JavaScript lets you sort of interact with that.

Yeah, that's exactly right. And I remember when I was first learning web development, I would read that word, the DOM, and I would be, I don't know what that means. And it really is exactly that. It's just the HTML that exists on the page, but it's also the different APIs that the browser exposes to interact with that so that you can programmatically

manipulate the page with JavaScript. Well, in NativeScript, there is no HTML, right? Because we're not building websites, we're building native mobile apps. So instead, what NativeScript does, it says, okay, we don't, there's no browser here, but there is a mobile operating system. So instead of the DOM APIs, I'm actually going to inject all of the native APIs into this virtual machine. So what that means is that once you're inside the NativeScript runtime, you can call any native API just using JavaScript. So instead of doing, yeah, so on the web, you may do document.getElementById,

which would select a div that has a specific ID. Well, in NativeScript, you can say var color equals uicolor.init with whatever the method is in iOS. And it'll actually give you a native iOS color object and store that for you in that variable. So you can create, yeah, you can create buttons this way and text fields and labels and all sorts of different UI elements. And you can also call any programmatic API that you need to. Gotcha. So if you're using native script, is there sort of an equivalent of HTML? Like, in other words, if you're building a website, you have HTML, like static HTML, that just kind of describes, you know, the placeholders for everything.

And then you have JavaScript that kind of injects all the content. And that way it's like your code doesn't have, you know, color equals green and stuff like that in the code. Is there some equivalent for NativeScript where, you know, the skin, the style is kind of separated from the code? Yes, yes. And it's XML is what's used and i always cringe a little bit when i say that because i think everybody's like a little bit you know xml is like violence if it's not working you're not using enough of it i think is the the old saying about xml like nobody ever used xml and was like oh that was awesome let's do it again yeah but it's really because in the past, you know, we used XML to transmit data, which is not really what XML was designed to do.

If you go back and read Tim, what's the guy? He used to work at Apple, was on the XML consortium. Anyway, his point was it wasn't meant for, it was meant for documents. It was not meant for. Tim Bray. Yes, Bray, him. And so anyway, his point is it wasn't meant to send data around yet. That's what we did with soap protocols and whatnot.

But it's actually very, very good for composing user interfaces because just like HTML, it's a markup language. In fact, they're very, very, very similar. And so NativeScript uses XML tags to mark up a page. So for a NativeScript page, you would have a page element, right? So page XML tags. And then inside of that, just like with a tree, with a DOM tree, you would have some sort of layout, like a stack layout or a grid layout. And then inside of that, you would have a button or a text field or whatever you had.

And you would compose your page with these XML elements. And then at runtime, NativeScript parses that XML file and creates the native equivalent components for you so that your screen is laid out and you're not doing all of that via code. Gotcha. That makes sense. What about CSS? Is there like an equivalent to that? Yes, there is. NativeScript tries really hard to stay close to web tenants. And so when you go to style components, NativeScript implements a subset of CSS properties. So it can't implement all the CSS properties because there's a ton of them and not all of them are applicable. But I think it implements like 90% of the most used properties. So things like padding, margin, border, opacity, gradient, things like that.

And that's how you style the components. So you actually use CSS and style sheets. So if you had a page called main.xml and you had a file called main.css those two files are automatically matched up by native script and then you can use classes and ids and regular css selectors to select elements and then style them with classes the way that you would html gotcha that makes sense so what happens if there's something uh kind of specific i'm trying to make an example like force touch on ios um i mean in that case you know if if there has to be some kind of function that i guess does nothing if you're on android you know i mean like there's there's basically

incompatibilities between the platform how does native script sort of reconcile that right so native script has its, it has a base abstraction layer to which it abstracts a lot of the touches that are universal. So things like tap, double tap, long press, two finger tap, things that you'll find pretty much across all touch devices.

And there's a laundry list of those. So those it provides out of the box and it normalizes those across platforms. But there are certain interactions like, for instance, there is force touch. Well, force touch exists in iOS, but does not exist in Android. So for that scenario, you would use the force touch plugin. So all of our plugins are delivered via NPM, the NPM registry, because they are JavaScript. And so if you just go to the npm registry and do natives and search for native script you'll see there's like 300 and something plugins and so the community folks in the community what they do is they take these native libraries and

then they wrap them with javascript and then deliver them to people so that the people consuming them can just use the javascript they don't even have to call the native apis they can call the javascript abstraction so for force touch there is a plugin for ForceTouch. There's also one for Touch ID, which is another one that may or may not be available depending on the device you're on. Then NativeScript

is very platform aware. What that means is that we understand that when people are building applications, there's going to be all sorts of issues like this between the different operating systems where they're going to have to target a specific feature for a specific kind of device. So it's like force touch is the example. So anytime in native script, when you want to do something that's iOS specific, you can say if iOS, because iOS is a global variable, right? And NativeScript just, yes, it's always aware.

And then it also allows you to do that in a couple of other different ways. If you have like a, say you have a main page and you have two different main pages, one for iOS and one for Android. If you call that main page main.ios.xml and main.android.xml, they will only be loaded on those,

on the applicable platform. Same with the markup. Same with the markup. If in the markup you prefix an attribute with iOS or Android, that attribute only takes effect on one of those two platforms. Gotcha, that makes sense. Yeah, so in any real life scenario, you're only gonna get so far

before you really wanna take advantage of device specific features. Man, that was hard to get out for some reason. Yeah, that's a good answer. Yeah, and Nittyscript knows that, and so we try to make it as easy as possible for you to say, okay, now, in this case, do this thing, and if it's not there, then just don't execute this block of code

or don't show this piece of UI. Gotcha, so the idea is if you're doing the basic thing, like if you're making an app to calculate the tip at a restaurant or something, then you'll almost certainly just stay within the APIs that support all the major platforms. But then if you have to do something like in-app purchases or something really specific, then there are plugins for that. Yeah, absolutely. And I think that, you know, forms over data, which is really in mobile development or in development in general, a lot of what we're doing is solving the same problems over and over and over again.

Especially if you do enterprise dev or you're primarily working with large data sets, you're primarily taking data, displaying it, editing it, and then visualizing it in different ways. And so when it comes're primarily taking data, displaying it, editing it, and then visualizing it in different ways. And so when it comes to forms over data, which would be like text boxes and buttons and labels and displaying data and sending it back to the server, all of those things are in the NativeScript framework.

But what's really cool about mobile is there's so many awesome things that you can do with mobile. I mean, there's so many different features that you can use. You know, there's accelerometers and there's, you know, there's force touch, there's screen rotation, there's all sorts of cool things. And as a developer of mobile apps, you want to be able to use all that stuff because that's what makes it so amazing. That's what makes apps engaging. It's not text boxes and labels and buttons. It's all the cool things the mobile platforms can do. And so once you want to expand into that area, that's when you begin to use those plugins for each one of those things that you want to target.

Or you just call the native APIs directly from JavaScript, depending on which one you're more comfortable with. Gotcha. That makes sense. So, you know, there was at one point there was this sort of Cambrian explosion of JavaScript native utilities, right? So there was AppCelerator. There was, I think, something from Intel, or maybe Intel bought AppCelerator. There's NativeScript. There's React Native. There's probably a bunch of others that I can't think of off the top of my head. But sort of, I guess, you know, I haven't been following it in the past few years. So what happened to all these different alternatives

and what are the pros and cons of each of them? Well, I know that for AppCelerator, and I don't know as much about AppCelerator, but AppCelerator was the first one to try this sort of approach and strategy. So really, NativeScript and React Native are standing on the shoulders of Accelerator to a degree, right? Credit where credit was due.

They were pioneers in that space. However, a lot of times being first, you get to find out all of the stuff that you might not necessarily do if you could do it over. And then all the people that come behind you get to go, okay, well, we're just not going to do that because that obviously doesn't work. And so, you know, an accelerator is still going strong. There's a lot of great, fantastic accelerator devs out there

and great apps. So I don't know as much about it, but it is similar to NativeScript in so much as there's a JavaScript virtual machine in there somewhere. React Native is probably closer to NativeScript because this is sort of the new generation of what we'll call JavaScript. We call it JavaScript Native. There's not a real good piece of terminology there, but that's generally what we refer to it as. But it also uses a JavaScript virtual machine. The difference between React Native and NativeScript at a fundamental level is that

React Native does not try to wrap the entire operating system so that you can access it from JavaScript. Instead, what it has you do is it has you build your right native code in Xcode or Android Studio, Java, or Objective-C Swift, and then expose that via a JavaScript wrapper, then import that into your project. The second thing is React Native. Wait, can you repeat that one more time? I think my brain just melted. So you write something in Swift, and then it goes to JavaScript with React Native?

Yes. And I'm sure someone's going to write in and tell me about how this is well, actually, right? This is not exactly correct, but as I understand it, if you have a specific native feature that you want to access, all right, so let's say there's some API. Let's say you're working with

HomeKit on iOS. And you built some plugin to control your lights or make your garage or go up and down or whatever. So you write that native code in Objective-C or Swift. And then there is a bridge between JavaScript and native code that React Native uses similar to how we do it. But then you have to take those two things and import them into your project. So you take the native code and you take the JavaScript wrapper that's gonna call into that native code and you bring those in and then you can access that API.

So how is that different? The difference with native- Oh yeah, go ahead. So, well, in native script, you don't have to go out and write that native code. You can just call it from JavaScript. Which I know is kind of confusing. So there's some kind of translation.

Like if you say function X, it doesn't matter. Like if they make a new function, there's some way to represent that in JavaScript already. Yes, yes. So like I said, earlier we talked about using like a UI color, but if you did, like let's say you were using a button, you would say UI button init with cgrect or whatever it is, cgrect 0, and your JavaScript would actually look like that.

And then Natascript would marshal the underlying button object and give that back to you. So you really are writing Objective-C APIs, but you're writing it in a JavaScript form. So there's no bracket syntax. It's just JavaScript. Got it. Okay, that makes sense.

And so I guess, so I see. So you have some layer that abstracts iOS and Android, but that layer itself is also written in JavaScript. And under the hood, it uses your lower level magic for me because I only know technically so far, but at some point it turns into like C++ and assembly code to make that transition, right? And in order to be fast too, because if you jump from JavaScript to Objective-C to bytecode, you take a performance hit each time you move between those. Gotcha.

And so in order to be fast, we try to go directly to assembly when possible. Right. So there's a lot of that that goes on behind the scenes. That's part of the runtime. Gotcha. So basically, if you're at home and you want to use JavaScript to make an iPhone and an Android app, don't do it yourself. It's really hard.

Use native script or React Native or one of these tools. Right, yes. It's one of these smart runtimes, if you will. Yes. And that's the idea, right? Is that we put all the work into the runtime and then the runtime basically abstracts out

and makes this very graceful, very normalized, very sane way to write cross-platform native mobile applications. Gotcha. So kind of playing Dell's advocate here, I mean, there's Apache Cordova, which I think used to be called PhoneGap. And there's some other tools like this, where you can take a website and effectively wrap it into an app where the, when you, you know, it looks like an app, like you have the icon of an app on your home screen. And then when you open it, it's really just opening a browser, but without the address bar. So, you know, you can't really tell it's a

browser, but it's, it's actually just a web, you know, your website on the phone. And so just why, why isn't that the Holy grail? You know? It seems like you could just take your website, use PhoneGap, and wrap it into this app, and then you're just done. Well, it would sure be nice if it worked that way. Unfortunately, and actually the way we ended up at NativeScript is, and I have to be careful here, because hybrid is a very important piece of technology and it's still very relevant. However, the use case, I think, is not what it once was. So progress makes developer tools. That's what we do. And so part of what we do is we make mobile developer tools. And at one point in time, we had built all of our tooling on Cordova. And what we discovered was that Cordova could build applications and 80% of your time would be

spent building the application and it would take you like an hour right and it would be amazing because all your web skills would just work and then the next 80% of your time would be spent trying to make this thing just behave right trying to make button click events work, trying to make scrolling work. Scrolling would be incredibly janky, especially if you were using images, it would flake out, it would lock up, offline was weird. And this is because you have all these different browsers on these different devices on these different operating systems. And all of them are sandboxed from the device itself. because device makers don't want to just allow full device access to anything on the web

because that means you could load a webpage which could just grab all of your CPU and all of your GPU and drain the battery on the phone in like five minutes flat. And people aren't going to blame the website, they're going to blame the device, right? They're going to be like, my battery sucks.

And so what they do for these mobile browsers is they make them very restricted. And so they don't have full access to the GPU. They're not a first class citizen. And that's really to protect the operating system and protect performance. The bad thing is that the web suffers on mobile. It just does. And we've seen this over and over and over again, right? Like people that put too many ads in their site, or there's too much data on a site and you visit it on a mobile device and you're like, God, this is so bad. I just want to download the app and have it just work. Yeah, it's totally true.

I mean, even the people who try so hard to get it right. I was on Reddit on my iPhone and I was on the web version. I went through the Chrome app and it was just bad. And you can tell that Reddit put so much effort into it because it was just so much better than any other mobile site I've ever seen. But it just didn't work well. Like the loading, the little loading GIF was duplicated.

There was like two spinning boxes and just like weird stuff like that. And I was on an iPhone. I wasn't even on a particularly esoteric device. Yeah, that's very true. And you know, there's folks that work on the Reddit team. They're so bright. These are some of the smartest developers out there.

And so if you're out there and you've built a mobile web app or a hybrid web app and it is slow or it doesn't function like you think it should, it's not your fault. Let me just be the first to say that. And I think that web developers think that we should be like these performance experts, right? Now, not only do we need to know the web platform, but we also need to be experts on like waterfall charts and all this stuff in the developer tools. And I've watched session after session after session, and I still don't understand what's going on

in these perf tools as much as I've tried to do these audits and things myself. And so developers typically blame themselves because we know everything is possible. And so when we build something and it doesn't work right, we take it and we internalize that. But the truth of the matter is that, you know, your feet were tied from the get-go

because you tried to build a native app inside of a web view. And ultimately, it's not going to work out for a myriad of reasons. Yeah, that makes sense. There's also this weird uncanny valley where, you know, you hit a button and it doesn't really slide. I mean, it looks like an iOS app, but the button doesn't slide. It just teleports to the on or off position. And when every single UI element is just a little bit off, it kind of puts you in this really weird state. It's almost worse than if it looked completely different.

Yeah, and, you know, hybrid apps are an imitation of native apps, right? So by definition, they are an imitation. And a lot of times, the second you can tell something is an imitation, you're like, cool, whoa, wait. Those are not real obelisks, right? Uncool. And so it's the same effect there. But we should point out that, look,

hybrid apps still have a really valid use case. Brochure apps, apps that have, that are very simple, that have just a couple of screens. You're not doing a lot of moving around, not a lot of animation, not a lot of data. Perfect for those types of applications. And they're great for prototyping because you can build them so fast, right?

Hybrid is still the fastest way to build an application. Unfortunately, it's not one that you can ship ultimately, but when you're building out a POC, hybrid apps are great for prototypes. That makes sense. So Unity is really popular. They have a ton of the market share on games and things like that. And Unity lets you deploy to different platforms and they have kind of a UI. And so again, Dell is advocating, why wouldn't I use Unity and, you know, deploy my app that way?

Well, Unity is targeted at games, though, right? It's a gaming. Yeah, I think it can deploy, but you're right. You're drawing. You don't really have any UI there. Like, you're drawing it all yourself. Like, you're drawing pixel by you don't really have any ui there like you're drawing it all yourself like you're drawing pixel by pixel or picture by picture yeah unity isn't trying to make a look like a native app right all the unity games i played the buttons are all like game buttons

right oh yeah that's true yeah so it's it's it's a different purpose it's really hard to make a ui and then when you do it's you do, it's way too low level. It would take you forever. I don't know that it's hard to make a UI. They're just not trying to make it look native. I don't believe they're using native components. It's like a drawing framework. I guess it's OpenGL.

Everything is being drawn to the screen. Yeah, you're drawing a HUD, a heads-up display. For some reason, I thought that the UI part of... So that's really hard then, never mind. Because, I mean, so then if you want, you know, I mean, getting a little bit off topic here, but if you wanted, you know, a button in Unity, you literally have to draw an up position button

and a down position. Like, there's no way to get a button from the OS itself You know, I mean like it's just a different use case for mobile apps, right? You probably wouldn't write Pokemon go with native script. Oh, you could unity would be a better choice there But you probably wouldn't use unity to write an application which keeps track of inventory and shows you charts and graphs Which you can then export to email. Gotcha, because there's so much of the UI you'd have to write yourself, it wouldn't look good.

And you'd be better off writing to apps or using NativeScript or React Native. Yeah, correct, something that you were more familiar with. And obviously the idea with NativeScript and React Native being that you can use JavaScript to do that, and that's the language a lot of people know. They already know how to make an AJAX call with JavaScript. Well, you can make that same AJAX call in NativeScript. They already know how to use local storage. Well, you can also use that in

NativeScript except in NativeScript it uses core data. So all these concepts that people have for the web translate directly to mobile, but end up giving them the app that they wanted, not the app that they were stuck with. So maybe to ask your question, Jason, in a slightly, well, not the same question, but a slightly different question, a similar vein is, you know, we've talked about why NativeScript or, to be fair, React Native work well, but when is the time not to use them? So you kind of pointed out hybrid app is good for relatively simple apps what about like on the complex end what is a sign that your app is maybe too complex or too performant or something and you should consider writing breaking down and writing actual native code i don't know that it's as much an issue of size and performance because you do have native these

are native apps that you're getting with react native and native script right so closing the gap there I think it's more a question of skill set so does your company have a mobile a mobility division with stacked with iOS and Android developers if so you should probably just build native mobile apps because you already have the skills in-house. They're already there. If your company, like a lot, doesn't have the luxury of having that sort of skill set and you have a couple of developers who are tasked with doing everything, right? They do the web. They do desktop. They do mobile.

They do database administration. They write queries. They build reports. They do everything, which is that's by and large most people out there, then you're going to want something you can't afford to build those native mobile applications. So that's when you would go back to native script. So it's really just an issue of skill set and the tools that you need and what's available, I think. Yeah, that makes sense. Yeah, I think the... Oh, did we

lose Patrick? Are you there, Patrick? Nope, I'm here. Oh, okay. I heard a weird buzzing. Anyways, so, I mean, this is a really hard question to answer, I guess, but, I mean, I think around maybe... There was a time where a lot of companies were doing the web thing. I think around maybe there was a time where a lot of companies were doing the web thing.

I think like Facebook was one of them. The Facebook app was all HTML. There's some other companies where that was the thing. And then kind of people moved away from that to writing native apps. And then I feel like NativeScript and react native is kind of the third sort of generation of that where a lot of companies as you said companies who don't necessarily have the expertise or want to kind of move quickly and develop on both platforms we'll use that what do you think is is next in other words like what's what if if you could

predict the next paradigm shift what would it be be? Oh, that's a great question. Well, I actually think that, well, let me say, let me speak for NativeScript first and then maybe for the industry. For NativeScript itself, right now, NativeScript, one of the big differences between NativeScript and React Native is that React Native has you write React. And NativeScript is a JavaScript runtime. So it supports JavaScript, but it also supports Angular too. So really, you're addressing two different camps here, those who want to write React and those who want to write Angular. For NativeScript itself, as it goes forward,

I think that evolution for NativeScript is that just like the browser, you don't say, hey, I'm using Chrome for Angular. You don't say that. You just say, I'm using Chrome and Angular works inside. But so does React, so does Backbone, so does Knockout, so does Vue, any of the other JavaScript frameworks. NativeScript as a runtime, as it matures, should eventually get to the point where you can drop

any JavaScript framework in there, just like you would on the web, and you can use it with NativeScript in a perfect scenario. That makes sense so nature is like like the browser in the same way as like the browser is just a platform upon which you build your website and it doesn't matter you know anything uh so yeah i guess native script would be kind of like a fully featured browser where any library would just work. Correct. And then I think for the industry at large,

are you guys familiar with Android Instant Apps? No, I haven't heard of it. Have you heard of these? No. Okay, so this is fascinating. Basically what they do is they take Android apps and they split them up into shards and then you actually take just a piece of that app.

So let's say you have, I mean, let's say you're OpenTable, actually downloads and installs that little shard of the native application, but only the piece that allows you to make that reservation. Now, once you've got that little piece on your device, you can then choose to install the rest of the application, or you can casually just say, nope, and it'll be removed the second that you navigate away. So it's kind of this weird blend of like the web, which is how we find everything, because app stores are abysmal for finding things. They're terrible.

With native apps, which provide performance on otherwise low-end devices. So it's it, I mean, I'm trying to think of this from a UI perspective is it kind of like an iframe where you this little frame inside the web browser pops up with native controls or does actually take you to an app and then back? It actually loads a piece of that native app on your device without you installing anything it like install and I don't know the internals of how it works, but I think that's the future. I haven't seen anything like that for iOS, but this idea that I can use just the piece of the native app that I need and I can do that from the internet and I can find it that way,

that's how I discover native apps. To me, that's mind-blowing. That's great. That's awesome. Yeah, I wonder, I mean mean what's to stop them from um let me think about this so i mean you could have a website where if the person's on a desktop they get the website and if they're on mobile they get this instant app but then I guess if you could if there's some if you okay if you could run NativeScript on the browser then you would sort of unify all the platforms right so in other words if if if you

could write NativeScript and it would create a website for a desktop or laptop and also an app, then you would be done. You wouldn't have to do double work. Right, and that's actually where Angular 2 comes in because Angular 2, which is the next version of the Angular framework, I don't know how close you guys follow JavaScript frameworks, but it's been in development for a long time. It was just released final. But one of the things that it really focuses on

is removing the dependency of the renderer from the browser. So when we write our websites, we build them, we're usually very tightly coupled to the browser, right? We're making DOM calls, we're selecting elements from the page, we're updating those elements directly from JavaScript. Well, Angular 2 says, no, no, no, don't do that. Use these normalized APIs and let Angular handle

all of the updating of the actual UI and vice versa. And that's called the renderer. So what NativeScript does is NativeScript comes in and says, okay, the browser was the renderer before, I'm the renderer now. So you can actually, we've done this, we are working on tooling that allows you to create one application that targets both web and mobile from the same application. Now, the difference is you're building two different user interfaces, you're going to have markup for HTML, that's going to be for the web, and then you're going to have markup for NativeScript that's XML. But all your business logic, right?

All your models, all your data, all your services layer where you're calling your API, all of that is normalized into a set of code that you can use across those two projects. Gotcha. Do you expect them to unify the markups? Because there's something, there's like Bootcamp, for example, which makes it so that, you know, as unify the markups because there's something there's like boot camp for example which which makes it so that you know as you resize the window your app your website still

looks reasonable and so i could imagine with boot camp um you know maybe it's it's some kind of markup language meta markup language or something that would turn into HTML and XML. I guess that's probably overkill. No, there's actually a project out there for NativeScript that does that. I think it's called NativeScript HTML. And so yeah, there's a lot of different people thinking in a lot of different directions. I think that we

have to try all these different things and figure out which of these things actually solves a problem for developers. Which one of these is the easiest to use and isn't just cool but is actually useful? Yeah, that makes sense. It's sort of this delicate balance between, you know, like polishing something, which usually means understanding it in depth and moving quickly. And that seems to be sort of the cornerstone behind this whole thing.

Yeah, we're sort of striking a fine balance, aren't we? There's like a pendulum that swings, and we're trying to desperately balance it in the right spot and stop it from moving so we can all catch up and be current on technology. But alas, I don't know that that will ever happen nice do you see a uh i mean so there was a lot of apps that were ios only um you know early on and now there's just a ton of pressure to uh make apps for android like prisma is a good example prisma made an ios app and you know a lot of these magazines you know newsweek and other people you know the first thing they said one of the first things they said is they don't have an Android app yet. And so if you're a successful app developer, you get a lot of external pressure to support Android. Do you think that you see like an

up-and-coming os or do you think it'll it'll just stick with these two forever or for at least the next few years i mean i think the only challenger out there right now would be the universal windows platform or the uwp which is the same operating system on all devices, phones, tablets, desktops. Unfortunately, though, the mobile market is just dominated by two players. I mean, it's just dominated. And so, I mean, I don't see anyone waiting in the wings. I don't see any up-and-comers there. Yeah, it seems like a losing market because once Android became open source,

it really torpedoed. I remember when Android first came out, Microsoft Windows Mobile was a big thing, and I think Nokia had something. And then when Android came out open source and there was no licensing fee, they just completely torpedoed all of those companies' business models. And I just don't see how anyone could compete with that. Yeah, it's really hard.

And I think that for developers, we're very married to our platforms. So I have an iPhone. So when I build apps, I build iOS apps because I assume that everyone uses an iPhone because why would you not? But that's not the case, right? And so, you know, you're missing out on like at least half, maybe more. I think Android has even more of the market share now depending upon especially which market you're going into.

So especially if you're going into developing markets, that's like an all Android market. Right, definitely. So, you know, it's having both platforms covered is almost table stakes. Yep. Almost table stakes. I don't want to turn this into a... Yeah, sorry.

I don't want to turn it into a giant political discussion. But I mean, one of the things when I read people's kind of... I know you call them postmortems, but after an app gets released and they talk about this... I've seen several fairly high-profile ones where people did release an Android app, and not for something where you're a company that needs to get the app out in front of people,

but, you know, like a premium app that you're trying to sell. And what they're saying is that even though Android has a ton more users, the amount of spend from Android users is just far lower than iOS. So even though Android may dominate numbers-wise, dollars-wise, iOS seems to dominate from most of the information I've seen. I agree. I've seen those stats as well. I think one of the more concerning stats that I've seen is this one where building an app and actually being able to monetize that on either platform is incredibly difficult now.

I mean, incredibly difficult. So NativeScript is primarily used in the enterprise, right? The enterprise is still building native apps that are very much internal apps, or they're B2B apps. They're built for their partners and customers. And they're distributing those apps via internal app stores. They're managing those apps, but they're still building the apps the same way that we built desktop apps back in the 90s. This is that new scenario just playing out now. As far as people building consumer apps, I mean, that's just got to be the bravest thing you can do as a startup is build a mobile app. Because man, is that an uphill climb? Yeah. And I mean, trying to do SEO is a total nightmare. As you said, I mean, personally, if I want to find an app, I have to go to Google, look up the app I want. And now I think actually Google has some deep integration with the App Store where you can install it straight from Google.

But yeah, I mean, the App Store itself, it's almost impossible to make your app popular oh yeah the app stores are are not good for you know searchability and and finding things even when you know the name of an app i don't know if you guys have ever seen this before where you like go in and you're like i know the name of the app and you punch it in but you don't punch it in right and it's nowhere to be found you're like come on come i know it's here you couldn't i i wrote instagram and left out the g and you couldn't figure that out come on give me a break exactly um so this is kind of a bit off topic but if you um if you want to do development like if you want to launch your app on both android and ios um do you have to be using a mac you Or can you use a Windows or Linux machine and develop for iOS?

Yeah, you can. And so shameless plug here, but what we sell, part of the products and the tooling that we sell is something called the Telerik platform, which allows you to build your apps on Windows. And then what we do is we basically outsource the build portion of that

or let you outsource it to a networked machine. So you basically send your build across the wire to a build machine, which then sends it back to you. So that's one of the ways that you can do that on Windows. We're not the only ones that do that. There's a couple of different others. Xamarin does that, PhoneGap does that. But yeah, it is definitely possible as long as you have a networked Mac in some way, shape,

or form, or in our case, where we basically license you the ability to do that via our build services. Gotcha. So it goes to the cloud, it gets built, and then the app comes back. And then I guess it goes from your computer to your Windows machine to the phone, runs on your phone, but I'm assuming you can't really debug it or anything like that. Well, yes, debugging is a lot harder, but one of the ways that we get around that is we're looking at things like cloud emulators

where basically everything is running in the cloud, and then your emulator runs in the cloud, and then you can debug as well, right? So we're just basically going to pipe you the whole experience so that you don't have to download or install anything. Because I don't know if you guys have ever tried to install the Android SDK before, but not only is it like six gigs,

but it's also a frigging nightmare. So just getting the native SDK set up is a huge feat. And you haven't even built anything. You just got it to run. And I think that as developer tools companies, we have got to get rid of that or people are not going to put up with that much longer. Yeah, that sounds terrible.

I'm surprised it isn't as easy as just installing Xcode, but I've never done it, so I don't know what the reason is for that complexity. Well, you know, more open systems, so more variables. Yeah, that makes sense. There's probably a lot of configuration and all that. So how does NativeScript, what's the relationship between NativeScript

and these IDEs like Xcode or the Android Development Studio? I mean, do they work in tandem? Do you have your own IDE? Like, how does that work? Well, NativeScript is a command line tool. So it runs in the terminal or it runs on the, what is it called on Windows? Command line, command prompts, right?

CMD, command prompts. Is that what it's called on Windows? I think, Command prompts. Right? CMD command prompts. Is that what it's called on Windows? I think, yeah, I think it's called command prompts still. But I see, yeah, so it's all on JavaScript so you don't really need Xcode per se because you're not really coding in Objective-C. No, correct.

It's a Node tool. When you install NativeScript, it's just npm install nativescript-g which installs NativeScript, right? And it runs on Node. Now, it also requires you to have, like if you're on a Mac, like Xcode and the Android SDK is installed.

Although if you don't have them, it will attempt to pull them down and install them for you on your machine via an installable or direct you to the site where you can get those, depending upon what the license agreements are for those SDKs from Apple or Google. Gotcha. So, so once you have all that set up, yes, it's a node, it's a node module that runs that. So that being the case,

we provide integration out of the box with Visual Studio Code. That's our preferred IDE. That's the one that we use. That's what NativeScript is developed in because we use TypeScript. And Visual Studio Code has fantastic support for TypeScript. However, there's... Yeah, we did a show on TypeScript, but for people who didn't listen to it yet, it's basically a separate language that's sort of a superset of JavaScript, and it gives you type safety or type inferencing, which is really important.

And then it then transpiles to JavaScript. So you still have JavaScript in the end. And the JavaScript is actually readable. It's not like LLVM or something where you go from TypeScript to total nonsense. So you go from TypeScript to totally readable JavaScript. But if through that process, the TypeScript compiler transpiler learns that you've tried to set a string to an int, it can warn you so that doesn't become a runtime error. Yeah, absolutely. And because it is strongly typed, it provides IntelliSense.

We'll call that IntelliSense inside of the IDE. Oh, nice. Which if you can imagine when you have NativeScript, scripts which is dealing with native SDKs which are huge the API surface of iOS is enormous and same with Android so you can either constantly go to the docs and look that stuff up or if you're using TypeScript you can just type out the first

part of the method or property hit dot and then scroll through the list of available properties or methods with the documentation right in the IDE where you need it. That's the really cool thing with TypeScript. Yeah. Yeah, that's awesome.

So I guess you provide like a, I guess you, oh, you don't even really have to provide anything because Microsoft already does the IntelliSense with TypeScript, so you just have the API. Well, we ship definitions for iOS and Android. Right, that makes sense. Yeah, so when you create a new project, we can give you definitions for iOS and Android. Right. So when you create a new project, we can give you definitions for iOS and Android

that basically tell TypeScript, hey, here's all the different methods that are available and submethods and how these things relate. Cool. Yeah, this is awesome. I actually, this is making me want to go and build another app that is hopefully better than my Android 2.0 app or whatever it was. Should build another pick a number app.

No, it was, what was it? Random trigger question. Yeah, yeah. Definitely do some, make another bar trivia app. Yeah. I mean, with NativeScript, I've actually been able to build actual apps with maps and all sorts of stuff. So if I can do it, anyone can do it. I promise you that much. Cool. So if someone wants to try NativeScript, how does that work?

Is it open source? Can they just go and download it? Do they buy it? Do you have a student license? What's sort of that process like? NativeScript is fully open source from front to back, all of it. So you just go to nativescript.org and there's a big button that says get started and you click on that button and then it'll take you to a guide and walk you through building an application that does authentication and sign in and helps you track a list of groceries and use one of those cool slide out bars, uh,

slide out menus on the side, uh, and teaches you the fundamentals of native script along the way. So if you get all the way through that, getting started guide, you will be, you will be a native script aficionado. Cool.

Yeah. And if anyone does that, let us know. Um, uh, you know, it's always good to hear, uh,

you know, kind of success stories and things like that every now and then we get an email from someone who's tried something that we've talked about in the show and it's always really satisfying those are actually the best emails so if you've tried Burke's tutorial and you have

an awesome grocery app definitely send us an email, let us know and we'll give you a shout out on the air next time yeah that'd be awesome and we actually there's like a button at the bottom when you get to the end and it's like hey you did it

tweet about it and it basically like pre-composes a tweet that's full of emoji and says like I completed the native script getting started guide so we see that all the time and every time we see it there's like this you know, big cheer from the team, the engineers. Awesome. Very cool.

Do you have a, we actually had a webhook for, I don't remember. Oh, it was when someone broke the build. So when the continuous integration system detected that, that someone had broken the master branch of the build, this robot, like the LED lights turned red and it started yelling. Yep. I've seen stuff like that before. Every time someone completes a tutorial, like a robot at Burke's office

shoots a basketball in a basketball hoop or something. So you'll make him very happy. Yes, that's right. Yep. We love it. Cool. Well, thank you so much for coming on the show. I'm definitely going to try

this tutorial. I think it's pretty cool. And if anyone out there wants to make a web app, especially as we said, so important that you make it iOS and Android. Even if you're making it for your friends, for your high school, for a college project, it's so much more satisfying when you can give your app

to someone and there's not a 50-50 chance that they can use it. There's 100% chance that they could use it. So check this out. And thanks again for being on the show. Yeah, absolutely. And just one last thing, let me just point out that

on that nativescript.org site, I think it's under resources. We have a Slack channel there where there's thousands of developers just hang out and commiserate and help each other. So it's really, really cool. So if you get started and you get stuck, check out the Slack channel.

Oh, very cool. So they go to nativescript.org and then there's a link, I guess, to the Slack. Yeah, I think it's under resources. It's a menu item at the top. Cool. Yeah, good resource. Thank you so much. And we will catch you later.

Oh, do you have anything you want to plug other than native script? Anything that Progress wants to plug? Oh, wow. Geez, anything? I can plug anything at all? You can plug anything you want. Wow. Well, if you're doing web development,

Progress also makes a tool called Kendo UI, if you're doing web development, Procureus also makes a tool called Kendo UI, which is a web UI framework. And we've just gotten started on rebuilding that from the ground up for Angular 2. And we're really super proud of it. It's in beta. It's going to be in RC in January. So you can check that out at kendoui.com.

It's a free download. We'd love for you to use it and tell us what you think if you're into web development. Cool. Yeah, I will check that out. Cool. Thank you so much. All right.

Thanks so much, guys. Have a good one. All right. Bye. So everyone out there, that was Burke. And it was an awesome episode. I learned so much. Patrick and I learned so much about NativeScript. A couple of

meta things. The t-shirt is, the straw poll is still going on. I'm talking to several t-shirt companies about that. Still trying to figure that part of it out, but they're definitely interested. We have over 100

t-shirts, so everyone I talk to is saying, oh, you definitely should buy in bulk and things like that, which is awesome. That's good news. And so they're willing to kind of work with us. Thanks again for supporting us on Patreon, on Amazon, all of that. And we'll catch you guys next time. The intro music is Axo by biner pilot programming throwdown is distributed under a creative commons attribution share alike 2.0 license you're free to share copy distribute

transmit the work to remix adapt the work but you must provide attribution to patrick and i and share alike in kind