Friday, September 23, 2016

Is Angular the future of web development? WebAssembly is coming.

Web development has passed through three major architecture patterns. And a fourth is on the way which will add more choices for designers and keep developers busy as they blend the types both by design and confusion.

Google's Angular framework is an example of the latest style of architecture and with the release of Angular 2.0 has demonstrated that the Single Page Application is getting easier to develop. But it's not just another framework. It's on the architectural path that the web is taking in general. The question I want to address is whether or not Angular will be a long-term solution for the web. In doing so, the choices will become clearer how other styles are appropriate or not based on business needs.

The early server side web site

The 1.0 web, a term used after the web had evolved some, was the basic setup where the developer created pages in a text editor, loaded them on the web server, and a browser requested them for viewing. That's it at a high level. There were millions of documents that were available but no search engine like we have today. Directories indexed files like librarians cataloged books. Most of the cutting edge activity occurred through the 1990's but business and other people learned how to make static web pages well into the 2000's.

Web 1.0 - Development workflow for static web pages

As web servers evolved to handle more and more processing besides just delivering pages to viewers, form processing, state management, and templating systems increased in complexity. Eventually, the server became the point where pages were built using a favored language injecting data stored in a data base. .NET, Java, and especially php were the dominant processing languages for creating a dynamic web site refreshing the page for every viewer and every request.

Web 2.0 - Dynamic web site with server side page generation and client side JavaScript UI

This style I associate with the Web 2.0 name, has been the driving enterprise architecture since the 2000's and continues to dominate page generation for most corporate web sites. The web server has enlarged its scope of functionality to add features that caused the name change from web server to application server on the Java side. The Microsoft side just adds features. And now nginx is becoming the dominant web server, taking over Apache's httpd server lead as the top dog for handling web requests, due to its speed and low or no cost.

The web 1.0 returns

The architecture where the web server does no web page processing may seem like a historical starting point of design but it's really a better solution for achieving the fastest possible speed for a page request. Other use cases emerged in the last few years that put typical Web 2.0 server processing operations in the development workflow instead of the on-request process occurring during the page request.

For instance, if you have no or little updating to do on your web site, say once a month like many blogs need to do, you don't need to provide an up to the minute current state of the web page provided by processing out the page on every request. The hack that added complexity to the design to overcome that problem was caching but it has issues, so much so, that the recent HTML5 caching proposal has been shelved.

The easier solution is to create the pages in the development phase once or as needed by the business, upload them to the server and not do any page building on the server. This is called static site generation and can be achieved will any language. Templates, JavaScript, CSS, and any kind of technology can be used and the user will only get the fastest possible delivery.

Web 1.0 - Development workflow for static site generation

Other types of non-server processing workflows in the development cycle can be cobbled together with tools to advance the poor state of affairs with the old technologies of CSS and JavaScript. Recent advances to help build better, faster, more scalable code have resulted in multiple languages to transpile, or convert into another language, new languages like CoffeeScript, Babel, and especially TypeScript to JavaScript. LESS, SCSS and SASS are the leading languages to transpile into CSS providing an easier set of style rules to update and manage.

Web 1.0 - Development workflow for CSS

Web 1.0 - Development workflow for JavaScript

My personal favorite tool I use in my development classes for these types of enhancements is Microsoft's Visual Studio Code due to its great support for TypeScript and extensions that keep me from making a patchwork of grunt script calls to JavaScript packages. But JetBrains' WebStorm might be my pick if I were a paid programmer because of the amazing feature set it has.

The mobile 3.0 web app

So as the browser expanded to handle the needs of providing the user with a better experience, the renderer sped up, and the JavaScript engine sped up immensely, making game developers much happier. JavaScript's ability to process so much so fast enabled the UI of a web site to support a full application and add more features like the web server did. Mobile phones and tablets were trying to provide the same experience but with less bandwidth so the round trip to the server to pick up resources was not a good idea.

Web 3.0 - Web app with client side execution using scripts

The transfer of resources and the processing of them on the browser was the ideal and then managing all the operations of an application except for supplemental data access and security became the goal. Even those services are outsourced leaving the application with the ability to be wrapped in a hybrid application shell like Ionic so it could be deployed using a marketplace service from Apple or Google. Google recognized the need for outsourcing the basic non-client services and has been putting a lot of effort into their Firebase project.

The UI operations handled previously by a proprietary technology like a Java applet, Silverlight, or Flash, now with the demise of  those non-stardard add-ons, have to be managed with the only possible solution on the browser of JavaScript. But our ability to do full fledged client-based applications is increasing as we are able to produce better code for application building libraries.

Angular is that new kind of application framework that has finally figured out a blended solution for how to take bundled resources of HTML, CSS, and JavaScript and manage the user interaction on the browser so that no server side page building needs to occur. It uses a library of components to interact with for the app that you build into a browser's web page. Now it's a web app and not a web site. The routing, controller logic, data binding, and templating are all features of its client side framework that creates the single page application.

Execution environment maturity

An execution environment is anywhere where code runs under a controlled context. for example, the database server has stored procedures, the mainframe has COBOL apps, the midrange computers have RPG programs, PCs have Windows and Macintosh apps, and phones and tablets have proprietary apps. Even embedded systems are under the control of a type of small to large chassis that takes care of the computing such as an ATM machine, a cash register, or a flight recorder. We're seeing the flourishing of familiar development environments Linux and Windows for Arduino and Raspberry Pi single board processors.

But the systems evolved as did other execution environments. Code structures all started with a basic script. Then the code became structured with reusable functions. And then libraries evolved to package up groups of cohesive operations. And then those scripts became faster by compiling and building the code into a machine readable format. This is the maturity cycle that has happened and is happening with web languages.

The browser is an embedded execution environment. It runs under another execution environment but by a set of standards that allows for the same results to be expected from any OS and any brand of browser. The standards allow us to see the browser as a viable execution environment to code to. It's even possible to provide the browser execution environment without an OS as we've seen with the introduction of the Chromebook.

The final stage of web programming

So with the emergence of client side programming on the web, we have begun the full acceptance of the web browser as an execution environment which supports the mobile crowd well. We will see the maturity of the Web Components ideas both supported by and combined with JavaScript frameworks for many years to come. Polymer is an excellent example of this. The Angular framework now looks like a jQuery UI plug in framework for browser apps and will continue to grow with more "plug-in" libraries like the current Angular Material project.

But the final 4.0 step will be when we convert our JavaScript code into compiled code. This is now on the blackboard. It's called WebAssembly. We will keep our browser JavaScript APIs only they will be available to us in every major language like C#, Java, VB, php, and of course, JavaScript. Then we will compile our code down to the WebAssembly format and load it on the browser. All major browsers have committed to supporting this standard so they will add an engine to execute the code replacing the JavaScript engine's functionality increasing the speed of our apps around 10 times.

Web 4.0 - Web app with client side execution using compiled code

The structures of client-side development that we are designing will all be stable and useful but the code will be done in Visual Studio or Eclipse and new IDEs. I am guessing that the ability to start doing this kind of work will be in another four years or about 2020.

Angular's future

So, does this mean that Angular will fade away? Not likely since it's been the trailblazer for a successful framework in JavaScript. I expect to see clones in most languages for WebAssembly like Jangular and Nangular as they might be called. But the dominance of JavaScript as a primary language, the need for TypeScript, and the requirement to know the JavaScript set of development tools are all going to be less important in the near future.

I'm excited for the future of the web. It's not the web as we knew it. It's a new development environment that will influence other environments such as television and other places where we might see an embedded browser execution environment. Maybe we'll see new types of hardware environments emerging that tailor to VR instead of just putting the browser to poor use on our web-enabled refrigerator.

Whatever it is going to be, we can be assured that the browser has blossomed fully as a development environment and the rate of design change and churn of projects related to that will slow considerably. The design choices are stable, the languages are looking stable and it's time to mature our processes surrounding the use of the web.