Worlds Collide: The Convergence of Modern Web, Classical Web and Native Mobile Development Paradigms

For years, I have switched between building native mobile, classical web applications and modern web applications. The context switching was, well, painful, until now. Recently, I switched from building native iOS and Android applications to a modern web application, but this time the switch was to Angular 2 with TypeScript. The learning curve no longer felt daunting. New ECMA standards, TypeScript and Node improvements have organized the way modern web applications are constructed and delivered. Modern web applications now have similar implementation paradigms as classical web and native mobile applications.

Level Setting

To understand this evolution, let’s level set some terminology.

Native Mobile Application — An application that runs on the core operating system of a mobile device e.g. iOS and Android applications from the App or Play Store

Classical Web Applications — A web application with server side code that is processed and rendered dynamically e.g. Java Spring, .NET MVC/Webforms

Modern Web Applications — Static, single page web applications leveraging JavaScript technologies e.g. Angular, React, Ember

The Evolution

Native mobile applications and classic web applications have many commonalities when it comes to the programming details. They are often built with mature object oriented languages. They have lifecycle methods. They provide the luxury of a compiler. And they have well documented development patterns. The general structure of these applications is organized and easy to consume across language and platform.

In addition to the language feature similarities, applications written in object-oriented languages have well documented patterns and practices for dependency injection and IOC.

Modern web applications on the other hand have not offered the same advantages. Node provided a path and ingenious engineers crafted software to fill JavaScript language gaps. Using NodeJS, developers could start to inject module dependencies using require statements.

The frameworks and libraries that emerged, Angular, React, etc provided a new streamlined way to deliver client side web applications. But, the same organization, structure, patterns and debugging tools did not exist. For many places, that barrier was a risk, the learning curve was high and there weren’t enough skills to embrace the single page application model completely. It was confusing to understand exactly how the frameworks were working together. A lot of less than optimal code was written.

What’s Changed

ECMA and TypeScript

What is different with the emerging standards? How has the learning curve been shortened? Well it starts with the new ECMA 6 standards and TypeScript.

The new changes take many of the paradigms for building apps that felt forced in ECMA 5 and make them fully fledged features in ECMA 6. It all starts with import and export in ECMA 6 as well as TypeScript classes.

It has become much easier to create organized constructs that can be imported or exported amongst modules. In ECMA 5, the concept of object oriented JavaScript was achievable to a point. But as you pulled off the layers, it never worked quite as expected or as we would have liked. TypeScript allows the engineer to write code in an object-oriented manner that is transpiled into JavaScript.

Application Frameworks

The new standards are only part of the solution. The application frameworks and libraries bring it all together. For this post, I’ll concentrate on Angular 2. If you remember, I talked about classical web applications and lifecycle hooks that are organized by classes. I also mentioned dependency injection. These constructs did exist in the Angular 1, however it required a good understanding of JavaScript/Node to understand exactly what was happening.

Let’s look at the syntax of an Angular 2 Component:

At first glance, this structure should look similar to an iOS App written with Xamarin:

It is important to note: there are major differences in how a TypeScript applications and native mobile applications are compiled and executed. However, the structure and syntax is converging. For someone that has experience with classical languages, the JavaScript world is no longer as daunting. It is merely syntax rather than a complete paradigm shift.

Let’s take a closer look at some notable parts of this component. The import/export makes it much easier for the engineer to understand exactly what dependencies and modules the component is going to use.

The class structure allows the engineer to create a self-contained module with public and private variables and functions. Imported dependencies are now injected directly into constructors, similar to dependency injection methods used in classical applications.

The application really starts to feel like a classical MVC application. We can use many of the same principles and patterns that were used in classical web applications while fine-tuning those patterns to the nuances of the JavaScript language.

Additional Considerations

I’ve talked a lot about the positives of the new standards. However, there are some drawbacks.

1. The standard is emerging — these standards are still being developed as well as being implemented by browsers, so you may deal with some bugs. Additionally, if you are an organization that supports legacy browsers, you may not be ready for these standards.

2. What about the compiler and debugger? — You are still reliant on console logs or IDEs that support local debugging. React has done some work in this space introducing Flow for Babel. The build deploy process is streamlined and optimized with tools such as Webpack.

3. Versioning, Config and Environment Management — If you are building a web platform with multiple environments, versioning and configuration management is an important topic. Like JavaScript based web applications of the past the configuration constructs are not nearly as formalized as classical applications.