Adding TypeScript Support to Projects

Bits and Bytes: Adding TypeScript Support to an Existing Project

In the previous Bits and Bytes, we looked at Getting Started with TypeScriptnow we will see how we can add TypeScript support to existing projects.

Similar to getting up and running we are going to need to make sure Node.js and our TypeScript compiler is installed. Once that is complete we can add a tsconfig.json file to support our compiler options. For info on getting up and running check out Getting Started with TypeScript.

Once we have TypeScript support we can code away within our project. But most developers have third party JavaScript libraries to help with their website development. From jQuery support to full single page applications using React or Angular. In any of the cases, you still can create custom TypeScript libraries but the interaction with the third party libraries will be limited.

Here is how you can fix that.



In order for TypeScript to perform the type checking, the types of these libraries need to be defined somewhere. This is where type definition files help. They provide the compiler a definition file of the JavaScript code that is not typed a “definition” of how it should be. We can add each definition file in the typings directory under a library of choice (ie angular, jquery..etc.). and the file extension for such a file is .d.ts, where d stands for definition.

So where can we get these files? or the GitHub repository. There are 1000’s of libraries out there and documentation on how you can create your own.

Once you find your .d.ts file, add it to your project and you should be able to enjoy the benefits from TypeScript from autocompletion, to syntax errors to member documentation.

Try it out and let me know what you think.

Bits and Bytes: Getting Started with TypeScript

You might be wondering what is TypeScript. Is it yet another programming language I need to learn? Another set of API’s and documents to read through? Yes and no. It is a superset of the programming language JavaScript. What does that mean? Well, as a “superset” it means everything that you love (or hate) about JavaScript is still there but now you have the ability to create classes, modules and interfaces to help build your large scale applications and components. Don’t worry about compatibility since at the end of the day it compiles down to simple JavaScript. What is also cool is you can start using TypeScript immediately. If you know JavaScript, you know TypeScript. Your developers and your apps can take full advantage right now and incorporate current JavaScript libraries if needed.

Let’s get started or watch the video.


Installing TypeScript

Remember, any browser, any OS, any host can accept type script. These instructions are platform agnostic so follow along.

Make sure you have Node.js install. I won’t go over that but it is as simple as going to and downloading it for your OS.

Once you have NodeJS installed you can add the TypeScript compiler via the package manager.

To confirm if it installed correct type in tsc and you will see the list of compiler commands


Editor Configuration

You can use an editor of your choice. Visual Studio 2015 comes with TypeScript support out of the box. If you are running a Mac or even Windows, a nice editor to use is Visual Studio Code. Lightweight and TypeScript support. I will continue the rest of the article assuming you are using VS Code.

Your project needs to have a defintion file to allow the compiler to understand the settings it needs. Open up a new file and save it as tsconfig.json. Intellisense should be able to start helping you create the properties within the file however a simple one to get up and running would be something like this:

The items to note here are target. You can specify es3, es5, es6. What that means is you can code to the E6 or E7 specs and output JavaScript to E5! So you can use the latest and greatest features of the new ECMAScript spec but still support browsers that are not there yet. For more information on all of the property options check out the GitHub page for detail.

Now, when we create a .ts file as part of our project we will have super rich and exciting experiences with validation!

Writing TypeScript

Create a new file and call it helloerror.ts

Since TypeScript is JavaScript we can add the following to that file:

Done! You just created your first TypeScript file. But before we get ahead of ourselves you might ask what about the Types and all of the cool stuff. Lets move on and change up our code a bit.

We just added a string type to our parameter. If we change myErr to a number we will get a compile error. Lets now add one more change.

Now we have an object. However over to see the intellisense to see what is being returned. Now we can debug a bit better. Understand our code when it becomes a bit large in scale. Bringing modern development to JavaScript.

Make a TS to a JS

Now if we try to run this in our browser it will not work. We still have a TS file and we need a JS file. We could issue the build process from the command line (tsc helloerror.js) but as you can imagine that would get tiresome after a while.

Let’s use some build tasks within VS Code. Open the command palette with F1 and type in Command Task Runner and hit Enter

This will create a tasks.json file in the.vscode directory with an example output. You can look through and optimize your build but we just need to update the path within the args property to the path for our helloerror.ts file.

Press Ctrl+Shift+B to kick of the build process and you will see helloerror.js show up near the TS file. Let’s open the file and see what we get.

Holy Cow! It looks like JavaScript! That is because TypeScript is JavaScript!

If there were any build issues they would have shown up on the lower left hand side of the editor.


Now you know TypeScript. Next up is how to take an existing application and add TypeScript support to it.


Website Debugging with Vorlon.js

I have worked for digital agencies for most of my career. I was a developer and eventually became the Director of Technology at a few of them. I have worked with web technologies since 1996 and have gone through iterations of design and build trends. From the Adobe Flash splash-screen phase to home page takeovers. From content needing to be “above the fold” to iframes to ActiveX and more! When I was working at Byte Interactive from 2003 to 2007 we were a big .NET and Flash web agency. We did some PHP and Java but most of our clients were .NET. In the 06/07 time frame we started dabbling in the Mobile design space. It wasn’t until we were bought out by Story Worldwide in 2007 when we started to get more into the mobile space. We worked on iOS and some Android and mobile web as well. I then left Story in 2010 and became the Director of Mobile Technology at Affinion Group. This is where I started to get heavy involved with the Mobile Web. From build patterns to testing on all sorts of devices. The “band” was getting back together in late 2010 (ex Byte and ex Story) to form a new company called WELD Media. I jumped in as VP of Technology and we supported web and mobile web heavily before I joined Microsoft.

Marshall St Mayhem
Marshall St Mayhem

During all of these companies we had many types of projects. Ranging from small promotional websites to full blown eCommerce applications. We had to support IE 7 for some time as well as all of the newer mobile devices. When it came to testing we used a bunch of methods that have stood the test of time. Different browsers. Browser add-on (Firebug, YSlow, Web Developer Toolbar) we used F12 and inspect element heavily. Heck, we even set up old PC’s and Macs as a test lab. We purchased iPod Touches, iPads, Android phone and tablets. But the common denominator with all of these is you had to be near the device or using the browser to help debug. It did not matter the “tool” you used. You had to open up the website and see for yourself or try and replicate the issue. And there were issues. As a developer, you are able to keep your dev machine up to date. But not so much your clients. Especially when the IT departments lock down versions.

QA Lab - Photo Credit: Library of Congress
QA Lab – Photo Credit: Library of Congress

I remember a few of our clients were still running IE6 when IE8 and Chrome were the standard. IE6! Ugh, that was the absolute worst. Even better, they might be using the latest version of a browser but the plugins are out of date (see Flash) or not installed. There is nothing you can do when you are trying to debug that type of issue other than heading down to the clients office and see for yourself (we did this a few times).

These issues are all present today and even worse. With the explosion of connected devices accessing the web makes it even harder to debug and troubleshoot an issue. How many flavors of Android are there now? Last count – 10! Even iOS has a lot. And lets not even touch on screen resolution.

So what happens when your client calls you up after the project has launched and says “I am looking at the site on my home computer and it does not work” or “The site is not working on my mobile phone”. Aside from saying the typical developer line “it works on my phone/computer”, what do you do?

Client on phone - Photo Credit: Library of Congress
Client on phone – Photo Credit: Library of Congress


In comes Vorlon.js. The remote debug web tool. It is ideal for situations like this. A simple line of code on your website and you can inspect til your heart is content the issue on your clients device. How does this work you say? Magically! Not really. Vorlon.js is built upon some great development library standards like Node.js, Socket.IO and Express. Vorlon.js runs on it’s own server (or Node.js server) to host the dashboard and the service. The service is using Socket.IO to get a connection to the dashboard as well as the various devices that we be connecting to the site that you are debugging. The site that you are debugging contains a reference to a JavaScript file that is served by the Vorlon server which contains all of the plugins and client code to interact with the client and the dashboard.


Get Started with Vorlon.js

Lets talk about how we use it and get started.

First you need to make sure Node.js is installed. Head on over to and download and install for your platform of choice.

Once installed, create a project directory somewhere on your computer and you can utilize the Node Package Manager to install Vorlon.js.

That will install Vorlon.js. The -g option with NPM installs the package globally. So you will not see the files in your project directory. You will have to navigate to the directory that global packages are installed to if you want to modify or copy the installation. On Windows you can find it at C:\Users\username\AppData\Roaming\npm\node_modules\ on a Mac /usr/local/lib/node_modules.

Once installed, you can issue the vorlon command to get the server up and running

Now you have a server running on your localhost on port 1337. To get access to the dashboard, just open your favorite browser and navigate to http://localhost:1337/dashboard/.


Start using Vorlon.js

In order to start debugging you will have to add a single reference to your client project.

Gifs N Giggles Released for the Windows Store


My newest app has jus made it to the Windows Store. It is called Gifs N Giggles. The app is powered by and utilizes its repository of animated gifs for you enjoyment.

My first release is just consuming the Giphy API to show the top trending and most recent gifs. There is a feature called “Make me Giggle”, which will get a random gif. Sharing is done via the Windows charms bar for now.

My next release will add some for features. I am thinking of adding a meme generator, like and dislike functions, rating/ranking and more.

I am using the MVP (minimum viable product) approach to get a product in the market, test and gather feedback and iterate on it.

gifs n gigglesgifs n giggles


Go download it now and let me know what you think.


jQuery Accordion with 8 Lines of Code

Ok.  Maybe more than 8 lines of code but very little.  I have been working with another agency (that will rename nameless) on a mobile web site for a client of ours.  The agency provided the HTML/CSS/Images and Script for our technology team to implement.  We hook up all the back end and call it a day.

The section that came into question was an ‘accordion’ style UI for a set of FAQ’s and other content.  When I first loaded up their pages, everything worked fine.  Upon further inspection of their code I noticed a lot of JavaScript libraries that were not needed.  They included jQuery AND Prototype along with some effects and accordion scripts.  (Prototype alone is almost 100kb in file size and the other scripts were 42kb.  That still does not include the 70kb for jQuery)  I thought to myself, this is a mobile site…why have extra scripts if not needed.  To make matters even more funny, we are supporting Mobile Safari (iOS), Mobile Chrome (Android) and the BlackBerry Browser (RIM), it does not work in BlackBerry at all.  Forget enabling or disabling JavaScript it just does not work.  Even the elements are hidden.

So it got me thinking about the old saying, “if you want something done right you have to do it yourself”.  So I did.

I removed all the libraries except for jQuery and made all of the elements visible by default.  Basically if a user does not have JavaScript enabled then they can see everything.

Here is my HTML

Styles and other HTML can be wrapped around it. You can change the paragraph tags to div’s if needed but that is the structure you need more or less.

Now for the JavaScript.

Make sure you embed jQuery (I did from Google)

Then hide all open content containers:

If the element does not have the ‘current’ class then we need to first remove the ‘old’ ‘current’, close the ‘old’ ‘current’ and open and set the new ‘current’.


Here is the final:

Depending on how you format the code and what you count as a ‘line’ it can be about 8 lines 🙂

Updated GitHub Repository

Demo here – View in Mobile Browser.  Desktop browser will work as well.  Works on iOS, Android, BlackBerry.