This week Dani Wiehl and I were giving a presentation about Microfrontends and the SCION Workbench at Voxxed Day Zuerich.

The slides are available on Slideshare:

The recorded presentation is available on YouTube:

Frontend Monoliths: Run if you can! — Voxxed Day Zuerich, 2019 was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Es könnt’ alles so einfach sein, isses aber nicht .

TLDR: Find the demo code here.

State-management in Angular can be a complicated topic. There is an abundance of 3rd party state management libraries: NgRx, ngxs, Akita … to only mention the most popular ones. These libraries are opinionated and have heavy implications on the architecture of an application. They imply concepts for separation of concern and immutability that are not easy to understand and implement.

I have seen a great share of over-engineered Angular applications, where zealous engineers implemented state management that looks like a fully automated Tesla Gigafactory … for simple “forms over data” applications.

As a consequence I regularly see teams struggle to extend and maintain these applications once the zealous engineers switched to the next project.

Yet there is also a desire for simpler state management:

• The future of JavaScript state management is less state management…
• My favorite state management technique in Angular — RxJS Behavior Subjects

Both articles suggest observable data services as a simple alternative to a full fledged state management library. The official angular documentation also suggests a similar design.

The pattern of the observable data service looks similar like this:

export class CounterComponent implements OnInit, OnDestroy {
  currentCount: number;

  constructor(private counter: CounterService) { }
 
  ngOnInit(): void {
    this.subscription = this.counter.getCount().subscribe(
      res => {
        this.currentCount = res.value;
      });
  }
...

Yet there is an even simpler and more intuitive way to do state management in Angular…

Just use Angular Change Detection!

export class CounterComponent {
   
  constructor(private counter: CounterService) { }

  get currentCount() {
    return this.counter.currentCount.value;
  }
...

Here we just leverage the default change detection of Angular with a stateful service:

• In templates you can just bind to properties of the service (using getters on the component).
• Then you can simply mutate these properties on the service.
• Angular default change detection will do the rest.

I created a demo project illustrating the concept by implementing the same simple counter demo from the post My favorite state management technique in Angular — RxJS Behavior Subjects.

I think this is the simplest and most intuitive way to implement state management. It is a form of “transparent reactivity”:

• The state is mutable data
• Any change (mutation) of the state is automatically shown in the UI (the framework “reacts” by updating the UI)

Angular gives us “transparent reactivity” out of the box when we use the default change detection.

This works with any shape of state. You can use deeply nested state and just mutate any desired property.

There is no need to implement a concept of “immutable state” (which is a paradox in most applications anyway).

There is no need to model state changes and reactions explicitly via observables and subscriptions. No need for RxJS at all!

The key takeaway: Default Angular change detection enables real simple state management!

I wonder why this is not documented more prominently …

Sometimes a simple solution is good enough. You should carefully consider if you really need ChangeDetectionStrategy.OnPush or even RxJS for state-management. What are the advantages compared to a simpler architecture? What are the trade-offs for your specific project? Can you really prove that a more complicated architecture pays off?

If you are going for a more complicated architecture, make sure that you get real benefits out of it. If we look at the demo from My favorite state management technique in Angular — RxJS Behavior Subjects I see more disadvantages than advantages:

• With a Subject-based solutions like this we often have not a single source of truth any more: Each component instance that subscribes to the service has its own state. These distributed states are programmatically synchronized via pub-sub of the Subject (this could be avoided by using the async pipe instead of subscribing programmatically).
• Moving away from a single source of truth for state-management to distributed state opens up the potential for many bugs where the states might diverge (i.e. race conditions)
• Moving away from managing a single source of truth to the notion of message-passing between components via a service might quickly lead to a tangled web of communication paths (remember “scope-soup” of AngularJS)
• Additionally subscribing to Observables comes with the need of unsubscribing which is another type of state (typically managed by the component lifecycle). When you rely on Angular default change tracking the components can be pure and stateless.

The Most Simple State Management Solution for Angular was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Initialize with TypeScript

create-react-app officially supports TypeScript since version 2.1 (as a consequence the fork create-react-app-typescript has been deprecated).

The documentation of create-react-app nicely describes how to transition from a JavaScript based project to TypeScript.

However if you want to start a new project with TypeScript there is the undocumented --typescript command-line argument:

npx create-react-app —typescript my-awesome-project

This is even easier than to create a plain React project and then adding TypeScript later on.

Using webpack-bundle-analyzer

Update 2019–03–30: Using webpack-bundle-analyzer has been deprecated an the flag —-stats has been removed in CRA v3. You should be using source-map-explorer instead by running: npm i -g source-map-explorer and source-map-explorer 'build/static/js/*.js'.
The following paragraph is deprecated:

webpack-bundle-analyzer is a nice tool to visualize the content of JavaScript bundles/chunks.

In order to use webpack-bundle-analyzer webpack has to be run with the flag --stats. But create-react-app hides the call and configuration of webpack.

Fortunately you can pass the flag --stats to react-scripts (the build abstraction of cra) like this:

npm run build -- --stats

This generates the file bundle-stats.json in the public directory, which you then can use with webpack-bundle-analyzer:

npx webpack-bundle-analyzer ./build/bundle-stats-json

This feature is currently undocumented (documentation was removed), because the CRA team thinks the labelling of webpack-bundle-analyzer misleading, see this GitHub issue.

Hidden Features of create-react-app was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

One simple/naive approach to break up a big single page application is to split it into different single page applications which then are loaded on the same html document.

Unfortunately it is not possible to run several create-react-app applications on the same document because the JavaScript bundles resulting from a create-react-app project is not without side-effects: The bundled WebPack runtime writes an object on the global scope, which prevents to load several such bundles.

The following steps illustrate the problem and show how to fix it.
The resulting code is available here: https://github.com/jbandi/multi-spa-experiment

The Setup

npx create-react-app react-app1 --use-npm
npx create-react-app react-app2 --use-npm

Changing the second React app to run on another port in development mode:

// package.json
scripts: {
	"start":"PORT=3001 react-scripts start"
..}

Change the DOM node on which the second React app is bootstrapped:

//index.html
<div id="app2-root"></div>

// index.js
ReactDOM.render(<App />, document.getElementById('app2-root'));

Run the first React application:

cd react-app1
npm start

Run the second React application:

cd react-app2
npm start

Load the second React app on the document of the first React app:

// index.html
<div id="app2-root"></div>

<script src="http://localhost:3001/static/js/bundle.js"></script>
<script src="http://localhost:3001/static/js/1.chunk.js"></script>
<script src="http://localhost:3001/static/js/main.chunk.js"></script>

Unfortunately this does not have the expected result: We only see the second React app bootstrapped on the page.

The Problem

Somehow loading the scripts of the second React app has a side effect and prevents the bootstrapping of the first React app!

It turns out that the WebPack runtime is the problem here. The WebPack runtime adds an object to the global scope which is used to lazy-load chunks. The default name for this object is webpackJsonp.

The Solution

The name of the webpackJsonp object can be configured in the WebPack config.

This needs to be changed if multiple webpack runtimes (from different compilation) are used on the same webpage.

To get access to the WebPack config of a create-react-app project, you need to eject or use another customization mechanism like customize-cra.

Then you can change the Webpack config like this:

// webpack.config.dev.json
...
output: {
	...
	jsonpFunction: 'jsonpApp2'
}

Once you have changed the jsonpFunction of your second React app to a unique value, you must restart the development server (npm start)

Make sure that the document of the first app still references the correct scripts from the second app. Sometimes WebPack decides to rename the chunks…

And voilà: Both applications are bootstrapped on the same document:

Note: I only showed here how to adjust the WebPack configuration for the development build. The same change is needed for the production WebPack configuration.
For production the project also has to solve the challenge of adding the correct script names to the integrating document, since WebPack is typically configured (i.e in create-react-app) to add a hash of the script content to the script name.

Hosting multiple React applications on the same document was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I wrote about “To use Angular CLI or not?”, I claimed that there was not much risk involved in starting a project with Angular CLI, since ng ejectallowed you to change your mind later and jump to a vanilla Webpack setup.

This has changed since AngularCLI 6: the eject command is now disabled.

Relying on Angular CLI has just become a much bigger risk for your project.

When I wrote about “Angular vs. React: The CLI” I claimed that I have not yet had a mandatory reason to eject. In the meantime I have come across several cases where the is a need to modify the webpack config of an Angular CLI project, which could be achieved witheject … but not any more.

One reasons is an integration with three.js. Many three.js extension rely on the global variable THREE. The typical solution in a webpack build is to expose THREE globally via webpack config… bad luck, with Angular CLI v6 you don’t have that option any more.
Other solutions are much more hacky …

Another nasty example where you typically need access to the webpack configuration is when you want to use the popular library Moment.js.

Let me illustrate the problem:

npx @angular/cli@6.1 new my-project
cd my-project
npm i moment @types/moment

Now use Moment.js in your project, i.e. in main.ts :

import * as moment from 'moment'
console.log(moment());

Now run the build and have look at the bundle:

npm run build -- --prod --stats-json
npx webpack-bundle-analyzer dist/my-project/stats.json

You get the following scary picture:

The main bundle of your application has a size of 498 KB of which Moment.js is 329 KB! The biggest part of Moment.js consists of a bunch of locales, which you most probably do not need!

Of course this is a shortcoming of Moment.js in combination with webpack. This is not inherently a problem of the Angular CLI. However Moment.js is a very popular library, many Angular projects want/need to use it. Maybe only because some other library depends on Moment.js (many do!).

There is an easy fix for the problem: how-to-optimize-momentjs-with-webpack.
However you need to modify the webpack config… which is not possible in a plain Angular CLI project! Bummer!

The answer of the Angular CLI is: that this is unfortunate, but they can’t deal with such special cases… bummer again!
Note: create-react-app accepts that Moment.js, as a very common library, deserves special handling and solves the problem out of the box.

At this point your project has a problem…

Of course the JavaScript ecosystem has a solution for everything:

Wayne Maurer on Twitter

@jbandi Monkey patch node_modules with https://t.co/p7p7L5FtDi

… but I don’t like that a “state-of-the-art” framework forces me into hacks like this.

A solution (sort of …)

Rob Wormald on Twitter

@jbandi https://t.co/1ObTgoXZ2L use this if you want to override config for some library without ejecting.

With ngx-build-plus you can change the webpack configuration in an Angular CLI project without ejecting.

(Note: The section below was updated on 2018–12–29 for Angular CLI 7.1.4)

In the example from above you can do the following:

ng add ngx-build-plus

Add a file webpack.extra.js in the root of your project:

const webpack = require('webpack');

module.exports = {
  plugins: [
    new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/),
  ]
}

And run:

npm run build -- --prod --stats-json --extra-webpack-config webpack.extra.js

npx webpack-bundle-analyzer dist/my-project/stats.json

Yay! All the locales have disappeared from the bundle:

You have now solved the problem! … But did you consider the price of the solution?

At best I can congratulate someone for quickly and simply solving a problem on top of the shit that they are given. The only software that I like is one that I can easily understand and solves my problems.
- Ryan Dahl on Software

Yup, ngx-build-plus is yet another “arcane” library you now depend on. Are you prepared to maintain that library yourself?

For Angular CLI v7.1.4 using ngx-build-plus is a working solution.

… but ngx-build-plus is was broken for Angular CLI 6.2:

Jonas Bandi on Twitter

Attempting an Angular CLI upgrade from 6.1 -> 6.2:

… bummer!

Note: There are other projects similar to ngx-build-plus, maybe they make you happy:

https://github.com/meltedspark/angular-cli-builders
https://github.com/Angular-RU/angular-cli-webpack

The source code for the above example is available here: https://github.com/jbandi/ng-moment-problem

Angular CLI and Moment.js: A recipe for disaster … and how to fix it. was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here are the slides:

Modern JavaScript Frameworks: Angular, React & Vue.js was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here are my slides:

Frontend Monoliths: Run if you can! was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Node.js Ecosystem Is Chaos

A critical view on the dependency problems of modern javascript development …

ES modules: A cartoon deep-dive

In-depth explanation of the mechanics of modules in ECMAScript.

Application State Management

This article by Kent C. Dodds discussing state management options for React applications. The discussion is also interesting for Angular development. My take-away: There is no one-size-fits-all solution for state management. The solution you choose should be specific to your project. Sometimes it even makes sense to use different state management techniques in the same app

Redux — Not Dead Yet!

The new Context API of React 16.3 provides an elegant and simple solution for the “prop drilling” problem of state management in a component architecture. The “prop drilling” problem is probably the most prominent reason for using Redux (and arguably a wrong reason, if “prop drilling” is the only problem you need to solve, since there are much simpler solutions).
The maintainer of Redux explains why Redux still is here to stay.

Podcast: Michel Weststrate creator of Mobx and Immer Libraries for JavaScript

An interesting conversation with information about MobX and Redux and the different paradigms behind those two state management libraries.

Video: 10 tips for React Redux At Scale

My personal opinion is that for most projects there are better state-management techniques than Redux/NgRx. But if you go down the Redux path this short video has some valuable tips.

Redux Ducks

If you are following a typical Redux tutorial, you find building a project where you jump a lot between files: actions, action-creators, reducers and selectors are all defined in separate files. Redux Ducks proposes another approach: structure your application by features.

A similar way is described as re-ducks in this post: Scaling your Redux App with ducks. There is also a ducks proposal for ngrx/Angular.

Contract First Design with Angular 4 and Swagger

Code generation of typescript classes/interfaces from a backend definitions is an interesting topic for enterprise applications. This article uses swagger-js-codegen, which is implemented in JavaScript and allows to customize templates. However the projects seems not very active. I have seen other projects using swagger-codegen or typescript-generator (both of them require Java).

Project from Hell

A funny description of a completely dysfunctional project.

Tweets of the week

Martin Fowler on Twitter

I believe that the principles of good programming are more important than what language we code in. I'd rather work with well-written JavaScript than badly-written Smalltalk.

Steve Drew on Twitter

https://t.co/o9GcJnd7Z0

Enrique 🐘 on Twitter

The year is 2040. The Information Superhighway is littered on both sides with discarded blockchains, carcasses of Docker containers, and rolled up kubernetes clusters. If you squint, you can see all those abandoned JS frameworks lying everywhere, like metal dust.

Weekend Reader 2018.15: JavaScript is Chaos was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently I read a post called “Why would you NOT use TypeScript?”. I found that post a bit biased, so I decided to play advocatus diaboli…

Disclaimer: I am working as a consultant and trainer for modern web development in the enterprise. For most of those projects I unconditionally recommend to use TypeScript. But there are also many reasons not to use TypeScript in some projects.

When starting a new project or reviewing an existing project, I evaluate on a case-by-case basis:

• Is a static type checker for JavaScript worth the effort?
• Is TypeScript the right tool for static type checking or should we consider an alternative?

In this second post about the topic, I look into the overhead TypeScript adds to a project.
In the first post I wrote about alternatives to TypeScript.
In the second post I looked into the overhead TypeScript adds to a project.

In this post I will wrap up with some negative implications of TypeScript not being JavaScript.

TypeScript is not JavaScript: LipStick on the Pig

TypeScript might be misleading. It tries to hide the “bad parts” of JavaScript and gives developers from traditional OO-languages a more familiar experience: They can work with constructs they know: namespaces, classes, interfaces, enums, access modifiers and types. But these are often just compile-time constructs. They are transpiled to JavaScript constructs (i.e. IIFEs) or they are just removed (i.e. types). The code that is actually executed at runtime does therefore still expose quirks that come with JavaScript (i.e. dynamic binding of this and no type-checks). Ultimately this is a leaky abstraction and developers must understand the concepts of JavaScript to debug and truly understand their TypeScript code.

So at the end of the day, TypeScript complies down to the same prototypal, functional, object-oriented Frankenstein’s monster that we know as Javascript.
- from Quora

Jonas Bandi on Twitter

I talked to several "Angular experts" lately ... I am amazed at their lack of JS knowhow ... "TS allows us to program like Java" ...

One thing that many beginners do not understand about TypeScript is that it does not guarantee type-correctness at runtime. Your TypeScript code might be fully typed and the compiler ensures you that everything must be correct… but at runtime you still get errors because your variables might be of the wrong types! Type error might still enter your system at the “untyped” boundaries … i.e. when getting json from the network or from local storage or even from the DOM.
By design TypeScript does no type checks at runtime. If you want type checks at runtime you have to implement them. Typically this means some duplication between the types you implement for compile-time checking and the types you build for run-time checking. Libraries like prop-types or io-ts help with defining type-checks at runtime. But there will be some duplication.

Jonas Bandi on Twitter

@tomastrajan Unfortunately TypeScript does not not make "invalid states unrepresentable" ... it just prevents *your* code to put the system in a invalid state... from my teaching experience many developers (especially Angular developers) don't get that ...

TypeScript is not JavaScript: Hiring Implications

Software is eating the world. The web is eating software & JavaScript Rules the web.
- Eric Elliot

JavaScript is extremely popular. By using TypeScript, you are focusing on a language that is less popular, therefore the pool of developers that can or want to work on your projects is smaller.
Depending on your project this might be a limitation or a factor that helps to ensure the right developers get on the project.

By choosing TypeScript, you are limiting the pool of developers that might work on your project.

TypeScript is not JavaScript: Lock-In

TypeScript claims to be a superset of JavaScript. That claim alone is questionable, since typical JavaScript code produces errors in TypeScript.

As a consequence migrating a project to TypeScript might be more work than just renaming the files from .js to .ts.

When you start using TypeScript features (types, generics, enums, access modifiers …), your code does not run directly in a JavaScript runtime any more.
Your project becomes dependent on TypeScript. For a big code base written in TypeScript it would be a lot of work to get back to plain JavaScript.

Right now this might not look like a problem, since TypeScript provides you with all its benefits.

The problem might arise in the long term. The current strength of TypeScript is that it is so closely aligned to JavaScript. This enables easy integration with the huge JavaScript ecosystem. Currently you can use TypeScript with almost every JavaScript library and framework. The TypeScript team clearly stated that this is also the goal for the future. This means new JavaScript features are also compatible with TypeScript.

However in a far future TypeScript might decide to deviate further away from JavaScript. This might impact the ease of integration with the JavaScript ecosystem a lot. Then TypeScript would just become another language that compiles to JavaScript, there are already a lot of those …

Another danger is that certain TypeScript features might clash with future JavaScript features and TypeScript has to change. This happened before with modules (I think TypeScript handled it gracefully, but there is still some friction in TypeScript aroundnamespace and module).

The next clash that is on the horizon is JavaScript introducing private fields.

I worry about building up a large codebase using TypeScript, only to have the ECMAScript spec introduce conflicting keywords and type features
- Eric Elliot, The Shocking Secret About Static Types

TypeScript does not have the same momentum as JavaScript. By using TypeScript you choose a path that bears some more risks than betting on JavaScript.
Also TypeScript does not shield you from having to deeply understand JavaScript. A TypeScript expert must also be a JavaScript expert!

Here is why you might NOT want to use TypeScript — Part 3: TypeScript is not JavaScript was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently I read a post called “Why would you NOT use TypeScript?”. I found that post a bit biased, so I decided to play advocatus diaboli…

Disclaimer: I am working as a consultant and trainer for modern web development in the enterprise. For most of those projects I unconditionally recommend to use TypeScript. But there are also many reasons not to use TypeScript in some projects.

When starting a new project or reviewing an existing project, I evaluate on a case-by-case basis:

• Is a static type checker for JavaScript worth the effort?
• Is TypeScript the right tool for static type checking or should we consider an alternative?

In this second post about the topic, I look into the overhead TypeScript adds to a project.
In the first post I wrote about alternatives to TypeScript.
In a third post I wrap up with some negative implications of TypeScript not being JavaScript.

TypeScript is an Overhead: Introducing a static type system

The main value of TypeScript today is adding a static type system at compile time. Depending on your project as well as the background and mindset of the team, the value of a static type system and thus the value of TypeScript might be questionable.

The value of a static type system is not undisputed. There are many claims that a static type system doe not prevent bugs or increase the quality of a project. The disadvantages of a static type system are about loosing the flexibility and elegance of a dynamically typed language and the additional complexity, noise and effort introduced by the type system.

Modeling generic code with a static type system can quickly become complicated , noisy and difficult to understand. Here is an example from this GitHub thread:

I think that JavaScript’s loose typing is one of its best features and that type checking is way overrated. TypeScript adds sweetness, but at a price. It is not a price I am willing to pay.
- Douglas Crockford

In many smaller-scale use cases, introducing a type system may result in more overhead than productivity gain.
- Vue.js Developers Guide

Static typing is an additional layer of complexity. You are basically writing the code again, on a different level.
- Dr. Axel Rauschmayer, JavaScript vs. TypeScript vs. ReasonML

TypeScript comes with a substantial cost, and it wouldn’t be wise to ignore it.
- Eric Elliot, You might not need TypeScript (or Static Types)

Static types give you a false sense of security. Type correctness does not guarantee program correctness.
- Eric Elliot, The Shocking Secret About Static Types

Here is a list of studies that research the topic of Static vs. Dynamic languages.

TypeScript is an Overhead: Implying a build step

TypeScript is a compiled language, this implies you need a build step for compilation.

There are many projects out there where a build step does not makes sense. Especially regarding the fact, that the state-of-the-art build tooling in the JavaScript ecosystem is re-invented every year.

Perhaps you don’t want to set up an entire build system for some small abstractions you could feasibly do without.
- Replacing jQuery With Vue.js: No Build Step Necessary

If your project does not need a build step, then you can’t use TypeScript.

The “real frontend engineers” among the audience will claim that projects without build step are just no “real projects”.

I see in most enterprises many small web pages providing some functionality or information for different end-users (process monitors, reports, simple process controls of data input …). The strength of the traditional web platform is that it is very easy to build a small html site, which is enhanced with JavaScript. This can provide immense value at a very low cost.

Also I think the pendulum will swing back from the current SPA-hype to server-rendered and “client-side enhanced” pages for many use cases line-of-business applications.

In these scenarios the model of adding some simple <script src="..."> to small pages is very productive. Optimising steps are often not needed for such in-house line-of-business applications.

TypeScript is an Overhead: Complicating existing build toolchains

Starting with the TypeScript compiler is not difficult: tsc --watch

But if you already have a build pipeline (maybe still based on grunt or gulp then you are probably doing some other processing steps that have to play well with the TypeScript compiler. i.e. template preprocessing/inlining, minification, source map generation … understanding and maintaining modern frontend build toolchains is a lot of work and a constantly moving target. Sometimes it is just not worth the effort to introduce yet another tool, sometimes it is really not feasible to do it.

Tools like the angular-cli or create-react-app help tremendously to reduce the effort to create/maintain a modern frontend build, but for some legacy projects these are just not an option.

Also there have been repeated cases where a new versions of TypeScript breaks existing code. Prominent examples that come to my mind are:

• New errors with RxJS on 2.4.1
• @angular/core is not compatible with Typescript 2.4.1

With TypeScript your build toolchain gets more complicated. This might be a cost that you are not willing to pay.

TypeScript adds an overhead on a conceptual level by introducing types and on a technical level by requiring a build step. For some projects this overhead is just not worth it.

Here is why you might NOT want to use TypeScript — Part 2: TypeScript adds Overhead was originally published in reality-loop on Medium, where people are continuing the conversation by highlighting and responding to this story.