We are going to explain how parts of NativeScript are developed in TypeScript and what that means for you in terms of developing your awesome application using NativeScript.
In 2012, Microsoft released an interesting language called TypeScript. This language is fully open sourced because the company felt it was something the JavaScript community needed. It is, in a nutshell, a superset of JavaScript with types and several other additional language features. If you write any code in TypeScript, you then have to use the TypeScript transpiler to convert the code from TypeScript back into JavaScript. One of the primary reasons people use TypeScript over regular JavaScript is that TypeScript offers the ability to do static type checking at the point it converts the code to JavaScript. So, you don't have a runtime hit, and you don't have to do a lot of runtime parameter checks if the code is all in TypeScript. This feature alone eliminates a type of bug that is very easy to access in JavaScript. In addition to static typing, it has several class/object type features that make inheritance and class definition considerably simpler and safer.
Note
Types possess the ability to add markup to code denoting the type expected:
private validateMe(name: string, password: string): boolean { };The string and boolean are declarations telling what the exact parameter types and expected return type are. This allows the transpiler to verify that the code matches the static types during the building stage.
Transpiler is a shortened term from translation compiler used to mean the code is converted from one language to another language. So, in this case, we are translating the code from TypeScript into JavaScript.
The NativeScript command-line utility, common modules, and components are all written in TypeScript. TypeScript is then transpiled to JavaScript before it is distributed for all us developers to download, install, and use. So, unless you are actually pulling the open source code from the NativeScript repositories, then all the code you will see is in JavaScript.
Fortunately for us, the majority of the differences between TypeScript and JavaScript are fairly minor, so the code transpiled to JavaScript in almost all cases is very close to the original TypeScript, which still makes it very readable.
Note
Telerik just released a brand new module in v1.5.0 that will allow TypeScript to now be a first-class citizen in the development of your application. If you don't use this module, then you have to manually transpile all your TypeScript code each time before you build an application. After you execute a nativescript install typescript command, when the NativeScript command does anything with your code, it will automatically transpile all your TypeScript code first. This makes your development a much more streamlined process.
Since the final output of all the code must be JavaScript, you are able to write any of your applications or modules in TypeScript, CoffeeScript, or any other language that can be transpiled into JavaScript. This book is going to focus on doing everything in JavaScript as this is what the final code output must be for all the devices, and it is the common language that binds everything together.
Common modules were created to solve the issue of JavaScript files polluting the global namespace with variables and functions that another JavaScript file could easily overwrite accidently. JavaScript allows you to redeclare or monkey patch your functions on a whim, which is part of what makes it so powerful. However, with that much power comes the ability to very easily shoot yourself in both feet simultaneously. Then, you are left scratching your head why you just lost both feet. To attempt to solve the issue of one included file function or variable being overwritten by another include file, developers came up with several techniques that evolved into the common module formats we use today. There are three standards available for you to use: the CommonJS module format, which is what node.js popularized; the AMD module format, which was designed for the asynchronous resolution of JavaScript files in a browser environment; and the brand new ECMAscript 6 module format, which, when finally released, should become the de facto module format. All three of them wrap the source code so that none of the code in a module by default can interfere with the global namespace. NativeScript follows the CommonJS module format where you use exports and module.exports to tell what parts of the code in the module you want to expose to outside parties. When you see var coolModule = require('cool-module');, this is the syntax that the CommonJS module format uses to load a module.