Complexity

Developing Large Web Applications

As a front-end developer, you’ve probably heard about TypeScript. Maybe you even tried using it. But not many developers know what it is like to build a large-scale project from …

As a front-end developer, you’ve probably heard about TypeScript. Maybe you even tried using it. But not many developers know what it is like to build a large-scale project from scratch using TypeScript.

A year ago, with a team of eight front-end developers, we started rebuilding the entire Wix eCommerce solution; the new product is called WixStores. Most of the developers worked on the codebase at the same time. And working together without breaking one another’s code was a challenge.

The WixStores application was divided into several small projects. We started using TypeScript for only one of the projects. The others used pure JavaScript. After seeing the benefits of TypeScript, we decided to use it for all of the projects.

Developing Large-Scale Applications Today

Large-scale web applications are usually divided into several layers: the framework (such as AngularJS, Ember, or Backbone), the view (HTML with CSS, SASS, or LESS), and the language.

This blog post is focused on the language layer. Obviously, writing pure JavaScript is an option. But in a large-scale web application, it is less than ideal. Instead, there are languages that compile to JavaScript. These languages are very helpful as you will see next, and there are already a few of them. The most well known are CoffeeScript, ClojureScript, Dart, and TypeScript.

Technology Decoupling

CoffeeScript and Dart are languages that compile to JavaScript. Unfortunately, the generated JavaScript does not look anything like the original code. It is hard to understand, read, and debug. On the other hand, TypeScript is a superset of JavaScript. TypeScript generates JavaScript code that is easy to read and debug, and that looks very much like the original TypeScript code. This means that if (for any reason) you wish to return to plain JavaScript, you can take the generated JavaScript and work with it directly. In other words, there is no dependency on TypeScript, so it is easy to stop using it. With CoffeeScript and Dart it would be difficult or even impossible to do that.

Type Safety

As the name suggests, TypeScript is a strongly typed language, and type safety is the most important added value that TypeScript offers. When creating a small to medium JavaScript application with one or two developers, it’s OK to go without any type safety. But when the application grows, that growth might lead to messy code that is very hard to maintain and debug.

Taking advantage of types means that you will get type errors at compile time instead of runtime (or not at all). And when I’m saying “types, ” I don’t just mean numbers or strings, I mean interfaces with a very clear definition. For example:

interface CatalogAPI { productsCount : number; defaultCategory : Category; loadProductDetails(productId : string):ng.IPromise; getProducts(maxProducts? : number):Product; updateProduct(product : Product | DetailedProduct):boolean; }

It’s Optional

Type safety is a wonderful feature, but you don’t have to use it if you don’t want to.

On the WixStores team, we were strict about types when defining a class API. We wanted to be sure that the developer who calls an API will know how to work with it. Any misuse of the API or breaking changes to the API will raise compile errors.

Because TypeScript type safety is optional, in the internal function implementation, we allowed the freedom to work with no types. It was up to each developer to decide whether to use it.

It’s Just Another Test

The result of TypeScript’s compilation is of course JavaScript. The most obvious difference between the TypeScript code and the generated code is that the types have been removed—they are used during the compilation phase only. You can think of it as another test that runs at build time to verify that all the function calls are valid. We nicknamed it WarningScript.

API Definitions and External Libraries

Interfaces are great for describing APIs. For example:

function listProducts(products) { ... }

This function definition does not tell you whether products is a list of actual product objects or a list of product IDs. Also, you cannot tell whether this function returns a result. The only way to get this information is to investigate the actual code, which wastes time.

On the other hand, an API like this:

function listProducts(products:Product):Product { ... }

Tells you at a glance that products is an array of Product objects. The result is an array of objects. As you can see, the API can fully describe the function implementation without having to investigate the implementation. And most IDEs can work with this information and will give you real code completion and not just an estimation.

Working with external libraries like Underscore or jQuery might also be a challenge; you can look up the API by searching the web or investigating the library code. But when working with types it is much easier to find out how to work with the library correctly. You can find definition files for almost any library at DefinitelyTyped. Again, IDE code completion and compile-time type checking will use this information to alert you of any misuse of the API.

Source: engineering.wix.com
RELATED VIDEO
[Srijan Wednesday Webinars] Developing Large Scale
[Srijan Wednesday Webinars] Developing Large Scale ...
SQL Server 2008: Developing Large Scale Web Applications
SQL Server 2008: Developing Large Scale Web Applications ...
Download Developing Large Web Applications: Producing Code
Download Developing Large Web Applications: Producing Code ...
RELATED FACTS
Share this Post

Related posts

Choosing BI Solution: Tibco Spotfire or Tableau?

Choosing BI Solution: Tibco Spotfire or Tableau?

DECEMBER 17, 2017

Recently Business Intelligence (BI) is gaining increasing importance among successful companies. Business Intelligence allows…

Read More
Developing ASP.NET MVC Web Applications

Developing ASP.NET MVC Web Applications

DECEMBER 17, 2017

Join me and Christopher Harrison (@geektrainer) for a free, full day online training event on Developing ASP.NET MVC4 Web…

Read More