Bill Blogs in C# -- TypeScript

Bill Blogs in C# -- TypeScript

Created: 11/23/2015 4:28:37 PM

This past weekend, I was honored to speak at Boston Code Camp 24. I had two different talks.

The first was on creating Angular 1.x applications using TypeScript. It was a great audience, and I enjoyed the conversation that went along with the discussions. The slides and demos for this talk are available here on github. As always, the branches are labeled using the steps in the demo. You can follow along as the application grows.

The second talk was on creating Diagnostics and CodeFixes using the Roslyn APIs. This one had a smaller audience (which I expected). I was quite happy that the people who did attend were very interested in the topic. Slides and demos are here (on github again). The branches walk through the tasks of building a diagnostic and a codefix. The specific diagnostic was for Item 24 in More Effective C# (“Create only Non-Virtual Events”).

That brings me to my call to action for attendees. I’ll repeat it here: Would you be interested in a Roslyn based analyzer that enforced the rules in Effective C# and More Effective C#? Leave me a note here, and let me know what you think.

Created: 4/10/2014 12:54:59 PM

I’m glad that I was selected to speak at self.conference, coming to Detroit this May. 

The speakers and sessions are a strong mix of the technical community in this area. In addition to quite a few local speakers, other super smart folks from the midwest are apeaking.

I’ll be speaking about TypeScript, introducing web developers to this new language. I really enjoy working with TypeScript. It’s very much like working with JavaScript, except that I feel much more productive. I get more done in much less time.

I also want to point out Tony Surma’s talk on “Apps that work when nothing else does.” Tony is a fellow board member for Humanitarian Toolbox, a charitable organization that creates Open Source applications for disaster relief. I’m the president and a board member as well. We’d love to have your help developing these applications. And, as you’ll learn from Tony’s talk, there’s a lot of software product skills you’ll learn developing apps that have to run in a disaster zone.

Self.Conference promises to be a great, great event. Go to http://selfconference.org/ and register today.  See you in May.

Created: 4/8/2014 12:21:12 PM

Let’s start with the biggest story:

A public Roslyn Preview that’s Open Source.

The next versions of C# and VB.NET have progressed far enough that you now have a new public preview. The Roslyn Compilers now support all the existing features (C# 5, VB.NET 12). In fact, they have even added some new prototype features for the proposed C# 6 and VB.NET vNext releases. (VB.NET would be at version 13, but I haven’t seen a published version number)

Best of all, you can see the development and you can participate in the ongoing language design discussions. The Roslyn compilers are Open Source. You can view them here. I’ll blog more about the compilers and the new and proposed language features in the coming months. 

And TypeScript, don’t forget TypeScript.

In more language news, TypeScript 1.0 has been released. It’s development has been public and Open Source for some time.  It’s integrated into Visual Studio 2013 Update 2, which is available in Release Candidate form.I’ve been working with TypeScript for a while, and I’ll be covering it more here. In particular, this discussion on the null propagating operator is very lively.

In addition, there’s now the new .NET Foundation, which is the curator of several .NET related Open Source projects. You can see a number of .NET libraries and components in the foundation already, and I only expect that trend to continue. The .NET Foundation is a great example of how Microsoft is changing. Look at the current board members of the .NET Foundation. The board already includes prominent community members that do not work for Microsoft. I expect that to continue and grow as time goes on.

Both Roslyn compilers, and TypeScript are already part of the .NET Foundation assets.

Visual Studio Online

The Humanitarian Toolbox has been using the preview versions of Visual Studio. It’s a tremendous step forward for team collaboration in the cloud. The tools help you can more information about your application, and Applications Insights provides a nice extra. Quick edits in the cloud, automatic deployments, insights, and more. Oh, and it’s integrated with your local Visual Studio experience.

Azure Updates

This probably deserves several blog posts on its own. It’s a full time job just to keep up with all the new tools released by the Azure team. There’s a new management portal. New mobile services, new resource management,  Java VMs in Anzure, and more.

I need to dive in more, because it’s hard to keep up with what Guthrie’s team produces.

 

Windows 8.1 update

Most of these news features are for end users, not developers. They do represent a lot of feedback and represent a good direction. For Enterprise developers there are a couple great features. The enterprise side loading story is much better. Modern apps are much more economical for enterprises to deploy than with previous 8.x platforms. The IE Enterprise mode will also help enterprise deal with legacy web-based applications. However, I would still recommend that most enterprises consider any application that needs enterprise mode to be a technology risk.

Universal Apps, and all it comes with

Microsoft has been talking about unifying the Windows Phone, Windows 8 and Windows Server platforms for some time. That’s now gotten even more ambitious. Universal apps also can include iOS and Android devices, using the Xamarin tools. The idea that a common API set could be available across Windows 8, Windows Phone, iPhone, iPad, Android phones and Android Tablets is really innovative.  Also, these projects work across different IDEs: Visual Studio, Xamarin Studio, and (where someone has written the plug ins) Eclipse.

It means C# is, along with JavaScript, the one language you can use to develop applications across all the popular computing platforms today. .NET and C# is truly a cross-platform development environment.

There’s more changes that make this cross-device story compelling. There are changes in the Microsoft Store that make it easier and more advantageous to produce apps for both Windows 8 and Windows Phone. You’ll get more visibility across the stores, and you’ll get more touch points with your potential customers.

Windows Phone and Cortana

I’m impressed with the potential of Cortana. You’ll see lots of people saying that Cortana is “Siri for WIndows Phone”. That’s an oversimplification. Yes, you can talk to Cortana and it will answer you. But what’s really interesting over time is how Cortana integrates with you through your applications on your phone. Voice recognition and voice interaction is a great step. More interesting is how those capabilities will work across applications when integrated with Cortana. Can my scrum app alert me if I’m too aggressive on deadlines because of other commitments? Could a nutrition app integrate across a fitness app to change calorie allocations because of upcoming events, or days off? There’s a lot of potential. There’s also risk. Can those cross-application capabilities be added while respecting users’ privacy?  There’s a lot of potential hear, and I can’t wait to learn more and dive in to create new, useful applications.

Conclusion: Microsoft is reaching out to developers in a big way

I know this post had less detailed technical content than my typical post. There’s a lot of information that came from //build. I’ll drill into many of the areas for some time.

The big picture of all the announcements and the reveals at //build is this: Microsoft is reaching out to developers again. And not just the developers that have traditionally worked within the Microsoft space. They are reaching out to Open Source developers, mobile developers that concentrate on non-Microsoft platforms, and more. It’s a smart move. They brought out lots of technology that makes lots of sense.

The platform, the languages, and the tools, are first rate. I’m glad to see Microsoft reaching out to developers and changing their direction to match today’s developer community.

Created: 2/27/2014 5:15:32 PM

Yesterday, TypeScript 1.0 RC was released as part of the Visual Studio 2013 Update 2 CTP. This announcement is significant for several reasons.

It’s an important language milestone. A Release Candidate means the major development for the first version of the language is completed. Now, the remaining work is to ensure the first release of the language meets the necessary quality bars. For organizations that were watching TypeScript, but didn’t want to jump in too early and cope with the kinds of changes early adopters accept, this milestone removes a barrier. If that’s you, it’s time to leap in.

This new release marks the integration of TypeScript into the main Visual Studio toolset. It’s being delivered as part of a regular Visual Studio update. According to Soma, TypeScript will ship with VS 2013 Update 2. Yes, if you have Visual Studio 2013 (above express), you’ll have TypeScript soon. That’s another reason to consider TypeScript adoption: It’s going to be part of the standard, delivered toolset for .NET developers.

The more I learn TypeScript, the more impressed I am with the features and the design of the language. It extends JavaScript in several useful ways. I’m more productive in TypeScript than I am in plain old JavaScript. And being more productive means I get more done in less time. That’s always a good thing.

Created: 1/13/2014 4:09:34 PM

I was honored again by speaking at CodeMash on the TypeScript language. I’m not going to post my slides, because most of the talk was demo.

The demos are here on my GitHub page. I tried something new with this talk, and I hope it helps you follow along after a talk.

If you look at this page, you’ll see 41 merged branches. Each branch represents a step in the demo. The commit messages explain what I did in each step, and what you can observe a you switch to each new branch.

My labeling convention is to use <demoName>-<major step> for a branch on each task based demo. Inside each of those branches, you’ll find a branch named <demoName>-<major step>-<minor step>. There will only be one commit on those branches. These <minor-step> branches show the small steps that make up each demo.

For example, the second demo I did was “Migrations-02”. To follow along, check out branch “Migrations-02-starter”, and each step is “Migrations-02-01”, “Migrations-02-02”, and so on up to “Migrations-02-final”. The “Migrations-02” branch shows all the checkins in order.

I would not follow this checkin policy on a product repository, but it does seem to make it easy to follow along and learn. I would like your opinions on that. If you find this easy to follow, please comment here. If you can think of improvements, please let me know.

Created: 12/17/2013 7:35:35 PM

This entry continues exploring TypeScript by examining the code from one of the samples.  Today, I’ll look at the TypeScript version of the MVC TODO sample. This sample is a TypeScript version of an MVC / JavaScript sample.

The samples are now getting longer, and have more features in them. I’ve also posted some samples and explained some of the basic syntax. From here on out, I’m only going to extract small bits of the code, and explain the features that I haven’t yet explained. As always, the samples are online both as a working example and as code.

This sample has a simple TODOD checked list.  You can see it running here. You can add new tasks. and mark any of those tasks as complete. The source code for the TypeScript version is here. That source code also contains a link to the original JavaScript version on Github, if you want to compare the JavaScript and TypeScript versions.

Let’s look at what’s new in this sample.

The HTML file, index.html, demonstrates a few new features (at least for this series). It includes a number of common JavaScript libraries. This app also uses with Json2, Underscore, and Backbone. 

Toward the bottom of the page, there are two template scripts that are used by the Underscore library.

<!-- Templates –>
<script type="text/template" id="item-template">
    <div class="todo <%= done ? 'done' : '' %>">
        <div class="display">
            <input class="check" type="checkbox" <%= done ? 'checked="checked"' : '' %> />
            <label class="todo-content"><%= content %></label>
            <span class="todo-destroy"></span>
        </div>
        <div class="edit">
            <input class="todo-input" type="text" value="<%= content %>" />
        </div>
    </div>
</script>

<script type="text/template" id="stats-template">
    <% if (total) { %>
        <span class="todo-count">
            <span class="number"><%= remaining %></span>
            <span class="word"><%= remaining == 1 ? 'item' : 'items' %></span> left.
        </span>
    <% } %>
    <% if (done) { %>
        <span class="todo-clear">
            <a href="#">
                Clear <span class="number-done"><%= done %></span>
                completed <span class="word-done"><%= done == 1 ? 'item' : 'items' %></span>
            </a>
        </span>
    <% } %>
</script>

The script type is “text/template”, so the browser will not try to parse and understand these two scripts.  But, they do have valid id’s and can be referenced as HTML snippets by the other script code in this sample.

Let’s move on to the todo.ts file.

As in the previous sample, the start of the file declares type information for the types referenced from Backbone, Underscore, and JQuery. Unlike the previous sample, this sample declares those types inline.

Again, I’ll make my plug for DefinitelyTyped. All three of these projects are already part of that project. 

There are a few new bits of syntax in these interface definitions that deserve explanation.

Here’s the definition of the Model class exported from Backbone. Note the highlighted portions.

The any type and optional parameters and properties

export class Model {

    constructor (attr? , opts? );
    get(name: string): any;
    set(name: string, val: any): void;
    set(obj: any): void;
    save(attr? , opts? ): void;
    destroy(): void;
    bind(ev: string, f: Function, ctx?: any): void;
    toJSON(): any;
}

I’ve highlighted the ‘any’ keyword in green. Any variable of type ‘any’ corresponds to a value in JavaScript. Minimal static type checking is performed on a variable of type any.

The declarations highlighted in yellow are optional properties or parameters. These may be omitted from the calls.

Generics

The Backbone type definitions also provide the first example we’ve seen of Generics, the Collection<T>:

export class Collection<T> {
    constructor (models? , opts? );
    bind(ev: string, f: Function, ctx?: any): void;
    length: number;
    create(attrs, opts? ): any;
    each(f: (elem: T) => void ): void;
    fetch(opts?: any): void;
    last(): T;
    last(n: number): T[];
    filter(f: (elem: T) => boolean): T[];
    without(...values: T[]): T[];
}

The syntax for the generic collection (highlighted in yellow) should be familiar to most of my readers. TypeScript generics provide type safety while using TypeScript, but compile down to a typical JavaScript implementation. I’m not devoting much space to generics, because they should look very familiar to you. That might give you the impression that generics aren’t that important. Don’t let that mislead you:  Generics in TypeScript are *awesome*.

The other features that I highlighted above (in green) is the ellipsis before the parameter on the last method. That indicates a variadic  parameter. That’s the same as a ‘params’ array in C#, or other languages you may be familiar with. It means that the parameter list will be placed in an array, and that array is passed to the without method.

There’s one final new syntax element above that I’ll mention.  The ‘each’ method has a parameter that is a function. The signature for that function uses the arrow syntax popularized in C#’s lambda expression. And yes, I know I didn’t highlight it, but I was running out of nice highlight colors.

The implementation

The application starts running in response to the JQuery ‘ready’ event. Most of the code is plain old JavaScript, and there are enough comments to explain how the JavaScript portions work.

One TypeScript idiom deserves mention.  The TodoView re-declares its model property so that the model is type safe.

The Backbone View type contains a model property (of type Backbone.Model):

declare module Backbone {
   
export class Model {
        // . . .
    }

    export class View {
        // . . .
        model: Model;
    }
}

Later, when the Todo model and view are declared, the model property of the view is re-defined:

class Todo extends Backbone.Model {
    // . . .
}

class TodoView extends Backbone.View {
    // . . .
    model: Todo;
    // . . .
}

 

Now, other code inside the TodoView that references the model property will see the model property as a Todo object, not as a Backbone.Model object. Unlike in other Object Oriented languages, it does not declare new storage. Code accesses the same storage whether it’s accessed through TodoView.model, or Backbone.View.model. The only difference is that in TypeScript, the available members will match the declared type.

Created: 12/16/2013 1:34:31 PM

The next TypeScript Sample I’ll explore is the JQuery Parallax Starfield sample.  You can see it running here.  The source that I’ll be describing is here.

This sample creates the effect of a view at a starfield where some of the stars are closer and some others are farther in the distance. The stars that are closer appear to be scrolling faster, and the stars that are farther away scroll more slowly.

The Parallax effect is achieved by scrolling multiple copies of the same image by different factors so that it appears the nearer copies scroll faster than the farther copies. As I go through the code, you’ll understand what I mean in more detail.

 

The HTML Page

Let’s begin by discussing examining the HTML page for this sample.  First, there are several CSS styles that describe how to display each of the images when they are first loaded.  You can see that the #plax<number> styles are quite similar. The difference is the Z index, and the initial background position. The  Z index layers the different images relative to each other . The position provides an initial offset for the images so that each image starts in a different location.

 

<style type="text/css">
   
#plaxHost {
        height: 2000px;
        background-color: Black;
    }
    #plaxHost div {
        width: 95%;
    }
    #plax1 {
        position: fixed;
        color:White;
        height: 2000px;
        background-image: url(starfield2.png);
        top: 0; left: 0;
        z-index: 1;
    }
    #plax2 {
        position: fixed;
        height: 2000px;
        background-image: url(starfield.png);
        background-position: 1087px 0;
        top: 0; left: 0;
        z-index: 2;
    }
    #plax3 {
        position: fixed;
        height: 2000px;
        background-position: 577px 0;
        background-image: url(starfield.png);
        top: 0; left: 0;
        z-index: 3;
    }
    #plax4 {
        position: fixed;
        height: 2000px;
        background-position: 337px 0;
        background-image: url(starfield.png);
        top: 0; left: 0;
        z-index: 4;
    }
    #plax5 {
        position: fixed;
        height: 2000px;
        background-position: 145px 0;
        background-image: url(starfield.png);
        top: 0; left: 0;
        z-index: 5;
    }
</style>

 

Next, the HTML file contains 5 different div tags nested inside another div tag that will hold each of the images:

<div id="plaxHost">
   
<div id="plax1"> &nbsp; </div>
    <div id="plax2"> &nbsp; </div>
    <div id="plax3"> &nbsp; </div>
    <div id="plax4"> &nbsp; </div>
    <div id="plax5"> &nbsp; </div>
</div>

Finally, this references the javaScript files that comprise the application. Notice that this file must include JQuery (because this application uses JQuery). However, notice that it does not include the type definitions for JQuery (read below).

<script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.10.1.min.js"></script>
<script type="text/javascript" src="parallax.js"></script>
<script type="text/javascript">
    var p = new Parallax.ParallaxContainer(window, 0.7);
    for (i = 1; i <= 5; ++i) {
        var star_layer = new Parallax.ParallaxSurface(document.querySelector('#plax' + i));
        p.addSurface(star_layer);
    }
</script>

The inline script creates a ParallaxContainer object (defined in parallax.ts). Then, it creates and adds 5 ParallaxSurface objects (also defined in parallax.ts) to the container.

After this script runs, the HTML page contains the five images, and you can scroll the image to see the parallax affect.

The JQuery Type Descriptor

Next, let’s look at jquery.d.ts.  This is a type descriptor for the interfaces and variables this application uses that are part of the JQuery library.  It’s a rather large file, so I won’t repeat it here. You can see the full listing here. This file contains TypeScript definitions for JQueryAjaxSettings, JQueryXHR, JQueryCallback, JQueryPromise, JQueryDeferred, JQueryEventObject, JQueryBrowserInfo, JQuerySupport, JQueryStatic, and JQuery. After defining those interfaces, it declares external variable references for JQuery, and $, both of type JQueryStatic.

You’ll need to create a type descriptor file for any JavaScript library that you use. Or, you’ll need to find one. There’s a great Github project called DefinitelyTyped that contains type definitions for many common JavaScript libraries. These packages are also available as NuGet packages.  If you are using an external JavaScript package, look at this project first. Chances are there are already type descriptors for the library you need. However, if not, you should contribute any type definitions you need to create.

The Parallax.ts file

This file contains the main logic for the application.  There are a few new concepts shown in this file.

The first line directs the TypeScript compiler to reference the jquery.d.ts type descriptor file.

/// <reference path="jquery.d.ts" />

By referencing the type descriptor, this file can use any of the types and variables declared in the type descriptor file without generating any compiler errors.

The types defined in this file are contained in the module Parallax.

 

module Parallax {
   // …...
}

 

That provides encapsulation for those types. To reference one of those types, you must include the module name as a namespace qualifier (see the code above). There are two types defined in this file: the ParallaxContainer and the ParallaxSurface.

The ParallaxContainer demonstrates are couple new TypeScript features:

export class ParallaxContainer {
    private content: HTMLElement;
    private perspective: number;
    private surface: ParallaxSurface[];
    //  …...
}

The export keyword indicates that this class can be referenced outside of this module. The private keyword on the field definitions defines that these variables should not be accessed outside of this type. I say ‘should not’ because you can access these fields in the compiled JavaScript. The TypeScript compiler will generate errors if you access these private fields.

There’s a few other syntax elements that appear in this sample.  You can see the => syntax for a lambda expression:

$(scrollableContent).scroll((event: JQueryEventObject) => {
    this.onContainerScroll(event);
});

And, this snippet shows how TypeScript can directly call JavaScript libraries (JQuery in this snippet).

The onContainerScroll method is a private method that has a void return type:

private onContainerScroll(e: JQueryEventObject): void {

The rest of the code should be familiar at this point.  When you scroll, each of the images scrolls a percentage of the distance based on its z index. You can see that code in the implementation of the oncontainerScroll. 

Created: 12/13/2013 9:36:04 PM

I'm finding more and more developers are growing an interest in Typescript.  When I first started learning the language, I started with the samples here:

I'm starting a series of blog posts on each of these samples.  I'm taking the notes I wrote when I first started learning TypeScript, and updating them with my current understanding. The samples start quite simple. Each sample adds new concepts and new examples.

The first sample is your basic Hello World sample.  You can see it running here:

Exciting, I know.

The source code is a bit more interesting. You can see it online here. It shows some of the important concepts in Typescript:

The HTML source for this sample shows an empty page that loads a single .js file:

 <!DOCTYPE html>
<html>
 
<head><title> TypeScript Greeter </title></head>
 
<body>
   
<script src='greeter.js'></script>
 
</body>
</html>

The source is not a JavaScript file, but rather a TypeScript file: greeter.ts. That's the first important concept: Typescript files are compiled to JavaScript files.  TSC (Typescript compiler) generates the greeter.js file from the greeter.ts file shown here:

class Greeter {
   
constructor(public greeting: string) { }
    greet() {
       
return "<h1>" + this.greeting + "</h1>";
    }
};
var greeter = new Greeter("Hello, world!");
var str = greeter.greet();
document.body.innerHTML = str;

Let's examine each of the TypeScript concepts in this example.

Class

Typescript supports types using the class keyword. This defines the Greeter class:

class Greeter {
};

Constructors and Fields

Typescript supports a very concise syntax for defining fields and initializing them using a constructor. Constructors are defined with the constructor keyword.

     constructor(public greeting: string) { }

The parameter (greeting) is of the string type. Notice that the greeting parameter is prefixed by the 'public' access modifier. That is a parameter property declaration. That tells the Typescript compiler to create a public property of type string, named greeting. The property will be initialized to the value of the greeting parameter. 

Member Methods

The remainder of the Greeter class implementation contains a single method "greet". 

     greet() {
       
return "<h1>" + this.greeting + "</h1>";
    }

 The greet method returns a formatted string. Notice that he code does not explicitly declare the return type of the function. The return type is inferred  by the compiler based on the body of the function.

 Script

Scripts can contain code that will execute as the script file is loaded.  Here, that code looks like plain old vanilla JavaScript:

var greeter = new Greeter("Hello, world!");
var str = greeter.greet();
document.body.innerHTML = str;

It creates a new Greeter object. Then, it retrieves the greeting from that greeter object, and uses that string to set the InnerHTML property of the HTML document.

That's all there is to it. A small introduction to Typescript. I'll continue this series with other samples that include more features of the language.

Created: 11/1/2013 7:04:09 PM

I gave three talks at DevIntersection in Las Vegas. All the demos are on my GitHub page. 

 

The Modern C# demos are in the Modern C# repository.

The TypeScript demos are in the TypeScriptFlashCards repository.

The Practical LINQ demos are in the Practical LINQ repository.

In all cases, the commits mirror the changes I made during the presentations. Thank you for attending my talks, and I hope it was worth the time investment you made.  If you have any questions or comments, please leave them below and I’ll answer them with repository updates or new blog posts.

Created: 10/22/2013 6:20:15 PM

I'll be at DevIntersection / AngleBrackets next week. If you're going, I hope to see you there.

I'll be giving three different sessions:

Monday at 3:45: Modern C#

Too often, we teach C# by explaining features version-by-version. That practice leads developers to believe that they should prefer the C# practices we used at the turn of the millennium. It's time to teach C# 5 without taking students on a journey of the idioms we used in all previous versions. Instead, this would teach the language from the perspective of C# 5, and leveraging the idioms we use today throughout the material. Encourage developers to follow the practices we use now, for the reasons we use them now. Encourage your peers to leverage the best of modern C# instead of reaching for the classic answers.

Tuesday at noon: If TypeScript is the answer, what was the question?

Typescript promises to bring C# developers to the world of client JavaScript. But what about existing JavaScript developers? What about existing JavaScript libraries? In this session, we'll look at what Typescript adds to JavaScript, and how to integrate Typescript into the right places in your development, without forcing it into areas where plain vanilla JavaScript is the correct answer.

Tuesday at 2:15: LINQ in Practice

LINQ idioms can be used to write more readable code for many everyday problems. Yet many developers reach for the familiar imperative idioms instead. This session shows developers how to recognize common practices where LINQ would create more readable, maintainable, and extendable code. You'll learn to recognize imperative code smells and replace those with LINQ queries.  You'll learn to write those queries in ways that help other developers understand and leverage the LINQ queries you've created.

I'm excited about all three of them. It's a good mix of super new unreleased technology, new technology, and everyday practices that could be improved.

But wait, there's more. When I'm not speaking, I'll be writing code at the Humanitarian Toolbox Hackathon. We've made quite a bit of progress on a few different apps since last Spring when we held our first hackathon at DevIntersection. In fact, our first app is almost ready for trials with relief organizations. If you're at DevIntersection, take some time between sessions and stop by. Write some code for an open source project that will have a positive impact on the lives of people affected by natural disasters. Contribute, and learn something.

Oh, and we may have some surprise guests stop by during the hackathon.

If you haven't registered yet, there's still time. The conferences are co-located, so you can register for either Angle Brackets , or DevIntersection. You can attend sessions listed under either conference, and attend the hackathon as well.

I hope to see you there.

Created: 9/5/2013 7:06:23 PM

Or is it? Do you have an opinion?

I selected this title because that analogy helps me as I’m learning more about TypeScript. It has “truthiness”. But in a good way. It will help you understand the motivations behind TypeScript, and how its syntax and concepts relate to JavaScript syntax and concepts. For example:

  • Every valid JavaScript program is a valid TypeScript program. TypeScript tools understand and parse JavaScript.
  • You don’t have to use all the TypeScript features to get the benefits of some of them. Way back in the early days of C++, developers (myself included) convinced managers that we could use C++ as “A Better C”, without using any of those crazy object oriented features. We could use just some of the syntactic features and write the same old procedural programs we were familiar with.  The same is true with TypeScript: you don’t need to declare interfaces, classes, and Modules. Just use elements of TypeScript that you like, and continue with JavaScript constructs everywhere else.
  • TypeScript integrates with your existing JavaScript investment. Just like C++ programs could leverage C libraries.
  • TypeScript’s features are designed to be consistent with the existing JavaScript syntax and idioms. For example, properties in an object type literal or interface may be designated as required or optional. That optional feature makes typescript more consistent with existing JavaScript style than with static languages.
  • TypeScript’s compilers output is JavaScript. Just like CFront’s output was C.
  • TypeScript’s language features implement many common JavaScript patterns for classes, inheritance, modules. If you subscribe to the idea that Design Patterns indicate missing language features, then TypeScript has those missing features.

It’s “truthiness”, because if you take that concept too literally, it breaks down. TypeScript makes some features easier than in JavaScript, but it doesn’t feel quite as revolutionary as the jump from C to C++ (or maybe I’m just older). TypeScript isn’t changing the techniques used in JavaScript, like the shift from procedural to object oriented programming from C to C++. It is making Object Oriented constructs easier, but they aren’t impossible in JavaScript.

TypeScript is only one of a number of languages whose goal is to improve productivity for JavaScript developers. CoffeeScript and Dart are two other important efforts. I’m also not sure that TypeScript will ever reach the kind of popularity that C++ has enjoyed. I also don’t see TypeScript compilers added to all the popular browser platforms.

What do you think?  Is this a reasonable analogy to help people learn and understand TypeScript? Or is it a bad analogy that will stand in the way of developers learning it?

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.