News

Q&A: Creating Modern Client-Side Applications Using TypeScript and Angular

• By Becky Nagel
• February 10, 2017

Magenic Lead Consultant Allen Conway will be speaking at Modern Apps Live! (part of Visual Studio Live Las Vegas 2017) this March. One of his sessions will focus on building modern apps on the client side using Angular 2 and Typescript. We recently asked him some questions about his session topic and got these tips and tricks back:

What is your number one tip for migrating an Angular 1 application to Angular 2?
There was such an interest in the community developing in Angular 2 before it was actually released, which was a good and bad thing. The result of this was a slew of documentation and blog posts created around earlier builds of Angular 2, with tutorials and tips on migrating Angular 1 apps to Angular 2. However as the framework evolved and got closer to being released, the API changed in A2, thus rendering a lot of the information invalid and, frankly, misleading.

The best documentation for the current migration process can always be found at Angular's site (angular.io), and is inclusive of strategies like migrating to TypeScript, using component directives, project restructuring and finally integrating the upgrade module to make a hybrid A1/A2 applications.

What is the number one thing NOT to do when migrating an Angular 1 application to Angular 2?
Having a mindset that all of your existing Angular 1 application must be migrated to Angular 2 in one fell swoop is not a requirement. The UpgradeModule available in Angular 2 makes it possible to begin introducing Angular 2 components and using them in your hybrid bootstrapped application by downgrading them as A1 directives. You can then continue to convert A1 code to A2 code over time and ultimately ending up with a completely A2 (or Angular version.next) application. This process allows a slower and methodical migration, so that the pain of refactoring doesn't have to be done all at one time.

What is your personal favorite feature of TypeScript?
Having a C# background and enjoying managed OO code on the server, makes me really enjoy some of the TypeScript features like Interfaces that don't exist in JavaScript and may never exist in the ECMAScript standard for the language. Take a look at the following:

//Notice there isn't any code for an Interface in the transpiled JavaScript
interface IEngine {

    //Properties
    horsepower: number;
    cubicInches: number;

    //Methods
    start();
    stop();

}

class CarEngine implements IEngine {

    constructor(public horsepower: number, public cubicInches: number) {
    }

    start() {
        //Insert key into ignition
        //Put foot on brake
        //Start the car!
        alert('A ' + this.horsepower + ' horsepower engine started started!');
    }

    stop() {

        //Place car in park or neutral
        //Turn off ignition
        //Pull key out of ignition      
        alert('stopped');
    }
}

class LawnmowerEngine implements IEngine {

    constructor(public horsepower: number, public cubicInches: number) {
    }

    start() {
        //Prime the carburetor
        //Pull the clutch handle
        //Pull the cord
        alert('A ' + this.horsepower + ' horsepower lawnmower engine started started!');
    }

    stop() {
        //Let go of the clutch handle
        alert('stopped');
    }
}

    

While this code doesn't look that impressive to say a C# developer, to a TypeScript developer this is a gem to be able to have such clean and concise code that otherwise in plain JavaScript would be much more difficult to create. To see the proof, just look at the resulting transpiled JavaScript for the contrived example above.

What is the number one advantage and disadvantage of using JavaScript as a framework vs. ASP./NET?
I think the number one advantage of using a JS Framework and creating a JS App/SPA over an ASP.NET application is the benefit of leveraging the client and the browser and all its power to do the front end rendering, processing, caching, etc. to create high performance Web applications. The user experience of a SPA almost eliminates the latency seen in years past, and brings things much closer to a native feel in terms of response and interaction times.

I think the number one disadvantage is the learning curve of additional languages and framework nuances (i.e. actually having to really understand JavaScript/TypeScript), along with the mindset shift from moving the presentation logic from the server to the client. Once these are realized and the learning curve has been conquered, the yielding result will be some really well performing and rich Web applications.

What is the best thing that people will get out of attending your session?
One of the things I like best about the Modern Apps Live! tracks (and specifically the Web sessions I do) are the broad look at the whole process of building modern Web applications. This style is presented -- asopposed to a session on a very finite topic (which are fantastic in their own right), -- we will take a look at Modern Web Apps holistically and the many choices we made, the technologies used, and the 'why' in the decision making process. This will greatly benefit those wanting to take information back after the conference and be more informed about building modern Web apps from a broad sense, as opposed to only focusing on a select few details. Hopefully, attendees will have a greater understanding of what a client-side JS App/SPA looks like using the newest technologies when building a modern Web application.

Thanks Allen!