CHUCK:
Well, you get murdered when you're getting in the car and your wife's like, “Let's go,” and, “Hang on, I'm tweeting this.” [Laughter]
AIMEE:
I have to tweet this.
[Laughter]
[This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on JavaScript developers, providing them with salary and equity upfront. The average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 bonus as a thank you for using them. But if you use the JavaScript Jabber link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/JavaScriptJabber.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development in that Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter, and more mobile Wijmo 5.]
[This episode is sponsored by DigitalOcean. DigitalOcean is the provider I use to host all of my creations. All the shows are hosted there along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent and their VPS’s are backed on Solid State Drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code JavaScriptJabber you’ll get a $10 credit.]
[This episode is brought to you by Braintree. If you're a developer or a manager of a mobile app and searching for the right payments API, check out Braintree. Braintree's new v.zero SDK makes it easy to support multiple payment types with one simple integration. To learn more and to try out their sandbox, go to BraintreePayments.com/JavaScriptJabber.]
CHUCK:
Hey everybody and welcome to episode 186 of the JavaScript Jabber Show. This week on our panel we have AJ O'Neal .
AJ:
Yo, yo, yo, I'm coming at you live from the only day of sunshine this week in Portland, Oregon.
CHUCK:
Aimee Knight.
AIMEE:
Hello.
CHUCK:
Dave Smith.
DAVE:
Hello.
CHUCK:
A blast from the past, Aaron Frost.
AARON:
Hello.
CHUCK:
I'm Charles Max Wood from DevChat.TV. Quick shout-out for JS Remote Conf. You can go sign up now of enter our Call For Proposals. We also have two special guests. We have TJ VanToll.
TJ:
Hi.
CHUCK:
And Burke Holland.
BURKE:
Hello.
CHUCK:
And I bless your parents for naming you things I can pronounce. [Chuckles]
CHUCK:
So, we brought you on today to talk about NativeScript. But before we do that, do you want to give us an introduction?
BURKE:
Yeah, so my name is Burke Holland. I work on the Developer Relations team at Telerik which is a company that makes tools for developers, all sorts of tools. Historically UI kind of stuff but more recently platform low-level kinds of things, which is the category that we would put NativeScript into. We'll talk more about that today. I live in Nashville where it's sunny all the time, AJ. So, you can come here whenever you want. Literally the sun just shines all day, every day. It's sunny with a high of 75. It's like the San Francisco of the South, yeah.
CHUCK:
[Laughs] Sure, just rub it in.
AIMEE:
Yeah.
BURKE:
Yeah [chuckles].
AJ:
Hey, you only need one good day of sun a week. The rest is for the plants to get water.
DAVE:
I think I've heard San Francisco called the Nashville of the West, but whatever.
AARON:
Yeah, I've heard that.
CHUCK:
Yeah.
BURKE:
Right. That's exactly right. Yeah, I think actually Nashville came first. So, that would be a more accurate statement.
CHUCK:
Totally.
BURKE:
Yeah, that's me. TJ, go ahead.
TJ:
Yeah, and I'm TJ. Also work at Telerik. Burke is my boss so I'm probably not allowed to say bad things about Burke during this episode. But we'll see what happens.
CHUCK:
I might be able to mute him. I don't know.
TJ:
[Chuckles] Yeah, we can always edit that part out. I'm from Lansing, Michigan where the sun does not always shine. [Chuckles]
TJ:
But I've been with Telerik for about two years. I come from a web development background. Before that I did some Java development, some other various things. But mostly working on web development. And then I've gotten involved with the NativeScript project recently.
CHUCK:
So, is it [trying out different pronunciations] Telerik or Telerik or Telerik?
TJ:
Telerik and Telerik are both proper pronunciations which is crazy. [Chuckles]
CHUCK:
Well, there we go. The official word right here.
DAVE:
[Chuckles]
CHUCK:
Now is it NativeScript or NativeScript? I'm just kidding. [Laughter]
DAVE:
Native.
TJ:
It is NativeScript.
CHUCK:
Ah, official word on that, too. [Chuckles] So, I'm wondering, just as we get started. I was looking at NativeScript and initially when I looked at it I was thinking, “Are we sure this is native and not JavaScriptCore and some WebViews?” But the more I looked into it, I was reading through the Getting Started and fiddling with it, and it's definitely not HTML and CSS. But it threw me for a minute because you talk about JavaScript and CSS.
BURKE:
That's correct. And you're actually half right. There is no WebView but there is a JavaScriptCore in iOS or a V8 on Android. And I'll let TJ explain more about how that is and how that works.
TJ:
Yeah. So, with NativeScript your JavaScript is actually running on the device. So, one common thing that we have to get across with NativeScript is not only is there no WebView so there's no HTML being rendered. When you type 'button' you're not seeing a button, you're actually seeing a UIButton iOS control or an android.widget.Button, Android control. But not only that, is that your JavaScript is also not being cross-compiled. So, it's not like NativeScript is taking your JavaScript and turning it into Objective-C code and Java code, but the JavaScript code is actually being interpreted on the device. So, JavaScriptCore would be the JavaScript VM that NativeScript uses on iOS and V8 on Android that is being used to interpret your JavaScript. And then NativeScript, we have these different runtimes for iOS and Android that does the translation process of taking that code and turning it from the web code, the JavaScript code that you're writing, and converting those into the native controls that actually appear in your app.
CHUCK:
So, just to be clear, it doesn't compile to Objective-C runtime and/or Dalvik or whatever it is now on Android and it doesn't run on Cordova?
TJ:
Correct. Yes to both.
DAVE:
So, pretty similar to how React Native works, right?
TJ:
Yeah. You're...
BURKE:
Yes, somewhat similar.
TJ:
Yeah, I was just going to say that if you were building a high-level diagram or organizing JavaScript frameworks, you would toss React Native and NativeScript in the same classification. They're similar from a high-level approach. But then the difference is once you get into the details, the frameworks diverge from there.
CHUCK:
Yeah, I also wanna just throw in here that on Monday I recorded an episode with Cesare Rocchi. He does talks on JavaScriptCore on iOS. So, go check that out if you want a little bit more on how JavaScriptCore works on iOS and how iOS developers think about it.
So, one thing I noticed is that the views, I want to talk about that for a minute, because they're XML so they're not HTML. They're not rendered in a WebView. So, what are you doing there? Is it close to the XML nibs or xibs or whatever you call them in iOS? Or is it completely different?
BURKE:
First of all, we don't say XML. We don't like to say XML because that's a dirty word.
CHUCK:
That's a four-letter word, yeah.
BURKE:
We just say markup. Yeah, it's a four-letter word. There's that famous quote about XML. It's like violence. If it's not working, you're probably not using enough of it. [Chuckles]
DAVE:
Yeah. [Chuckles]
BURKE:
So, the idea was when we first were building NativeScript we actually looked at all the different ways that we could possibly allow people to declaratively build UIs. And the first one that we looked at because we wanted to make it simple for web developers to take their existing knowledge and go use that immediately inside of NativeScript. And so, obviously the first one we looked at was HTML. But what we discovered really quickly is that that's super disingenuous because you're basically telling a web developer, “Hey, write your HTML and then we're going to try to render something for you that looks similar to what a browser might render but with native code and controls.” And the whole thing degrades really fast. You could make it work but it would be a huge bait and switch for developers. So, we [inaudible] to stay with markup. But since we weren't using HTML, the next place you go there is other markup that's not HTML that should not be named.
AJ:
Well, I do want to say this. HTML can't be parsed. XML can be parsed. There's actually a specification for it. So, it does have, it's not all bad. It has that redeeming quality.
BURKE:
Right, correct. It's great for user interfaces. It's bad for data transfer. But it turns out it's excellent for declared UIs.
TJ:
Yeah, and the other thing too is that there needs to be, in terms of how these things are actually implemented, each XML element that we provide or each UI component that we provide has to have basically a one-to-one mapping to some sort of native component. So, we talked earlier, like if you type button, like the open tag, button, close tag, what NativeScript will do is actually instantiate and turn that into a UIButton in iOS and android.widget.Button on Android. And that same parallel applies with basically any number of the dozens of UI components that we provide. We're basically translating that into some native component that is available on both iOS and Android.
AJ:
So, I saw that when I was scrolling through the website. And one thing that I've wondered about, I guess probably there's different ways to feel about this, but you're creating an app that's then going to look different on every platform. It's going to look different on iOS, different on Android, different on Windows Phone, different on Firefox Phone. How do you know that what you're doing is going to look good at all? And what if the way that Android does it, you think is ugly or something?
TJ:
Yeah, so you're app will look different on the two different platforms. But that's by design. The whole point of building native or going native, using native UI components, is that you want your app to take advantage of the native ecosystems. You want your iOS app to look like an iOS app. You don't want to make it necessarily look like you're interacting with a browser. And the same thing with Android. You want to be able to use things like material design, like leverage the Android back button and things like that. So, in terms of how you customize your app, NativeScript provides a number of different ways for you to fork your code to handle iOS or Android differently. You can actually define a completely different XML file, say if you wanted your view to look completely different from Android or iOS. You could do say, .android.xml file, .ios.xml file. Usually you don't need things that are that drastic that you're completely redefining entire views. Normally you need things that are just small tweaks.
So, in your XML you can actually use, we have an Android XML tag that you can plop in and say, basically saying this section of XML only applies to Android and this section only applies to iOS for instance as well. And usually, you can get by with little tweaks like that because even though iOS and Android are different usually your high-level paradigms are going to be there. There's going to be things like tab use. There's going to be things like scroll views for scrolling pages, list views, those sorts of things. And at the end of the day, there's a bit of a trade-off involved in going the truly native route and building truly native apps. There will be more testing. You can't necessarily, just because your app works on iOS it doesn't necessarily mean that it's going to work and look perfect on Android. There's going to be a little bit more testing involved in reaching these different platforms.
But the gain you get is that by using the native UI component, you get something that fits on that platform better, that's going to perform better because it's using these native UI components. So, there's a bit an inherent trade-off with going native, essentially.
CHUCK:
Someone should totally go in and create an app and switch the base styles for iOS and Android and then release them on the other stores and call them “Only Prettier”.
[Chuckles]
CHUCK:
Which is entirely possible, by the way. I was looking at it and I thought, “Wow, that is really nice that you can set up a style and say look, my iOS app needs to look like this. My Android app needs to look like this.” And it has the fit and polish that you would expect on either one so that it doesn't look foreign. I thought that was awesome.
TJ:
Yeah. And usually styling is a smaller piece of the puzzle. When you think of all the things that have to go into building your apps, really where the big gain comes from using something like NativeScript is taking advantage of all the silly little things that you don't want to have to care about on iOS or Android. Usually building the UI is the fun part because people generally have their smart phones. They have an idea of what they want their app to look like. But for instance, no one wants to know how to make an HTTP call in an Android app. No one wants to learn the Java code to do that or god forbid the Objective-C code that you need to do that. So, it's far easier to call NativeScript implements the web's fetch method. And just to use the fetch syntax to make your HTTP call and take care of those nitty-gritty things that you really have no concern with, and to then focus your time on just tweaking your app and polishing it for the different platforms that you're building it for.
AJ:
So, what you're saying is NativeScript is the jQuery of phones. [Laughter]
TJ:
Sure.
CHUCK:
Halloween was last week.
BURKE:
Right [chuckles]. I would say NativeScript does try and build upon existing standards and principles for all of the things that are implemented. So, like binding expressions in the XML are Polymer binding expressions. And the HTTP method is the fetch API. It matches the fetch API. And so, we've tried very hard to define standards instead of defining our own and then asking developers to come, “Hey, why don't you come learn a different binding syntax or why don't you come learn a completely different way to style your applications?” which I think is really off-putting for developers. It's not that we don't know the language. It's just that we really don't want to learn your framework. We just want to learn principles that we already know. And that's the underlying concept behind NativeScript.
AARON:
I was at Google I/O earlier this year and Burke came up to me and said, “What do you think about NativeScript?” And I was like, “I don't know what it is. Sounds dumb.” [Laughter]
DAVE:
Sounds dumb so far.
CHUCK:
That is such a great default answer. I don't know. Sounds dumb.
TJ:
Yeah, we were [inaudible] of Burke's questions, really.
AARON:
And so, he starts explaining it to me. And he does a really good job explaining it. And I say to him, I was like, “No, that's not a real thing. I would know about that if that was for real.” And he's like, “No, we built it. It's called NativeScript.” And I'm like, “I don't think that's real. I would have heard about that right now.” And I went home that night because he swore it was real. And it was. And I started messing around with it and it was so cool how easy it was to write one set of services with two different UIs on top of it. And I had something going in an emulator for Android and for iOS. And I was like, “Wow, that was insanely easy to write two apps with only two UIs but one services layer.” It was pretty cool. So, I'm a huge fan of NativeScript.
BURKE:
Yeah. I remember that, because we were both wearing headphones at the Google I/O party and screaming over dueling DJs. Do you remember that? They had two DJs.
AARON:
Yeah, yeah, yeah.
BURKE:
And you had to switch between channels to pick your DJ. And we were screaming about NativeScript over the talk of thousands of dancing developers.
AARON:
Yeah.
BURKE:
Yeah. I think one of the things that you said to me that same night was you were like, “No, I've heard of React Native but I haven't heard of NativeScript,” which is generally the sentiment that we get. And oddly enough, NativeScript was released just prior to React Native. But people tend to lump those two in together. Now the NativeScript team does work closely with the React Native team just in terms of knowledge transfer. Both are open source projects. NativeScript really tries to abstract you completely away from having to write any native code. So, the way that NativeScript works is that it injects into the global namespace of the VM all of the meta information for the APIs for iOS and Android, depending on which platform you write it on. Then what it does after that is that it wraps a lot of these things inside of very convenient and very plain and simple API.
But there are pieces of a native SDK that you're going to have to get that the framework's not going to provide for you. And this is true even for React Native. But the big difference is that in NativeScript you don't ever have to write native code. And this is really super confusing for people. But even if you're calling native APIs that we don't wrap, you call them through JavaScript. So, you would do it like if you were working with a UIColor on iOS you would say UIColor.init with whatever the method name is straight out of the box and that would actually work inside of JavaScript but without that goofy Objective-C message passing syntax. The difference there between that and React Native is that in React Native you do have to write a few of your own custom bindings, I guess they call them, for components that don't exist. So, you have to drop in and write some lower level code, I believe. But I would say I haven't used React Native.
AARON:
So, you end up either having to learn Android or needing an Android or iOS developer to get some
of it done?
BURKE:
Right. That's the idea. You will have to know some native code. And even with NativeScript you're going to have to, eventually, it's a lie to tell people that you can build entire applications and never have to touch the native APIs. That's just not going to work. In a real-world application, there's going to be native APIs that we don't wrap that you're going to want to call. But at least you don't have to go and open up Xcode and write Objective-C. You don't have to write Java. You can stay inside of JavaScript and just call the API. Just go find the doc and call the API and it'll still work.
AARON:
So, if I understand what you're saying, to write those bindings in React Native, I end up needing to know some Objective, or I need a developer to write it. But in NativeScript you guys have some sort of reflection on top of it where I can just talk to some API and it reflects and goes and talks to those APIs for me? Or how does that work?
TJ:
To take a step back, when we talk about these APIs being made available, really what NativeScript does is actually take a representation of iOS and Android and injects it into the JavaScript VM. So, if you look at JavaScriptCore which we talked about earlier, one of the things you could do with NativeScript is you could just type new UIAlertView which is an iOS API. It's implemented in Objective-C. But with NativeScript we make that available from JavaScript directly. So, we actually use JavaScriptCore's C++ APIs to make these various APIs available to you. And we'll actually interpret that directly from JavaScript. So, we'll take care of the hard work of making sure that JavaScript code that you write actually turns into the native representation.
So, the cool thing about that is that when you need to go native, instead of say, opening Xcode or opening Android Studio or whatever tool you'd need to use, you can stay directly within JavaScript. So, the code that you're writing stays basically the same. The APIs are going to be the same regardless. But by staying in JavaScript you stay in a mindset that you're more comfortable with instead of having to dive into native world to get some certain task done.
DAVE:
So, does that apply to every API? Even Strings and things that are provided for you on iOS?
TJ:
Yes.
BURKE:
Yes. Yeah, it does. The other thing it applies to is every third-party library that's out there. So, one of the other things that we wanted to do is we wanted to leverage the rich ecosystem that iOS developers have. If you do iOS development you know that there's insane components that people have built and then open sourced. I think Fitbit has charts that they open sourced and put out there. And Flipboard's got this crazy diagnostic tooling that they put out there. And then there's this pods which is similar to npm for web developers that [inaudible].
CHUCK:
CocoaPods.
BURKE:
CocoaPods, right, to just pull in these libraries and use them. And if you want a drawer, you can just pod in a drawer. If you want some, I don't know, whatever you might use on iOS, you just pod it in. And so, the way NativeScript works is it actually allows you to use CocoaPods and pull them into your application. And when you do that, we run reflection on those and then we pull those and then we shove that into the VM so that you can use third-party libraries for iOS and Android still without having to drop down and write any native code. It's kind of mind-blowing.
CHUCK:
So essentially, from what I gather, because I know that you can do this the other way from a Swift or Objective-C app where you can actually write some of your logic for your application in JavaScript and what it does is it spins up a JavaScript process and then passes essentially messages to it saying, “Load this JavaScript file and then here's the function call.” So, are you essentially doing it the other way where you spin up an Objective-C or Swift runtime or an LLVM process and then say, “Here's what you should have a binding to. Run that”?
TJ:
So, it's a bit different. So, my mental model for how NativeScript works is we treat the JavaScript VM, so if we stick with the JavaScriptCore in iOS example, we treat it in a similar manner to how the browser operates a JavaScript VM.
CHUCK:
Mmhmm.
TJ:
So, if you think of JavaScriptCore, JavaScriptCore knows about JavaScript things but it doesn't know about browser things. It doesn't know what the window object is. It doesn't know what the document object is. In Safari you'll have to have APIs, it has to have mechanisms to tell JavaScriptCore, “Here's what a window object is. Here's how it works. Here's what you should do when the user of this actually calls things on the window object.” And so, with NativeScript we do something similar with iOS. We'll say, “Okay, here's what the UIAlertView API is, plus all the other various iOS APIs. Here's what all these APIs are.” And there's C++ APIs to actually do that. And then there's also C++ say, callbacks essentially, that let you configure what happens when these APIs actually get invoked. So in a way, we're leveraging the JavaScript VM to run the iOS app and using that VM as the thing that actually handles the execution in a similar way that the browser would handle the same sort of task. Does that make sense?
CHUCK: Uhuh.
DAVE:
Yeah, I think so. Question for you about that. I can only imagine that there were weird edge cases you've encountered where the semantics of the say, iOS Cocoa API are hard to map onto the semantics of JavaScript. Specifically I'm thinking like message-passing. Especially like nil handling and stuff. How do you guys deal with those kinds of things and did you have any particular cases that were hard to map to JavaScript?
BURKE:
Oh my gosh. TJ, you want to go ahead and?
TJ:
Yeah. Message passing is the one that is a very good example because it gets very complex, really tricky. And the JavaScript code needed to handle that ends up being more verbose than you would care to be to handle it. I'm trying to think. If you look at the NativeScript docs, if you go to docs.nativescript.org and scroll to the bottom, there's a section on runtimes for each, iOS and Android each have their own section, where we drill through the edge cases of this. And it gets weird in certain situations. But for the most part, the common things that you need to do in an app actually are relatively straightforward. Although there are certain differences in a java.lang.String and an NSString and JavaScript's concepts of a String, for the most common things that you need to do, it's actually fairly similar. The same thing with your basic integers. Those things are fairly straightforward and we try to document the things that gets really murky and strange. But those things are less common than you actually have to deal with in a common application.
DAVE:
Sure.
BURKE:
Yeah. The term that I was looking for was marshalling. And there's a whole section on marshalling in the docs that goes over, how do we do that? How do we create an array or map to an array and things like that. So, really interesting stuff that the team has put together here.
DAVE:
So, along those same lines, what do you do with native APIs that require you to pass to them native objects? Let's say you have some widget that needs to be passed like an NSDictionary. And there's really no equivalent to NSDictionary in JavaScript today. But we do have immutable data structures from third-parties. How did you map that?
BURKE:
Well, you actually create an NSDictionary in NativeScript, believe it or not. Because you do have the ability to call those native APIs, like I said. So, if you actually went into NativeScript and asked for a new dictionary object in iOS you'd get one. And you would say 'var dictionary equals', and then you'd create one and you'd get it. And then you could pass that then to some native API that was expecting a dictionary. [Inaudible]...
DAVE:
Oh, okay. But is that an example... Go ahead.
BURKE:
Well, I was going to say I don't know if that's exactly what you're asking. But the way that the marshalling works, we do actually preserve those types, I believe. TJ, is that correct? Or am I speaking out of turn?
TJ:
Yeah. Basically NativeScript has to manage two different states. So, there's the state that the JavaScript VM knows about and there's the state that the parent app knows about. And what NativeScript will do in that case is that you would type your NSDictionary. NativeScript's going to pass you back a pointer to that native object and essentially keep a map that it knows that that NSDictionary has been allocated for you to use. So, in your JavaScript code you would type new NSDictionary and you would be able to pass it to the API. And under the hood there would be a true NSDictionary object and that NSDictionary object would get passed to that API.
DAVE:
And then if you new one of these up are you responsible for deallocating it later?
BURKE:
No.
TJ:
So, yes. But...
BURKE:
Yes, no? [Laughter]
DAVE:
Classic memory management answer.
[Laughter]
CHUCK:
It could be ARC.
BURKE:
That was perfect.
TJ:
So, memory management is hard. [Chuckles] I don't think that's necessarily a surprise. And the NativeScript runtimes are actually fairly smart about being able to figure out some of those things. But there are some cases, especially if you're building certain apps that are more complex or using certain kinds of objects where you will have to give the NativeScript runtimes hints for things to be reallocated appropriately. Does that make sense?
BURKE:
Yeah, and...
DAVE:
That sounds dumb. [Chuckles] Just kidding. [Laughter]
DAVE:
A little Frosty snark moment.
AARON:
Oh, that sounds dumb. I don't like it. [Laughter]
DAVE:
Memory management sounds dumb.
CHUCK:
Yeah. So, I've got a quick question. And this is something that I asked the folks on Ionic, too. They had a different answer because their tables are all built in HTML and then they handle this case differently. In your case, are you actually putting in a native UITableView when you display a list of things? And if so, one thing that I'm aware of is that it has its own APIs that it links back to the controller and expects the controller to implement so that it can say, “What are the elements at this index?” so that when you scroll up it reuses the UITableView cells and does the magic so that it looks like it's scrolling but it doesn't actually have to redraw any elements onto the screen. So, do you handle those cases or do you handle them differently and in your own special little way?
BURKE:
Well, what we do for those complex cases is we wrap those components for you. And if you go into, if you create a NativeScript project, you'll get a folder in your app called TNS modules. And then inside the TNS modules you'll see all of the different things that we implement on your behalf in JavaScript. And one of those is a complete set of UI components, very common components, like TextViews, labels, buttons, ListViews being one as well. And we even implement things like virtual scrolling in our ListView for you. So, the idea being that the developer should be able to create a ListView in markup, wire up the events just in the markup, and then handle those events in JavaScript and then we'll worry about what happens under the covers in terms of the references to cells and to the controller and back and forth and like that. TJ, you want to get to that?
TJ:
Yeah. We will on iOS create a UITableView. That is how our ListView is implemented. So, if you just type ListView as an XML element, it's a UIListView under the hood. So, really as a more board statement to one of the cool things about having this mapping and this direct access to iOS and Android is that really anything that you can do in an iOS or an Android app you can do in a NativeScript app. So, really any question of “If I saw this in this iOS app or I saw this in this Android app can I do it in NativeScript?” the answer is always yes. It's just a matter of whether we've created an abstracted view to make that easy for you like in the case of a ListView or whether you have to dive into the native code to make that happen yourself.
CHUCK: Hmm.
BURKE:
Another thing that we do there for people that do dive into the native code is we allow you to publish those things as npm modules or npm libraries. I don't wanna... I used npm modules once.
Somebody was like, “They're not modules. They're libraries.” So, I want to make sure I [inaudible].
CHUCK:
[Laughter]
DAVE:
I think they're a package that can contain modules. Is that the right terminology?
BURKE:
There, that's what I was looking for. That's it.
CHUCK:
How dare you?
DAVE:
Most packages contain one module. But anyway, that sounds dumb.
BURKE:
That is dumb. I don't like it.
[Laughter]
DAVE:
I don't like it. [Laughter]
CHUCK:
I don't like it when you're doing it wrong. So, get it right.
AJ:
Yeah. And you better use the Oxford comma, too.
DAVE:
[Inaudible] sounds dumb.
TJ:
Don't get me started on that. [Laughter]
AARON:
So, I have two questions that I want to ask to you guys that I want you to address before we end. One is, can you talk to us about, I know you guys are in talks with the Angular team. I'd like to hear how that's going. What's the plans with NativeScript and Angular 2? The second question is for most of us who want to start using NativeScript at work, we can't. Rewriting the entire app isn't an option. But we want to be able to start writing features going forward. I know that that's not an option in NativeScript. Can you guys talk to us about your plans to enable that? Those are my two questions I want to hear.
TJ:
Yeah, so as you mentioned we've been working with Google and the Angular team for pretty much the better part of this year since I think May. I think for those that aren't aware of that, one of the nice things about NativeScript is that there's many... since the APIs that are available are really low-level you can build a number of different abstractions on top of it. And we at Telerik have been fans of Angular for quite a while. But Angular 1 if you're familiar, was tightly coupled to the DOM. So, everything in Angular needs the DOM to work. There is no DOM in NativeScript. So, Angular 1 was out.
But as soon as Angular 2 came out and we had this model of trying to build these UIs that weren't tied to the DOM, we instantly tried to get that sort of thing working in NativeScript. And we do have an implementation right now. If you go to GitHub.com/NativeScript and you just do a search for Angular there, you'll find, we have a few different samples in our repo. But the idea is that especially with one of the biggest things we try to talk about with NativeScript and Burke talked about this earlier, is letting people reuse skills they already have. Well, one of the major opportunities for that is Angular 2. being able to share some of your Angular 2 code potentially with your web app and also with your native iOS and Android app.
AARON:
Cool. How's the plans coming along with that?
BURKE:
It's going really well. Just demoed our first pass at integrations during AngularConnect. Aaron, I know you were there for the session that Sebastian did for that. Of course, it's very new. We're a bit tied to Angular 2's release schedule. So, we can't really release until they do. But fortunately, they involved us really early on. Well, I'd say early on but a lot earlier this year. So, we've had a lot of time to work on it. And they continue to work closely with the team. I would expect that we shall be ready around the time that Angular 2 is ready.
DAVE:
Cool.
AARON:
Whenever.
BURKE:
If somebody could find out, we would love to know, yeah.
CHUCK:
[Chuckles]
TJ:
Yeah, and really, if you want to learn more about it, Burke mentioned this too, but all the AngularConnect talks are up on YouTube. And if you look for NativeScript AngularConnect you'll find one of your colleagues, Sebastian, did a talk about it that goes into more detail than we'll have time today. So, it's a pretty good watch.
BURKE:
Yeah. And it's an excellent point. One of the things that he talks about that I think is really interesting is, there's a diagram where he shows Angular and how the idea with Angular 2 being that you could either got the web route or you could go the native route. And that your business logic should be able to work in both places. I think one of the tough things about writing native code is that your business logic gets siloed inside of DLLs or inside of portable class libraries or JARs or whatever you happen to be using. But if you're able to write JavaScript objects and use them everywhere, then theoretically speaking you could centralize your business logic and stop having to duplicate it in multiple places, which is I think is the unicorn that we've all been chasing for a long time.
CHUCK:
Yes.
BURKE:
Aaron, your other question about adding NativeScript to existing projects, I noticed that Valio who's our PM had sent me a GitHub issue. So, they are working on it. Apparently you're not the first person to request that. But if anybody here that is listening wants to, has a feature request or wants to know the status of something in NativeScript you can go to GitHub.com/NativeScript and send your pull requests or your issues. If it's a good idea, we'll just tag it as a feature request and get it in there.
AARON:
Cool.
AIMEE:
One thing that I've really been wanting to dig into is building stuff for Apple Watch or Pebble. Can you use NativeScript to build out anything for wearable stuff right now?
TJ:
We have a proof of concept out there for Apple Watch. It's one of those things that is again, depends on demand for how much we support some of these other devices. But if you go to GitHub.com/NativeScript you'll see out beta Apple Watch idea. And really, this goes back to the same point I'd said earlier that anything that you can do in an iOS app you can do in NativeScript. So, you can build Apple Watch apps using NativeScript. It's just a matter of, it might be a bit of manual work to get it up and running. And it's currently where our Apple Watch situation is right now.
CHUCK:
I know that Pebble has Pebble.js so you can write your apps directly in JavaScript. It wouldn't be the same as NativeScript obviously. But do you know if Apple Watch has JavaScriptCore on it? Because it doesn't... [Chuckles]
CHUCK:
Technically speaking have a browser or anything like it on there.
BURKE:
Well, I think in the current incarnation it's dependent upon the phone, right?
CHUCK:
Okay.
BURKE:
Like don't you have to have a... So, that's what the [weird]...
DAVE:
Yeah. The phone does the heavy lifting.
BURKE:
Right. The phone does that.
CHUCK:
Right.
BURKE:
So, that would be where your NativeScript runtime would be. And then your APIs would talk to the Watch app.
CHUCK:
Okay.
BURKE:
So, as TJ said you could do it since you can call any API. We just, we have not yet provided the fancy schmancy wrappers for you and the scaffolding on a new project to do that.
CHUCK:
Okay.
BURKE:
I think, we're looking at wearables very closely but we're really trying to nail the mobile developer experience to make that just gorgeous, right? The best possible workflow, all of the right wrappers for all of the right UI widgets so that developers can be productive really, really, really quickly. Because without that successful mobile app, who gives a crap about wearables? [Chuckles] If you don't have a successful mobile app, you definitely don't have a successful wearable.
CHUCK:
Yeah. I was also going to ask about Apple TV. But I think the answer is kind of the same where it's so new and...
BURKE:
It is.
CHUCK:
You just don't know.
BURKE:
Yeah. And again, we have a proof of concept just to see, can we do it? And what does it look like? So, we've done it. But we haven't, yeah we haven't provided the wrappers or scaffolding yet.
CHUCK:
The other question I have is that on iOS in particular and I'm sure Android has something very similar that parallels it, is that you can build applications that are universal. So, they run on both iPads and iPhones. How does that work with NativeScript?
BURKE:
That's a great question. TJ?
TJ:
You can do that as well. And I think one of the challenges there is providing, really it's your UI layer again. Building a view that looks good both on a small little iPhone and also an iPad as well. So, one of the things you can do in NativeScript is in addition to providing say, different XML views for you iOS and Android app, we also have what we call resolution dependent or something where you can provide essentially different XML files based on the pixel density or the size of the device that you're outputting to. So, you could provide a different XML file for say large iPads, small iPads, small iOS devices. Really you can get as fine-grained as you want, to configure what it is you're building. Obviously there's going to be a bit more work with every time of different files, type that you want, or different device that you want to support through that means. But that is something that you can do.
CHUCK:
Sounds great to me.
DAVE:
So, what prompted you guys to create NativeScript in the first place?
TJ:
So, at Telerik we've had, I don't know if people know this but we actually, in addition to building web tools we have Kendo UI that we've had. Kendo UI is actually turning 4. So, it's been out for quite a while. And we also do native development. So, we have native iOS controls, native Android controls, native Windows Phone controls as well. And NativeScript really came out of an effort to unite the best of both worlds. We don't want to give up say, some of native's best things. Like native's performance, native's gorgeous UI components, some of the things that we love about the native apps that we use in our phones every day.
But we also love things, a lot of things about the web. So, web has the fast development cycle. It's JavaScript code. It's interpreted. You can view changes right away. JavaScript web code is also very easy to deploy. You don't have the craziness of native build cycles. So, NativeScript really came out of an effort to unite the best of both worlds. And we get as frustrated building for all these different platforms as everyone else does, especially as a software company. We're on the front lines of that sort of thing. So, NativeScript was really our effort to simplify that process.
BURKE:
So, to just provide some historical context on this, about three years ago, well actually four years ago right about the time we launched Kendo UI we were at the same time working on a hybrid development solution, which at four years ago, now everybody's doing that. Four years ago, there was not anybody else who was doing that. The only other player out there was Adobe doing PhoneGap build. And what we discovered in the process of doing that was that developers would build up these hybrid apps really fast because they knew web dev. So, they could do that. They could build the UI and they love that. And then they would start trying to add PhoneGap plugins to their app. Like I want a native action sheet and I want a native social share and I want a native tweet, and I want a native this, that, and the other.
And then it would get to the point where they were like, “Can you just translate all my HTML into native plugins?” [Chuckles] Is there some way that we can have a framework where we just end up with a native application on the other side? Because we kept converging on that point. So, that's where NativeScript was born out of, was this idea of, can we take what web developers already know and turn that into a native application? And it morphed over time. It started out like that sort of conversation. And then it changed as we began to look at that. Like no, we can't really change all your HTML into PhoneGap plugins. That's not really feasible. But here, this solution actually would work. And can we make it so that nobody ever has to touch native code again?
DAVE:
What kind of companies are using NativeScript today to build apps and what are they doing with it? Do you have any cool stories?
BURKE:
Well, [chuckles] we don't have any cool customer stories at the moment that I can think of. I know that there's... and the only reason I say that is because I don't know because we do a lot of, Telerik does a lot of commercial deals. I'm not sure who we can talk about. So, I got a couple of names that just popped into my head but I don't want to say them because I'm not sure if that's okay or not. TJ, do you know if we have anybody that we can publicly disclose? Like our indie developers?
TJ:
No. Yeah, I think the nature of Telerik as a company is a lot of our customers tend to be these companies that I'm not sure if we can disclose. One thing I will say is if you go to NativeScript.org we have different samples out there and that's the place to look for different apps that are out there. You can find a few different apps that are out in the App Store. If you search for NativeScript examples, we have a recent app that's out on Google Play. It'll probably be out on iOS by the time this podcast airs. We're in the iOS approval state right now. But I think it's NativeScript.org/samples and you can see a bunch of different apps that you can check out.
DAVE:
So, without approval, what was that again? Does that mean that if I were to go build an app with NativeScript, can I get it in the store right now?
TJ:
Yes. And we have several apps out in the store, yeah.
CHUCK:
I'm kind of wondering. It sounds like people are using this for some fairly specific uses. Are there things that NativeScript really isn't good for? Like writing games or building I don't know, other apps that do other stuff.
DAVE:
Teslos.
CHUCK:
Yeah, Teslos [chuckles].
BURKE:
I would say at the moment that yeah, it's probably not quite ready for prime-time gaming. We did just implement a brand new animations framework, so we're moving in that direction. The idea being we want to cover all use cases. But I think that if you were going to sit down and write some crazy game like Osmos or some great game like that, that you would find yourself very, very heavy inside the native code, what do you think TJ?
TJ:
Yeah. If you're trying to create the next Flappy Bird clone, NativeScript might not be the best choice for you. But if you're looking for a framework that lets you build your traditional app like a line of business app and even a step beyond that, like you want a quick and easy way to use your web dev skills to build a really common scenario for an app, I think NativeScript's one of the fastest ways you can get that done.
CHUCK:
So, you've got components or modules or whatever you want to call them for things like audio and video and web and APIs and all that stuff?
TJ:
Correct, yes. And the other thing too is that, so in addition to the things you'll find documented on the website, if you go to npm right now and just search for NativeScript just to give you an idea of what's out there, at the time that this is, that we're recording this, we've got 70+ things. You'll see things like NativeScript phone if you want to make phone calls in your app or send SMS messages, NativeScript sound, play sound files like you'd mentioned, maps, clipboards, screenshot, email. So, it's a fun list to look through to just give you an idea of the sort of things that are out there that you can accomplish.
CHUCK:
And you need those plugins to do those kinds of things?
TJ:
It depends on the specific scenario. Usually the plugins are there because they're not in the core NativeScript framework, yes.
CHUCK:
Okay. What about testing or debugging?
BURKE:
Oh. Actually testing is great because you just can use the same tools that you were using before, at least for QA testing. If you're talking about unit testing frameworks...
CHUCK:
Yeah.
BURKE:
I'll let TJ cover that one in a second. As far as the debugging goes, we offer several different ways to debug your application. One of them is the console, which will shell out, if you were going to shell something out to the console just like you would in a browser. But instead it comes out to the terminal or the command line on Windows. We also allow you to connect to your instance with Safari Inspector. And you can basically step through your JavaScript the way that you would a web app, which is kind of nuts. I can't even believe that works. But somehow it does. Those are the debugging scenarios.
Unfortunately native apps have really bad UX when it comes to crashes. They just disappear unceremoniously. And so, there is some of that that you have to deal with. It's not like the web or the browser where it's extremely forgiving. If something doesn't work, it'll just barf but it sits there and waits for you to inspect everything. Native apps don't do that. So, the debugging experience is different. But at the same time you can still use Safari Inspector which is close to Chrome Dev Tools. Not quite the same. [Chuckles] But it's definitely a familiar environment.
CHUCK:
So, if it crashes on somebody's phone halfway across the world, I'm not going to get a whole lot of information about what happened?
TJ:
Well, it's a native iOS app. So, you'll get the same amount of information that you would get from any native iOS app.
CHUCK:
Okay.
TJ:
Which means you might want to leverage some sort of service that there's a whole ton of different analytics and crash analytics iOS services that you could leverage.
BURKE:
Yeah, like Telerik Analytics, TJ.
TJ:
Yeah.
[Laughter]
TJ:
We need a cha-ching sound.
CHUCK:
There you go.
BURKE:
Right? Shameless, what's the shameless plug sound effect?
CHUCK:
I don't know. I should probably disclose that Telerik is a sponsor of Adventures in Angular.
BURKE:
Are we?
CHUCK:
Yup. Kendo UI.
BURKE:
I didn't know that.
CHUCK:
It's a new thing.
BURKE:
Oh, sweet. Okay.
DAVE:
You know, I had forgotten that. But I could tell. I don't know what it was, but I could tell.
CHUCK:
[Chuckles]
DAVE:
That sounds dumb. I don't like it. Just kidding. It sounds great. Thanks sponsors. [Chuckles]
DAVE:
Cha-ching.
CHUCK:
So anyway, back to testing. So, you just hook up something like, I'm blanking on tool names now.
And I wanted to say QUnit but I know that'll turn people off.
DAVE:
Mocha, Jasmine, Karma.
CHUCK:
Yeah.
TJ:
Yeah, so the nice thing about being build with JavaScript is that there's a lot of good JavaScript testing solutions already out there. And you can use those as part of your NativeScript app. We have on our road map, I think we're going to get it into the next release, where we're going to make our CLI a little smarter about handling those tests for you. Because even though there's a lot of these JavaScript tools out there, there are some NativeScript specific things in the way that NativeScript starts up its app that it creates views for that. And we want to provide some helping guidance for that, because we know it's a common thing people are looking for. So, you can expect that to be out hopefully in our 1.5 release which is coming out later this month. And if not, shortly after that.
CHUCK:
And then as far as acceptance tests or end-to-end tests or whatever you want to call them, where you're actually testing from the interface on the phone or on the emulator?
TJ:
So for that, you should play the shameless plug sound effect again.
CHUCK:
Cha-ching!
TJ:
Because we could talk about [inaudible].
BURKE:
Yeah.
CHUCK:
Well, if it's a solution that works, I have no problem talking about it, so go for it.
BURKE:
Right. So, if we go back and talk about what we call the Telerik Platform which is the mobile app solution, end-to-end solution for hybrid apps, that's the way it started. And that is not just the IDE or the IDE integration with things like Visual Studio but it's also the publishing pipeline to get you into the store. It's an internal app store. It's analytics. It's app feedback. It's everything that you need. It's an end-to-end solution. And so, because we already have that baseline, we're building on those things and offering NativeScript in that context. So, if you were doing things like your user acceptance testing, you would include the app feedback module in your NativeScript application which would then allow people to send you automatic crash reports, will allow people to shake the phone and then annotate right where they see a bug or something's not right or this isn't what it should be, and send that feedback directly back to the developer where it's consolidated inside of a dashboard. Is that sort of what you were asking there?
CHUCK:
Yeah.
TJ:
Yeah. I think too, one question we get a lot that we haven't really gotten today is people ask us a lot, well how do you make money off NativeScript? How do you monetize NativeScript? And a lot of it is the tools and services that we've been describing today. Things like the Telerik Platform. Tools that aren't necessary to help you build your NativeScript app. NativeScript's completely free to use from the command line. It's completely open source. Anybody can use it. But we do have these tools and services that we're providing for things like analytics, et cetera, that people can leverage if they want to.
BURKE:
One of the things that we discovered early on was we have all these different things. We'd say, “Hey, look. You can build an app and you can do analytics on it and you can deploy it privately and you can measure stuff.” But the problem was that people couldn't get to app. And so, we want to make it as easy and free for people to get to the application. Because you're really not going to need services and all this other stuff until you know that you can actually build an application. So, we wanted to remove all of those roadblocks for people to their app and then provide them with a complete integrated ecosystem so that they could have all of the things that they needed to actually take their app to the App Store and be successful with it.
TJ:
Yeah, and this also makes for a nice convince your boss moment, if you're one of those people that's in a company that's trying to use a tool like this in your next app. You can know that at Telerik we do offer not only this tooling but we do offer support as well for a lot of our tooling as well, which can help make the sell if you're trying to convince your boss or some higher up.
CHUCK:
One other question that just came to mind is data storage. So, do you just use Core Data or SQLite?
TJ:
There is a SQLite plugin. We have modules that will store, that will leverage Core Data to store things directly in the device. And you can always, there's HTTP service so that you can use some sort of external provider. I think we have a, someone's working on a Firebase plugin as well that you could use, hopefully soon as well.
CHUCK:
Realm?
BURKE:
There's also a, well there's a bounty out right now for somebody to do Meteor and NativeScript integration. Did you see that, TJ? I forget what...
TJ:
I did not.
BURKE:
Somebody put a bounty out for somebody to create Meteor and NativeScript integration. So, somebody out there is working on it. I'm just not quite sure who. I can't find the link at the moment.
But yeah, everybody wants NativeScript to integrate with their web framework.
CHUCK:
[Chuckles] Yeah, there's a third-party database for iOS called Realm. I was wondering if you have support for that.
TJ:
If they have an SDK, it should be fairly easy to write a NativeScript plugin that ties into that.
CHUCK:
Cool.
BURKE:
You could write it and then sell it for eleventy billion dollars. [Laughter]
CHUCK:
Enough to buy a Big Mac. Alright.
BURKE:
That's right.
CHUCK:
Any other questions?
AARON:
I'm good.
CHUCK:
Alright, well let's go ahead and do some picks then.
Before we get to picks, I want to take some time to thank our silver sponsors.
it:
errors cost you money. You lose customers or resources and time to them. Wouldn't it be nice if someone told you when and how they happen so you could fix them before they cost you big-time? You may have this on your backend application code, but what about your frontend JavaScript? It's time to check out TrackJS. It tracks errors and usage and helps you find bugs before your customers even report them. Go check them out at TrackJS.com/JSJabber.]
[This episode is sponsored by Thinkful.com. Thinkful.com is the largest community of students and mentors. They offer one-on-one mentoring, live workshops, and expert career advice. If you're looking to build a career in frontend, backend, or full-stack development, then go check them out at Thinkful.com.]
[Once again this episode is sponsored by Braintree. Go check them out at
BraintreePayments.com/JavaScriptJabber. If you need any kind of credit card processing or payment processing in general, they are a great way to go and we appreciate them sponsoring the show.]
CHUCK:
AJ, do you have some picks for us?
AJ:
Of course I do. So, first off I will pick Caddy server. I might have picked that before. It's a web server written in Go but it's a little bit different because it's an HTTP 2 web server. So, they're just finishing up the Let's Encrypt plugin. And there's also going to be some HTTP 2 plugins. So, it'll automatically do the, post your scripts and stuff. That's not implemented yet but it's getting there. And it's written in Go. So, it's a safe language. You don't have to worry about vulnerabilities like with Apache. But you also can get in there and play with some of the code and get your hands dirty without... because Go's a very friendly language, very easy to use. So, Caddy server. Yeah.
Also I'm going to pick, there is a video game called Top Gear. And in fact, the best Top Gear was probably Top Gear Rally but it will never be made again because I think it ended up being like Microsoft bought the company that bought the company that company that bought them or something. So, they'll never show up on Nintendo again. But there's an Overclocked remix that you can listen to on YouTube. If you're a Top Gear-head it will bring back the memories for you.
CHUCK:
Alright. Aimee, do you have some picks for us?
AIMEE:
I do. So, based on the episode that actually came out last week, I don't know, I've had this desire to start digging into more CS topics and take a break from the back and forth of all the frameworks and all these details of things that have been going on. So, that's what I've been spending my time with on the weekend.
I stumbled upon this absolutely incredible post about Bloom filters this weekend. So, of course I can go to Wikipedia or check out YouTube courses. But this was written by a developer at Medium and it's meant for people who maybe are technical, maybe are not. But he goes into detail about why they use it at Medium so they can quickly find out whether a post has been seen before but it's just an incredible, even if you know what a Bloom filter is, you should read this because he tells a story in it. So, I don't know. It just was incredible. Anyway, so that's my first pick.
And then my second pick, I thought it was important to thank a couple of people that I've been working with lately because they've been so helpful that I wanted to also thank this mentor that I've been working with. His name is Mike Gehard. And he's a developer at Pivotal. And then he also used to teach at gSchool which is one of the, I don't know that gSchool is still a thing. I'm not certain. But it's one of the only other six-month bootcamps. So, he has just been extremely helpful and I wanted to make sure I said his name on here. And that is it for me.
CHUCK:
Awesome. I'm a Mike Gehard fan as well.
AIMEE:
Oh really, you know him?
CHUCK:
Yeah, I've met him a couple of times at various Ruby events.
AIMEE:
Okay, so he's the one, if I keep talking about this mentor that I've been working with, that's who I've been working with. And he is just incredible. I can't believe that someone would give an hour of their time a week not expecting anything in return. No payment, no anything. Just doing it because he's nice. [Chuckles]
CHUCK:
Yeah, I...
DAVE:
You just haven't gotten the bill yet.
[Laughter]
CHUCK:
I thought for sure we had him on Ruby Rogues. But it doesn't look like we have. We'll have to remedy that.
AIMEE:
Yes. He's just so nice. I'm so, so, so grateful.
CHUCK:
Alright. Dave, what are your picks?
DAVE:
Okay. Well, I just wanted to pick one talk that really touched my heart from AngularConnect. It was actually Joe Eames's talk. It's called 'Becoming Betazoid: How to Listen and Empathize with Others in the Workplace'. And I really, really enjoyed it. I shared it with all my team. And I just think that we could all do better at this, probably. And I think that we could all really benefit from taking some of Joe's suggestions in that talk. So, if you have a minute, take 20 minutes out of your day and listen to Joe's talk, how to become betazoid.
CHUCK:
Awesome. I think Joe said you had to be nice to people, which is why I haven't watched the talk yet. [Chuckles]
CHUCK:
Alright I've got a couple of picks here. I've been, I've just been thinking a lot about some of the things that we can do to be more effective as programmers. And the funny thing is, is that a lot of them are things that really have nothing to do with programming. They have to do more with how you take care of yourself and how you take care of your brain, which is the major organ that we use in this kind of work. And so, I'm just going to pick a couple of things. I'm probably going to put together a three or four-page pamphlet with ten or so things that I think you can do right away to actually boost your performance as a developer.
One of the first ones is exercise. And we've talked about this on the show before. But it increases blood flow to the brain. It increases your oxygen efficiency. And it just does a lot of good things for you so that you can be more effective as a programmer. The other one is sleep. And getting enough sleep is important if you're exercising. But it's also important just from the standpoint of that's when your brain repairs itself. It's when it catalogs all the memory from the day and things like that. And it's super duper important. There are all kinds of studies out there that tell you that sleep is important. So, I'm going to pick that as well. I'll probably go find one of those and pick it next week. But for the meantime, just keep in mind that exercising and sleeping well are two things that you could start doing right away that will probably increase your effectiveness as a programmer.
Aaron, did we get picks from you?
AARON:
Not yet. But I got some.
CHUCK:
Alright. Let's hear them.
AARON:
Alright. My first pick is electron. I've been doing some stuff the last few weeks for work in electron and I'm a huge fan. If you need to write a native desktop app you should definitely look at electron. It's really, really cool and really, really easy to use.
My second pick is, so I used to be on this show a lot right? And I used to talk a lot about, throw in a lot of books. And so, I've read a ton of books since the last time I was on. I'm going to just pick one series. It's a four-book series. It's called The Synchronicity War. And it's future sci-fi. It's really, really cool. And I shared it with my friend, Dave Kiss and he loved it. And I've shared it with a couple of other friends and they really like it. So, I think you'll like it. It's cool. It's a four-part series. But check it out. The Synchronicity War. It's a really good book. And I listened to it on audible. The reader is really talented as well. So anyway, check it out.
CHUCK:
Alright. And just to throw this out there, we do have an Electron episode scheduled in December so it'll probably come out the beginning of January if everything goes to plan. Keep an ear out for that.
Burke, what are your picks?
BURKE:
I've only got one today. And I'm going to pick an app. I hope that's not too cliché to do that. So, I deal with a lot of stress and anxiety. I think that most people are no stranger to stress. But I [inaudible] suspicion that developers actually have it worse than people do, just because of the way that our minds tend to work. We're very much [inaudible]. And so, I've really been into this idea of mindfulness lately, especially when I travel in places, busy places, and I get super stressed out. And it's a very simple app. It's called PAUSE. And you put your finger on the screen and there's some nice, relaxing music. But it forces you with your eyes to follow this blob as it gets bigger and bigger and bigger. And the whole idea of mindfulness is that when you have anxiety you're always living in the future, never live in the moment. You're always worried about what's coming. And mindfulness forces you to live in the moment by focusing your mind. And so, this works really, really well for me. It's a paid app. It's totally worth it. I know a lot of times we're like, “99 cents? Man, I'm not paying 99 cents for that,” like that's so much money. But it's great. I would highly recommend it, especially if you're like me and you deal with a lot of anxiety. It's definitely a good way to focus and ground yourself.
CHUCK:
Alright. TJ, what are your picks?
TJ:
So, I've got one as well. I've been watching this show, TV show, Outlander. Which if you haven't heard of it, it's basically, if you've ever wondered what would happen if you touched a stone and you ended up going back in time to 1740 Scotland, then this is the TV show for you. Because that's essentially the entire plot. This woman touches a stone and Scotland goes back in time 200 some years. And drama ensues. But very good TV.
CHUCK:
Cool, what channel is it or what network carries it?
TJ:
It's Showtime. And I think it aired a year or two ago.
CHUCK:
Alright. Well, thank you both for coming. If people want to know more about NativeScript or about Telerik or about anything else that you both are working on, where should they go?
BURKE:
Oh, if they want to know about NativeScript they can go to NativeScript.org and can get the bits from npm. It's just a relatively simple npm install. If you want to know more about the Telerik Platform which we've talked about a little bit during our shameless plugs, that's platform.telerik.com. And if you want to know more about Telerik in general, just go to telerik.com and you can find us there.
CHUCK:
Alright. Well, thanks for coming. We'll go ahead and wrap up the show. And we'll catch everyone next week.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at
JavaScriptJabber.com and there you can join discussions with the regular panelists and our guests.]