Category Archives: Web

24 Months with TypeScript


It has been 24 months since I started working with TypeScript with our project at Harland Clarke. We were a very early adopter but even then 0.8 showed great signs of improving our team workflow and enabling us to build/maintain a large JS codebase. At the time, we figured that the quality of the JS output was clean enough that if TypeScript was abandoned we could continue development from the raw JS. Since then we have migrated the codebase across every release of TS and have a team of 5 actively maintaining and advancing the application(s). Overall it has been a great experience and has taught me a great deal about Javascript and team development.

Why use TypeScript?

Compilers are very smart, very fast, and very exact; Humans however vary wildly in all these areas. Humans make mistakes, I make mistakes, I make mistakes everyday. In a team environment my mistakes impact others, cause delays, and generally make a larger mess. When we started work at Harland Clarke we wanted to minimize our mistakes and be able to quickly correct before the team was impacted. We chose TypeScript to minimize human mistakes but over time we saw lots of additional value.

1) Compile-time errors > Runtime errors.

TypeScript will rather quickly show you complex errors at compile-time. This prevented non-valid builds from entering version control and resulted in a higher quality codebase. Better, these errors are very useful in both refactoring and seeing deeper into a codebase during development. With TypeScript we compile & edit more and test only when the build is valid.

2) You must be this tall to ride.

The compiler forced our team to a quality level before code moved into the team environment. Regardless of how senior or junior, everyone was accountable to the compiler. If your code did not validate, you learned why and fixed it. I know several developers improved the quality of code they wrote over time as a result. Some also found ways around the compiler but as we typed more of the codebase, more errors would surface for us to remove.

The type system in TypeScript is 100% optional. This is a great feature as you can “type-down” important areas of the codebase and all dependent code must conform yet leave other areas alone. We did this within our model classes and within our graphics api use ( CreateJS & Canvas ) and in these areas we were much stricter than others in terms of extension or use. Some of our more recent work was building a text/font engine extending CreateJS/EaselJS in TypeScript and we integrated this as an external library complete with its own type definition file, *.d.ts.

3) Validate all code at compile-time.

TSC takes all the code you feed it and validates it at compile-time. It makes sure that access or use of other developers code is valid. Even down to the type you pass in arguments to the type of data/object returned, to member variable. Over time this added lots of value in that every compilation is a full validation of the codebase. We know the app is valid across the whole codebase before we test.

4) Refactoring bliss

Refactoring in TypeScript is one of my favorite things. I tend to make all my changes at once and then run the compiler to see how the changes impact the codebase. This turns the compiler error output into a handy todo list with line/row numbers. Often times you will discover dependencies you never knew you had. Change a method name, compile, see everywhere it is used by line number. Change the data type passed, see all the incompatible calls. Delete a variable and see the impact. Upgrade the TypeScript compiler from 0.83 to 0.97 and see all the errors TS8.3-9.7p1 TS8.3-9.7p2 .

5) External Libraries

External JS libraries can be integrated seamlessly into a TypeScript project even though they are written in JS. The key is support for definition files. A TypeScript definition files describes the interface of an external JS library and adds type support to restrict your use of the api via the compiler. Rather than only be limited to TS libs, you can add definitions to structurally type your use of external libs like JQuery, VueJS, EaselJS and many many others. If you need a definition file, head on over to DefinitelyTyped for the latest from over 2,216 external libraries. If you cannot find one that fits, writing a definition file is fairly simple and easy to learn.

Is TypeScript appropriate for my project?

The real advantage to TypeScript comes in the form of type & interface validation. Most projects will benefit from this, some will not. My rule of thumb is 2+ devs and 5+ classes, anything past that and you will benefit tremendously from using TypeScript. Compiling between changes is not for everyone and for those coming from Javascript it can seem like a downgrade initially. Compared to pressing Refresh in the browser, running a compiler feels antiquated. In general, the benefits of team dev need to outweigh the individual compiler burden and often this is a tough sell on small projects. Many of the devs on our team (4 of 5) suggested we just use JS at the start, yet after we had lots of code (5 of 5) were thankful we used TypeScript. It will slow down your development workflow but it will improve code quality and reduce the testing cycle (no invalid builds are tested). This is a trade off that you will have to make but after 2 years, I feel strongly that slow and steady wins the race.

Integrating TypeScript

There are 100 different ways to structure a TypeScript project but after doing this 100 times, my ways are rather set in stone. I prefer a single build.ts file in the root of a project with internal references (/// <reference path=’../tools/requirejs/require.d.ts’/>) to the other project files in dependency order. By compiling one file, all files are processed and output like so:

// compile the project
tsc build.ts

//or with AMD module support
tsc -m 'amd' build.ts

I find this structure is easy to walk into and get working. It is simple and adding additional workflow above this is easy with grunt or gulp. Within our latest project we used gulp for compilation, example.

My issues with TypeScript

Having used anything for 2 years you run into a few things you want to see changes. Here is my list.

  • [NOTE: ADDED as Union Types ] Type cascade – Rather than only providing one type, I would love to hand the compiler a set of appropriate types like so:

var foo:number|string = 123;

var foo:Solid|Liquid = new Liquid();

  • TypeScript Configuration Metadata – It is hard to denote how you want referenced files handled exactly within a single compiler pass. While there is a notation for referencing files (adding external file into compiler within a .ts file ), there is no output notation other than use of import/export module syntax. Ideally one could add output values to the references to control compiler output. I prefer to have a single built.ts file in the root of the project and compile through it, thus the need for options for packaging, module syntax, concatenation, consolidating the __extends calls (subclass wiring), and optional file output at all (build.ts always results in an empty .js file). [NOTE: Turns out any file with a *.d.ts will not be output by the compiler but any references within will. This makes for an ideal entry point into the compiler with a single build.d.ts file. ]
  • Better ES6 support
    • Import/Export
    • Destructing assignments
  • Macros – I have found that you can extend the TypeScript language with Sweet.js. Being able to define new language level extensions to the compiler would be a great hard feature.

Summary

I feel lucky to have started using TypeScript when it first came out and have learned a ton about building larger scale Javascript projects. My consulting clients at Harland Clarke have benefitted greatly and hold a maintainable high quality codebase as a result. During our first 12 months of development, we saved at least 3 months by not testing invalid builds. Saving 9 dev-months (3 devs initially) of time is a non-trivial benefit yet it says nothing about the maintainability or quality benefits TypeScript provided. Our later projects have benefitted the same, yet we are rarely building from scratch and typed library reuse becomes even more beneficial. At first TypeScript holds you back by adding a compilation step but it accelerates team development by keeping each developer build valid and improves code quality.

TypeScript is easily one of the best technologies to emerge from Microsoft in a long time. Having seen it’s impact on the quality of our team output, I would strongly recommend using it. Everyone makes mistakes, but having a quality compiler highlighting those errors before they impact your project is a big win. TypeScript will continue to be my co-pilot for large Javascript applications.

Links

Cheers,

Ted :)

7 Months with TypeScript


Since December 2012, I have used TypeScript as my primary language while working on a large scale enterprise project due to ship next month. I want to share the details on how we are using TypeScript as a team and our workflow that has made our project a success.

TypeScript?

TypeScript is an open source language and compiler written by Microsoft that runs on NodeJS. The language is based on the evolving ES6 spec but adds support for types, interfaces that generates JavaScript (ES3 or ES5 dialects based on flag). TypeScript’s compiler is written in TypeScript and run on any compliant JavaScript runtime by default it is distributed as an npm on Nodejs. End of the day, JavaScript is generating JavaScript. For more information see wikipedia or typescriptlang.org.

Evaluation

In November 2012, we selected technologies and our initial evaluation of TypeScript proved surprisingly beneficial. While we evaluated Haxe, Dart, CoffeeScript, we quickly honed in on TypeScript given it is an ES6+ to JavaScript compiler. We wanted all code to be JavaScript but we wanted to inject structure into our development process and be able to lean on the compiler for validation and richer errors. Really our choice boiled down to either use JavaScript or TypeScript. From there we wrote several small scale prototypes and quickly exposed the following:

  • Validation – TypeScript enabled us to validate code usage cross-modules at compile-time. In assigning types to variables and to method arguments, we were able to effectively validate all call/get/set across every module, every build. If a property was set to type bbox.controls.Image, nothing would satisfy the compiler but an Image instance or a subclass.
  • Early errors – We would get very detailed errors from the TypeScript compiler and with the addition of types and interfaces, the errors got even more specific.
  • Zero calorie types – TypeScript’s types and interfaces evaporate at compile time leaving no trace of the language while generating clean JavaScript.
  • ES6 Today – TypeScript is based on ES6 with additions of types and interfaces. It let us write source in a modern dialect of JavaScript, yet output to compatible ES3, ES5 with a compiler flag. With support for a modern class syntax( constructor, subclassing, interfaces, export, modules ) it made code organization painless.
  • Build process – One of the first checkins and tests was to create a team build process with Ant. With a properly configured environment any developer could sync with SCM and build a working local server with all code packaged for development or production use. The build process integrates Less, RequireJS, Uglify2, TypeScript, template processing, and server generation.

Usage

In the months that followed our evaluation we settled into a team workflow with TypeScript that really benefited our project. The build process is at the center of development and our daily work. Every day looked like so:

  • Update from SCM
  • Run ‘ant all’ ==> Full build + start local server
  • Run ‘ant dev’ or ‘ant ts’ ==> Incremental build
  • Error at build or Test in Browser
  • Rinse & Repeat

build

I really enjoyed this model in that I found over time that we spent far less time in the browser testing than prior JavaScript projects. As the build would validate and catch syntax/interface/type/usage errors, we only browser tested when the build validated and worked. Once we all got better at decoding the TypeScript compiler output errors, we gained a level of productivity that I have not encountered in web development. It sounds odd to spend 5 seconds compiling but in the end it removed an entire class of useless testing of non-working code from our development schedule. This aspect alone saved us 2 months of time while dramatically improving the output code quality.

When we began development the quality and quantity of available TypeScript definition files was not ideal. Definitions allow you to strongly type the interface of JavaScript Libraries externally and thus your code must conform to the definition at compile-time. Since starting this project definitions have done a complete 180 with many contributions to Definitely Typed for just about any major or minor JavaScript library in existence. We utilized the definition files for Require, JQuery, Backbone, Bootstrap, Underscore, and EaselJS within the build process. To add a definition file you simply add the following reference statements to the file within your main .ts file:

Screen Shot 2013-06-25 at 5.53.00 AM

The references above are also how you add in any external libraries to TypeScript. In a way definitions, interfaces, and TypeScript classes all operate in the same way. In order to simplify our build process we unified all these calls in a single init.ts file which when called by the compiler loads in all TypeScript needed by the application. Even classes that are intended to be loaded via module are denoted here so that they are externally compiled to a module file. Note the use of the “export Class” syntax in this external module, this tells the compiler to keep the file external as a module and a compiler flag “–module amd” makes the compiler format modules to conform to either AMD or CommonJS format.

Screen Shot 2013-06-25 at 6.00.25 AM

Another elegant item is the module system in TypeScript for code organization. Each class and variable is exported into a path off the browsers window object making it global. We utilized the namespace ‘bbox’ for all classes and variables and with typing support, you can make a very well defined namespace for your application quickly. The module above starts in ‘bbox.controls’ and at runtime you can find this class exported to bbox.controls.Bounds. Considering we have 60+ classes to work with we used the module system to its limit and it never missed a step. You are free to export and type individual variables and whole classes this way so you are not locked into everything needing to be a class. In many ways a typed export variable works great for singletons within a module as it provide limits to the type written and location accessed. With the additions of modules and types, the way you work with JavaScript just changes and it is a blurry line what is considered bad practice. With a first class compiler that can detect overwriting an object with an array or a very specific class type, you begin to work differently as TypeScript induces its own working model as a language. It isn’t JavaScript, yet it is.

Over the course of development I found myself changing development strategies in terms of refactoring. I started to trust the compiler’s behavior to the point where I would intentionally change types, interfaces, and naming to break things in order to expose code affected. I would then correct all lines from the compiler output and refactor as needed. In many ways this has allowed me to work effectively within a larger codebase.

typescript

As for development environment, I went with Sublime Text 2 + TypeScript syntax, while the other developers on the team opted for JetBrains. I found Sublime to be a great environment for TypeScript, even without code completion, I had zero complaints. Given that the compiler can provide incremental compilation and richer ide integration I think it will be a matter of time before we see far more advanced TypeScript tooling in Sublime/Edge/Jetbrains offerings.

While I loved working with TypeScript (and will continue to do so) there is one escape hatch that every developer using it should understand. There are times when you will butt heads with the compiler and it will block your attempts to call a method or variable as typing information is unavailable. When this shows up, we found that associative array syntax would unblock the issue til we could fix thing up. Example: foo['myProperty'] foo['myMethod']() would allow you to access myProperty or myMethod on foo regardless of typing information. I know it sounds odd but just keep associative array syntax in your back pocket, you will need at some point.

Some project stats on the project:

  • 63 TypeScript Classes
  • 12 libs ( Underscore,Require , Bootstrap , Jquery , Backbone , EaselJS … )
  • All Build – 8 seconds
  • Dev build – 5 seconds
  • 149Kb Libs & 411Kb Classes

Summary

TypeScript has been a joy to work with over the past 7 months. Having had experience with types/interfaces in ActionScript/ES4, I took to TypeScript very rapidly as it supported the structure I needed, yet maintained the elegant flexibility of JavaScript. In many ways I know our choice in using the compiler really moved our project forward in both delivery date and in code quality. I cannot say I have ever been a Microsoft fan but TypeScript has ‘softened’ me, it is easily one of the best web technologies to arrive in the past 3 years. I am looking forward to working on more projects with it and evolving with the language/compiler ongoing.

This week I will be onsite at Build in San Francisco learning about generics in the 0.9 build and next month I will be speaking on TypeScript at both Senchacon and 360Stack.

Consider me a TypeScript fan.

Ted : )

Changes


Friday 9/28 will be my last day at Sencha and marks 20 days until the birth of my daughter. I am departing Sencha to focus on family and return to working as a consultant and entrepreneur.

I have been extremely lucky over the past 7 years to work for some amazing companies (Adobe, Barnes & Noble, Sencha) and I have learned a ton about business and large scale software development in the process. Sencha has been a great experience working inside a world class, fast growth startup at the heart of HTML5. In my short time at Sencha, we focused on enterprise, delivered major releases of every product, added 30+ people to the company, and welcomed a ton of application developers to the platform. It has been a distinct honor to work at Sencha, build a great developer relations team, and work with so many amazing developers in the community.

As an evangelist I only advocate for technologies that I believe in and my path has included Flash, Flex, Android, and Sencha. In the case of Sencha, I am giving up employment to build services using Sencha as a platform. I am not sure there is a better validation of Sencha and given the large scale use of Sencha frameworks at Adobe, SalesForce, Cisco, Concur, Morgan Stanley, and many others; I know this is a very sound decision.

Having started-up straight out of college, I have yet to see an entrepreneurial climate as good as today. With a command line, I can launch hundreds of servers, leverage a ton of revolutionary code, and work with amazing people remotely. The costs of starting-up have literally fallen an order of magnitude in the past 10 years and executing projects has never been easier. During my time at NOOK, I launched 63 apps which turned into a solid recurring revenue business. This success enabled me to leap quickly to Sencha and with upcoming family changes has evolved into my return to being a consultant and entrepreneur.

Long story short, I am an entrepreneur at heart, I love solving problems, and I love building things. This change allows me to focus on family while executing on a project that has been burning a hole in my pocket. For now… family, family, family!

Regards,

Ted :)

Joining Sencha: The Intersection of Applications and The Open Web


I am joining Sencha to build a world-class developer program but in a larger sense I am returning to the intersection of Applications and The Open Web. I wanted to share my thoughts on why I am returning to web technologies and highlight some industry trends that are rapidly driving change within the software industry.

I believe that we are witnessing a sea-change in the platforms upon which software is built and delivered. Long term, I believe all software will be built with web technologies across enterprise and consumer facing applications.

Here are a few trends driving this change:

1. Web Innovation – Browsers and the core fabric of web technologies are innovating rapidly again. CSS, JS, HTML are changing to enable running first class applications in the browser with no dependencies.

2. Web Performance – The performance of web technologies has eclipsed end user performance requirements. JavaScript performance has improved dramatically in the past 3 years and browser rendering performance is in most browsers now leveraging the GPU for rendering. Fast code and fast graphics are essential elements to building great end user experiences.

3. Computing Cost & Capability – The ecosystem surrounding ARM is lowering hardware costs while delivering exponential performance growth in mobile and will soon engulf desktop and server markets.

4. Touch – Sensors for touch both physical and virtual (Kinect) are enabling simpler UI across devices.

5. Native Capacity – Few companies have the team capacity to deliver native applications across multiple platforms successfully. I am seeing many developers leverage web technologies within native applications to simplify development and reuse existing content, servers, and services.

6. Utility Computing – Services are changing how software is created, sold, and deployed server-side.

7. Mobile – Everyone will have a browser in their pocket… Everyone!

Now while the trends and market opportunity seems crystal clear, the reality is there are actually very few companies actively delivering “professional grade” web technology solutions that “just work”. Sencha stood out for me for a few reasons:

1. Team – An exceptional team with world class leadership and focus.

2. Opportunity – The Intersection of Applications and The Open Web

3. Customers – Read the list, it speaks volumes.

4. Products – Professional engineering teams building high quality frameworks, tools, and services for developers.

I am very excited to join Sencha to build a world-class developer program and to return to investing in web technologies full time. Exciting times ahead!

Cheers,

Ted :)