An Angular Wish List

Angular is an excellent web framework for creating large-scale production web applications. Many of its supporters would like to see it rapidly evolve to be able to tackle even more complex scenarios, so let’s brainstorm to come up with a list of potential ideas.

Our goal here is to come up with the list, which will later need to be pruned and prioritized. This article is my initial list of suggestions, but you and others of course will have additional ideas. Please add them in the comments section below. It would also be interesting to hear which of all the proposed ideas you think would be worthwhile as part of a future Angular update.

When deciding how to evolve any widely used framework there is tension between whether to add or not add new features. The worry is the framework might become bloated, but the goal is to provide an even more comprehensive solution that can better tackle diverse problems. Not surprisingly, application developers’ views of potential new features often depend on whether each specific proposed new feature brings concrete benefits to their own apps.

Even if it is agreed that a new feature should be added, another issue is where to add it. New features could be added to the main Angular project, or could be added as a layered project, or in a totally separate project independent from Angular. In general I would like to see the main project kept small, so the other two options are usually better, with a preference for the layered project approach, similar to Angular CLI or Angular Material.

Rendering

We’ll start examining where Angular could be extended by looking at rendering. Angular introduces the concept of a configurable renderer which is used by higher level Angular features and application components to render content to the screen in a flexible manner. A renderer needs to implement the  Angular rendering API. Angular supplies various Platform- packages that implement different kinds of renderers. Platform-Browser provides a renderer that writes to the browser’s DOM that we are all familiar with. Platform-Server provides a renderer that writes to an HTML file on the server which can later be downloaded.

The most interesting of the renderers comes from Platform-WebWorker, which allows rendering to be used in the context of a web worker. In my guide to the Angular source tree, I provide a chapter that describes Platform-WebWorker in detail, including the message bus and message brokers used to transfer rendering information from the web worker (which has no access to the browser’s DOM) to the main UI thread (which can access the DOM). Since Angular provides wonderful flexibility so application code that calls the renderer does not have to be co-located with direct access to the DOM, is there anywhere else this can be useful? Interesting usage scenarios include shared applications, X-Window style applications and rendering to documents.

Many corporate web sites have a chat button which allows a user accessing the web site to chat in text-mode with a company agent. Live-training websites would like to have the teacher and remote students share the same view, as would many remote product demonstrations for sales purposes. When the web site is based on an Angular app, it would be desirable to have the option of sharing the application with remote users (assuming security considerations are managed correctly).

There are many ways of implementing browser screen sharing – what is proposed here is to have a new Angular platform type (let’s call it Platform-Shared). It would have a composite renderer with functionality similar to what is both in Platform-Browser (to display locally) and in Platform-WebWorker (but the destination is across the Internet, rather than a different thread). It could be configurable whether the remote user only gets to see the rendered output or could also send events back (e.g. mouse click events, keyboard events).

The X Window System has the concept of a display server, which runs on the machine the human user sits in front of, and this offers a display service that remote applications can use to render on screen. Currently with Angular, the entire application runs in the web browser where the user is located. Imagine a new Angular Platform-DisplayServer that would allow the web application to run on some remote machine (e.g. in the cloud or a secure corporate data center) and remotely render to the user’s web browser. No application-specific code need run on the user’s web browser, only a generic instance of Platform-DisplayServer.

Building on the idea of rendering to a document as demonstrated by Platform-Server which renders to an HTML document, what about rendering to other document formats – starting with PDF and Open Document Format (ODF)? For many types of applications, we would like that what appears on screen could also appear in a document, which is easier to share with others, easier to edit in normal document editors and easier to print.

Angular Workspaces

Though not used much, Angular supports the concept of one platform and multiple applications running concurrently within a single browsing context (each application edits a different sub-tree of the same DOM). Imagine a new package called Angular Workspaces, that builds on this idea of many Angular applications running simultaneously.

Most users, when working with a small mobile device will only use a single application at a time; with a larger mobile device they may have two or three apps running in a split-window arrangement; with a laptop or a desktop, users very often work with many applications running in overlapping windows at the same time. It is the device’s operating system that supplies some form of desktop/workspace manager that coordinates the different applications.

A web browser is a different kind of workspace manager. It also supports multiple applications with each running in a different tab managed by the web browser. Angular Workspaces would be yet another kind of workspace manager - the workspace with its many applications runs within a single web browser’s tab (a single execution context).

Angular Workspaces could supply the same services other workspace managers provide. These might include authentication, isolation (e.g. run each Angular app in a separate web worker to prevent interference with other apps), app launcher (how to select and start an app), application discovery together with a cloud-based app store (learning which apps are available to run), app layout on screen (multiple overlapping windows and their positioning / sizing) and session management (hibernate a workspace with all its running apps to the cloud, and resume later in the same or a different browser).

Integration with Web Assembly

Many scientific / engineering / financial / audio-visual projects have a significant (non-UI) CPU intensive calculation engine coupled with a user interface and a messaging library to talk to remote APIs. That calculation engine is often written in C or C++ for high-performance. Up to now, these have run on the server. With the arrival of Web Assembly we can now run such code in the browser, opening up new architectural layouts. Angular should play nicely with Web Assembly.

TypeScript Language Features

Angular should make enhanced usage of TypeScript features. Now that async/await has arrived in TypeScript, it should become widespread in the Angular source tree, the Angular API and in Angular applications. The new TypeScript v2.2 adds expanded support for mixins and Angular should using mixins where appropriate. Angular should use TypeScript namespaces for its larger packages (specifically Angular/Core). We do not need namespaces at the top-level of all packages (the package itself is in effect the root namespace we would see in other programming languages). However, if you are a new Angular developer, then the wall of types presented as part of Angular/Core is daunting. The discoverability is low. Many new developers ask themselves “Among the dozens and dozens of types available, which am I meant to use for a particular task?”

Angular Graphics

Angular provides excellent support for general HTML elements but in the area of graphics it could do more. Three important graphics-related technologies are HTML Canvas, WebGL 2 and SVG 2. A new Angular Graphics package would be appreciated by developers involved in creating graphical apps.

Angular Protocols

Angular currently supplies an HTTP package that helps with client-side HTTP programming. It is a wrapper around XMLHttpRequest calls. An application could make XMLHttpRequest calls directly, but using Angular’s HTTP client package helps with dependency injection, supports replaceable backends (e.g. in-memory-web-api for test), responses are converted to RxJS event streams and finally XSRFStrategy is supported for enhanced security. Angular in future should similarly support additional protocols – specifically HTTP (server), HTTP/2, WebRTC and Web Sockets.

Angular as a System Programming Framework

Angular is great for web UI programming but once you learn more about all its rich capabilities, it becomes clear it could be a wonderful system programming framework as well. For a moment, let’s ignore the great UI features of Angular and just concentrate on how what is left could be useful for system programming - for applications and components that do not have a user interface.

Powerful Angular features not specific to user interface programming include hierarchical dependency injection, event emitters and support of RxJS for streaming processing, use of zones, integration with WTF (Web Tracing Framework), enhanced reflection, testability, metadata and decorators, internationalization, dynamic loading of Angular modules, web worker message bus and message brokers.

TypeScript (and ECMAScript) does not have a huge built-in framework (unlike other environments, such as Java or C# that have very large related frameworks). Hence a powerful framework like Angular can actually be of use above and beyond just UI programming.

For Angular to become the leading TypeScript system programming framework involves documentation effort, some consideration on the part of Angular Core team about how capabilities could be used in non-UI targets, and a little imagination where hosting is concerned.

Angular Host

At the moment, a full stack application developer has to contend with different hosts when developing web client code (using Angular in the browser), web server code (using Node/Express), native mobile/desktop app code (using Ionic/NativeScript/Electron) and non-UI/non-server system code (using Node). It is highly desirable to reuse as much as possible developer skill sets and codebases across all target hosts but this is not happening because of the difference among diverse hosts.

As we have discussed, Angular offers an impressive collection of system programming capabilities so imagine if new Angular-dedicated hosts were developed using Angular as the system programming framework that present a consistent API for all types of applications. We could have Angular Server Host (replacing Node/Express completely), Angular Mobile Host (replacing Ionic / NativeScript / Electron) and Angular System Host (replacing Node). All these hosts could use the Google V8 JavaScript VM and, where needed, one of a number of the available open-source HTTP & HTTP/2 frameworks, together with a small amount of new additional C++ code and these hosts could consistently present functionality to application code based on the Angular framework.

For example, currently we have RxJS-based Angular event emitters being used to deliver HTTP responses from the server to client application code. With a future Angular Server Host, we similarly could have Angular event emitters deliver HTTP requests from the client to server application code. This would mean that a developer’s knowledge of handling observable event streams in web client applications could be directly useful for web server applications.

Another example is dependency injection used to wire up an application’s structure from a dynamically configurable set of components – most Angular developers would really like to be able to use the same Angular dependency injection engine client-side and server-side. Yet another example is web worker messaging – this is very nicely implemented in Angular Platform-WebWorker for client-side multithreading and it would be desirable to be able to also use it server-side.

Going beyond system programming, there are other parts of Angular that could be used server-side and elsewhere. Many server web applications involve server templates being used to extract data from server-side databases or other middleware, evaluate an HTML-like template to generate HTML on the server, and send this down to the web browser. Imagine if such server-side templates were based on the existing client-side Angular Template Syntax. It would mean a full stack developer could leverage the skill of using Angular template syntax client-side and server-side, rather than having to learn two distinct templating engines.

We could also leverage the Angular layered projects, such as Angular Material and Angular CLI. Angular CLI could be used to generate the initial project layout not just for the web client but also web server application and mobile applications, and could generate shared code. Material design is an excellent initiative and Angular Material is an excellent implementation of it for Angular projects. It would be really nice to see it also being used as part of an Angular server-side templating solution. 

About the Author

Eamon O'Tuathail works for Clipcode where he provides mentoring / training / consulting for clients working on cutting-edge Angular projects. He has worked across Europe as a software engineer, technical architect, project manager and technical trainer on software development projects covering cloud-based storage, engineering management systems, eCommerce portals, protocol design, large multithreaded high-throughput financial messaging, security server platforms, X.509 Certification Authority, aerospace visualisation, seismic imaging and lots more.