Forem: Victor Savkin

Lerna/Yarn -> Nx: Faster Build Times + Better Dev Ergonomics

Victor Savkin — Tue, 13 Jul 2021 14:53:17 +0000

In this video I'll compare monorepo tools such as Lerna/Yarn workspaces/PNPM workspaces with Nx. The video walks you through the steps of adding Nx to a Lerna repo and showing many affordances Nx offers. Although the video uses Lerna, everything said applies to Yarn or PNPM. Basically, any time I say "Lerna" you can substitute it for Yarn or PNPM.

Clarifying Misconceptions

Misconception: You have to choose between Nx and Lerna.

Lerna, Yarn workspaces, pnpm workspaces offer the following affordances for developing multiple projects in the same repo:

Deduping node_modules. If I use the same version of say Next.js in all the projects, the package is installed once.
Task orchestration. If I want to test all the projects, I can use a single command to do it.
Publishing (Lerna only). I can run one command to publish packages to NPM.

This is what Nx offers:

Smart rebuilds of affected projects
Distributed task execution & computation caching
Code sharing and ownership management
High-quality editor plugins & GitHub apps
Powerful code generators
Workspace visualizations
Rich plugin ecosystem
Consistent dev experience for any framework
Automatic upgrade to latest versions of all frameworks and tools

As you can see, there is basically no overlap. Nx isn't a package manager (it's not a JS-only tool), so deduping node_modules isn't in that list. Nx doesn't care whether your repo has multiple node_modules folders or not, and whether you choose to dedup them or not. If you want to use Lerna to dedup node_modules in your Nx workspace, you can do it. Many companies do.

What often happens though is when folks adopt Nx, they have better affordances for implementing a single-version policy (why this is a good idea is beyond the scope of this post, but you can read more about why Google does here). But it's important to stress that this isn't required by Nx. It's simply something that Nx can enable you to do at scale.

Misconception: Nx is for apps, Lerna is for libs.

Although it's true to say that the Nx core doesn't care whether you publish your packages or not, there are Nx plugins (e.g., @nrwl/node) that help you bundle and package your modules.

For instance, the Nx repo itself is built with Nx. It has 2 applications and a few dozen libraries. Those libraries are published to NPM. Many larger organizations using Nx publish a subset of their libraries to their registry.

Misconception: Nx is configuration over convention

As you saw in the video, the amount of the generated configuration is small. The add-nx-to-monorepo script generates the following per project:

"header": { "type": "library", "root": "packages/header" }

That is it. If you have 200 projects in your workspace, you will see 200 lines specifying projects' roots. Practically everything else you see is optional. You can choose to configure your executors instead of using npm scripts, or configure generator defaults, and so forth. When you configure the @nrwl/web:dev-server executor, though, you aren't just adding a chunk of json config into workspace.json, you are also removing the configuration files you used to implement the same functionality (start scripts, Webpack config files etc.) So the total amount of configuration is decreasing, and, often, by a lot.

We came from Google, so we take the toolability very seriously. Nx plugins provide metadata to be understood by the Nx CLI and editors. The configuration of your workspace is also statically analyzable (in opposite to say the Webpack config files). In addition to enabling good VSCode and WebStorm support, it allows us to update your configuration automatically as you upgrade your version of Nx. Other than the toolability aspect we try to keep the config as short as possible and rely on conventions.

Summary

Nx has more in common with the build tools used at Google or Facebook (just made a lot more easily accessible for other companies) than with Lerna. When using the word "monorepo" in the context of say Google, we imagine a much richer dev experience, not simply collocating a few projects side by side (read more here). Lerna/Yarn/PNPM are package managers. When it comes to monorepos, they mainly perform node_modules deduping. So the choice isn't between Nx or Lerna. It's between whether you want to have multiple node_modules folders (in this case use Nx with Lerna) or not (use Nx without Lerna).

canonical_url: https://blog.nrwl.io/lerna-yarn-nx-faster-build-times-better-dev-ergonomics-2ec28463d3a5

Smart, Extensible Build Framework Explained in 12 Solarized-Themed Diagrams

Victor Savkin — Thu, 20 May 2021 14:04:42 +0000

Nx is a smart, extensible, toolable, and easy-to-use build framework. In this post, I'll show you how it works using 12 diagrams.

Plugins & Code Generation

Let's create a new Nx workspace.

> npx create-nx-workspace --preset=empty

This creates the following:

apps/
libs/
tools/
workspace.json
nx.json
tsconfig.base.json
package.json

Nx is a VSCode of build tools: it has a powerful core that you can build plugins for.

Let's run nx list to see the list of available plugins:

>  NX  Also available:

  @nrwl/cypress (builders,generators)
  @nrwl/jest (builders,generators)
  @nrwl/linter (builders)
  @nrwl/node (builders,generators)
  @nrwl/workspace (builders,generators)
  @nrwl/express (executors,generators)
  @nrwl/next (executors,generators)
  @nrwl/react (executors,generators)
  @nrwl/storybook (executors,generators)
  @nrwl/web (executors,generators)
  ...


>  NX  Community plugins:

  nx-electron - An Nx plugin for developing Electron applications
  nx-stylelint - Nx plugin to use stylelint in a nx workspace
  @nxtend/ionic-react - An Nx plugin for developing Ionic React applications and libraries
  @nxtend/ionic-angular - An Nx plugin for developing Ionic Angular applications and libraries
  @nxtend/capacitor - An Nx plugin for developing cross-platform applications using Capacitor
  @nxtend/firebase - An Nx plugin for developing applications using Firebase
  ...

Let's add Next.js plugin, which will also add the React, Jest, and Cypress plugins.

> yarn add @nrwl/next

Let's use the Next.js and React generators to create new projects (applications and libraries) in the workspace.

Nx uses a virtual file system to run its generator, so you can compose them, run them in the dry-run mode etc.

> nx g @nrwl/next:app app1
> nx g @nrwl/react:app app2
> nx g @nrwl/react:lib lib

Everything is Metadata-Driven

Everything in Nx comes with metadata to enable toolability. For instance, you can run the generator from within VSCode. Default values, validations, autocompletion will work.

Even though I won't show it in this post. It's important to note that this works for any plugin, and also works for any other command. This metadata is used by Nx itself, by VSCode and WebStorm integrations, by GitHub integration, and by third-party tools implementing richer experiences with Nx.

Project Graph

This is a project graph. It reflects the source code in the repo and all the external dependencies that aren't authored in the repo (e.g., webpack, react).

Nodes in the project graph are defined in workspace.json. You can manually define dependencies between the nodes, but you don't have to do it very often. Instead, Nx will analyze the source code (e.g., package.json, ts files, etc) and figure out dependencies for you. Will see this in action below.

Starting with Nx 12.1, this functionality is pluggable, so Nx can analyze other source files (e.g., Go, Kotlin).

We put a lot of work into making this process very fast, but even then it can take a few seconds for a large repo. That's why Nx stores the cached project graph, so it only reanalyzes the files you have changed.

Why not simply use package.json, like Lerna?

Similar to Lerna, Nx analyzes package.json files, but doing that alone is insufficient for many projects. For instance, Nx allows you to have lightweight nodes with less config, it works across languages and platforms, and supports scenarios where dependencies are implicit (e.g., e2e tests depending on the app).

Let's add this import to both apps:

import '@happyorg/mylib'

This changes the project graph to:

Task Graph

Any time you run anything, Nx will create a task graph from the project graph, and then will execute the tasks in that graph.

For instance > nx test lib will create a task graph with a single node:

Projects/Targets/Tasks/Executors

Projects are the source code in the repo. A target is something that you can do with a project (e.g., build/serve/test). Every project can have many targets.

{
      "root": "apps/app1",
      "sourceRoot": "apps/app1",
      "projectType": "application",
      "targets": {
        "build": {
          "executor": "@nrwl/next:build",
          "outputs": ["{options.outputPath}"],
          "options": {
            "root": "apps/app1",
            "outputPath": "dist/apps/app1"
          }
        },
        "serve": {
          "executor": "@nrwl/next:server",
          "options": {
            "buildTarget": "app1:build",
            "dev": true
          }
        },
        "export": {
          "executor": "@nrwl/next:export",
          "options": {
            "buildTarget": "app1:build:production"
          }
        },
        "test": {
          "executor": "@nrwl/jest:jest",
          "outputs": ["coverage/apps/app1"],
          "options": {
            "jestConfig": "apps/app1/jest.config.js",
            "passWithNoTests": true
          }
        }
      }
    }

To make adding Nx to an existing repo easier, if you don’t define any targets in workspace.json, Nx will treat npm scripts you have defined as targets.

An executor is a function (with some metadata) that tells Nx what to do when you run say nx test lib. The metadata piece is crucial. This is what tells Nx how to validate params and set defaults, what to cache etc.

Task is an invocation of target. If you invoke the same target twice, you will create two tasks.

Creating a Task Graph

Nx uses the project graph (information about how projects relate to each other), but the two graphs aren't directly connected (e.g., they are not isomorphic). In the case above, app1 and app2 depend on lib, but if you run nx run-many --target=test --projects=app1,app2,lib, the created task graph will look like this:

Even though the apps depend on lib, testing app1 doesn't depend on testing lib. This means that the two tasks can run in parallel.

Let's change this.

{
  "dependsOn": [
    {
      "target": "test",
      "projects": "dependencies"
    }
  ]
}

With this, running the same test command will create the following task graph:

This doesn't make much sense for tests, but it often makes sense for builds, where to build app1, you want to build lib first. You can also define similar relationships between targets of the same project (e.g., test depends on build).

It's important to stress that a task graph can contain different targets (e.g., builds and test), and those can run in parallel. For instance, as Nx is building app2, it can be testing app1 at the same time.

Affected

When you run nx test app1, you are telling Nx to run the app1:test task plus all the tasks it depends on.

When you run nx run-many --target=test --projects=app1,lib, you are telling Nx to do the same for two tasks app1:test and lib:test.

When you run nx run-many --target=test --all, you are telling Nx to do this for all the projects.

As your workspace grows, retesting all projects becomes too slow. To address this Nx implements code change analysis (i.e., it analyzes your PRs) to get the min set of projects that need to be retested. How does it work?

When you run nx affected --target=test, Nx will look at the files you changed in your PR, it will look at the nature of change (what exactly did you update in those files), and it will use this to figure the list of projects in the workspace that can be affected by this change. It will then run the run-many command with that list.

For instance, if my PR changes lib, and I then run nx affected --target=test, Nx will figure out that app1 and app2 depend on lib, so it will invoke nx run-many --target=test --projects=app1,app2,lib.

Nx is able to analyze the nature of the change. E.g., if you change the version of Next.js in package.json, Nx will know that app2 cannot be affected by it, so it will only retest app1.

Running Tasks

Nx will run the tasks in the task graph in the right order. Before running the task, Nx will compute its computation hash. As long as the computation hash is the same, the output of running the task will be the same.

How does Nx do it?

By default, the computation hash for say nx test app1 will include:

all the source files of app1 and lib
relevant global configuration
versions of externals dependencies
runtime values provisioned by the user (e.g., version of Node)
command flags

This behavior is customizable. For instance, lint checks may only depend on the source code of the project and global configs. Builds can depend on the dts files of the compiled libs instead of their source.

Once Nx computes the hash for a task, it then checks if it ran this exact computation before. First it checks locally, and then if it is missing, and if a remote cache is configured, it checks remotely.

If Nx finds the computation, Nx will retrieve it and replay it. Nx will place the right files in the right folders and will print the terminal output. So from the user's point of view the command ran the same, just a lot faster.

If Nx doesn't find this computation, Nx will run the task, and after it completes, it will take the outputs and the terminal output and will store it locally (and if configured remotely). All of this happens transparently, so you don't have to worry about it.

Although conceptually this is fairly straightforward, we do a lot of clever things to make this experience good for the user. For instance:

We use an interesting technique of capturing stdout and stderr to make sure the replayed output looks exactly the same, including on Windows.
We minimize the IO by remembering what files are replayed where.
We only show relevant output when processing a large task graph.
We provide affordances for troubleshooting cache misses.
And many other things like that.

All of these are crucial for making Nx usable for any non-trivial workspace. For instance, if you run nx build app1 --parallel, and it depends on say 1000 libs, Nx will create a task graph like this:

It will then process the task graph from the leaves, running everything it can in parallel. If ParentLib depends on ChildLib1 and ChildLib2, it will build the child libs first. Before running every task it will check if it already has the needed files in the dist folder? Found them? Then don't do anything. No? Check local cache and, if needed, remote cache. Cache hit? Restore the files. Cache miss, run the command, capture stdout and cache it together the file outputs for future use. The min amount of work that has to happen will happen. The rest will be either left as is or restored from cache.

Distributed Task Execution

Nx Cloud is a cloud companion for the Nx build framework. Many features of Nx Cloud are free, but some are paid. One of them is the distributed computation cache, which allows you to share cache with your team members and CI agents. If you pull the main branch in the morning, everything will be cache because the CI just did it.

But an even more exciting feature Nx Cloud provides is config-free distributed task execution (DTE). When using the distributed task execution, Nx is able to run any task graph on a many agents instead of locally.

When using this, nx affected --build, won't run the build locally (which for large workspace can take hours). Instead, it will send the Task Graph to Nx Cloud. Nx Cloud Agents will then pick up the task they can run and execute them.

Note this happens transparently. If an agent builds app1, it will fetch the outputs for lib if it doesn't have it already.

As agents complete tasks, the main job where you invoked nx affected --build will start receiving created files and terminal outputs.

After nx affected --build completes, the machine will have the build files and all the terminal outputs as if it ran it locally.

Summary

Nx is a smart, extensible, toolable and easy to use build framework.
You can install plugins that will bring executors, generators, and dep graph processors.
Nx uses a virtual file system to enable powerful code generation and code augmentation workflows with previews and VSCode and WebStorm support.
You can very easily create apps, components, libs etc.
Everything in Nx is metadata-driven and toolable.
Nx is able to analyze your source code to create a Project Graph.
Nx can use the project graph and information about projects' targets to create a Task Graph.
Nx is able to perform code-change analysis to create the smallest task graph for your PR.
Nx supports computation caching to never execute the same computation twice. This computation cache is pluggable and is distributed.
Nx supports distributed task execution where a single command can run on multiple agents with zero-config.

Learn More

Check out nx.dev to learn more about the Nx Build Framework.

Nx is Modern Angular

Victor Savkin — Tue, 30 Mar 2021 13:43:23 +0000

In order for the Angular community to thrive, it has to remain up-to-date with the broader JavaScript community. The Angular community has to consider what else is going on, and adopt the best tools and ideas.

Regardless of how good the Angular core is, if developers have to use Karma, Protractor, and TSLint (no one’s first choices at this point), Angular will feel outdated.

As I mentioned in my blog post “Angular is an Onion” the team at Google is well-positioned to design core APIs and capabilities and is at a disadvantage compared to the Angular community when it comes to higher-level API and integrating tools into the CLI.

Angular CLI Dropping Support For Legacy Tools

The Angular team has made the decision to drop Angular CLI support for legacy tools and will no longer be shipping the Angular CLI with TSLint, which has been deprecated in 2019.

I strongly support the Angular team no longer shipping TSLint with Angular CLI. At this point, it’s better to have no linter built-in than to have TSLint. Having a deprecated tool as part of the CLI made Angular look outdated and not well maintained. It also made it harder for the community to provide a good alternative: removing the built-in linter and installing a better one is extra work most folks don’t want to do. It’s a right decision.

I think the Angular team should go further and remove or replace Protractor and Karma as well.

Modernizing Angular Development with Nx

At Nrwl, we help companies build very large Angular applications, and seeing them struggle with Protractor or seeing them trying and failing to generate a file using the Schematics API is disheartening.

As a former Angular core team member and NgRx core team member, I still feel a strong affinity with the Angular community. I want to see the folks enjoying the framework and the tools around it. I want to see the community excited.

Nx was created to provide a better developer experience for the Angular community and developers in other communities who are trying to navigate increasingly large and complex development environments. As the Angular landscape has evolved, we have worked hard to ensure that Nx stays one step ahead.

Modern Tools

Developers should use modern tools that help them work more effectively and efficiently. Among our clients and the broader Angular ecosystem, we’ve observed that there are some pretty clear front-runners when it comes to testing and linting tools. We’ve therefore built out-of-the-box support for those tools into Nx. They include:

Jest (replaces Karma) Jest is a zero-config JavaScript testing framework that prioritizes simplicity. With robust documentation and a feature-rich API, Jest is a great solution for JS developers looking for a powerful, modern testing toolkit.
Cypress (replaces Protractor) Cypress supplies fast, reliable E2E testing for anything that runs in the browser. Cypress includes time travel debugging, readable errors and stack traces, real-time reloads, and more.
ESLint (replaces TSLint) ESLint uses static analysis to identify problems in your code, many of which are fixed automatically in a syntax-aware manner. ESLint is highly configurable; customize your linting to preprocess code, use custom parsers, or write your own rules.
Storybook Storybook is an open source tool for building UI components in isolation, making it an excellent platform for design systems that can be shared across an entire brand, including apps built with a variety of frameworks and libraries.

These tools were not selected simply because they’re new and popular; Jest/Cypress/ESLint are more stable and robust than Karma/Protractor/TSLint, and their popularity puts them in a good position for long-term growth and development.

The Nx team has worked hard to ensure that the integration between Nx and these tools is seamless. For example, Nx can generate Cypress tests for your Storybook stories, etc.

Modern CLI

In addition to using modern tools, developers want to work with a CLI that reflects how their needs and expectations have evolved.

Angular CLI is an impressive piece of technology. It has robust code-generation and execution capabilities that facilitate onboarding and developer mobility, but it has a few issues:

In 2021, we aren’t comparing the Angular CLI with an ad-hoc folder with 5 npm scripts in it. Other frameworks offer code generation, editor integration, etc. The delta between the Angular CLI and other CLIs isn’t as big as it used to be.
The Angular CLI got many things right in principle (e.g. atomic code generation aka dry-run, ng update) but, in practice, the API were not very ergonomic and didn’t account for many real-world scenarios.
Several tools now are trying to offer computation caching and other ways of scaling.

When using Nx, you can either let Nx decorate theAngular CLI to improve the developer experience or use the Nx CLI instead. All the points below will apply in the same way.

Let’s look at a few examples.

Computation Caching & Scaling

Computation caching is a great way to improve performance. With it, you never have to build or test the same code more than once.

The Angular team attempted to integrate Bazel into the Angular CLI, but that effort has been canceled. Nx builds on inspiration from Bazel and similar tools, and implements computation caching in a way that works with any tool and requires no configuration. The result is much faster builds and continuous integration.

These are the types of savings we are talking about:

This enables a lot of new ways of developing. For instance, if your “ng serve” takes a long time, you can make it faster by using incremental builds.

Editor Support & GitHub Support

Nx provides a modern, integrated dev experience. VS Code and WebStorm plugins help you use the build tool effectively, generate components in folders, and much more.

Nx also supports optional free cloud support with Nx Cloud, as well as GitHub integration.

Simpler APIs with Nx and Nx Devkit

Regardless of how you use Nx (with Angular CLI or standalone), you can always use the Angular Devkit. You can generate code using schematics and invoke builders. But there is a alternative: you can use Nx Devkit.

Nx Devkit uses only language features (e.g., it doesn’t use observables unless you choose to use them yourself) and it doesn’t use any advanced patterns like partial application.

You can step through your code with a debugger. When an exception is thrown, the stack trace is short and every line points to your code.

The Nx Devkit API is small and is optimized for most common scenarios. See the comparison of the Nx and Agular devkits here. Also, Nx Devkit is well documented.

**Important: **Nx allows you to mix and match Nx Devkit and Angular Devkit seamlessly. Every Nx Generator can be used in an Angular Schematic and vice versa. The user invokes schematics and builders in the same way regardless of which devkit they are written in.

Staying Up to Date & Ng Update

Ng Update is the best thing about the Angular CLI. It is a robust solution for one of the hardest problems in software engineering. But it has a few problems when upgrading larger workspaces:

It often takes many days or even weeks to perform an upgrade, so doing upgrade in small pieces is necessary.
Some but not all migrations have to be rerun after each rebase.
Migrations have to be reordered.
Migrations have to be patched in node_modules (or copied over and replaced).
Different versions of packages have to be used cause of org firewalls etc..

Nx comes with its command that takes the best parts of ng update does but addresses all of the issues above. See here on how it does it.

There is a second aspect of staying up to date: giving people a way to move forward to the new tech.

Some of it is more natural in an Nx repo because of how Nx works. In contrast to a standard Angular CLI setup, folks using Nx split their applications into many packages, each of which can have its own testing tool, linter etc. So you could use say both Cypress and Protractor and slowly move to Cypress one package at a time.

But we at Nrwl also try to do our best to automate this process when possible. For instance, Nx 11.6 has a generator that allows you to move from TSLint to ESLint. So if you have a large Nx workspace, you can move to ESLint in one go.

“Modern Angular” also means working together with other frameworks.

Most large companies use multiple frameworks to build their applications. One org can use Angular, another one can use React, and this is OK.

Nx provides the same dev experience for many frameworks including Angular and React. You can build Angular apps, Next.js apps, share code between them. You can build portals out of Angular and React microfrontends. You can share org-specific code generators, lint checks, CI/CD setup.

Where your code lives and how it is divided should be based on your organizational structure, not on what frameworks you use.

Learn More

Check out Modern Angular on nx.dev and give it a try!

On Bazel Support

Victor Savkin — Mon, 02 Nov 2020 13:53:53 +0000

A year and a half ago we announced our second attempt to add a Bazel backend to Nx. Unfortunately this is not going to happen in the near future. I'd like to provide some context about why we wanted to do it and why we decided that this isn't the time.

We started the Bazel effort for the following two reasons.

Computation Caching

We really wanted to add computation caching to Nx and Bazel had good support for it. So one way to add computation caching to Nx was to run Nx on top of Bazel.

We then realized, however, that to really integrate caching in the dev workflow it will have to be a first-class concept in the build tool itself. That's why we've added distributed computation to Nx. At this point adding Bazel would not give us much on top of what we already have.

Bazel and Angular

Nx is widely used in the Angular community. The Angular team at Google had plans to add Bazel support to the Angular CLI for many years, but the plans didn't materialize. The key folks (e.g., Alex Eagle) working on the effort left Google. Google employees no longer maintain rules_nodejs.

This, of course, doesn't mean that rules_nodejs isn't maintained well. It simply means that the vast majority of Angular developers won't use Bazel, so there is less motivation for us to support them.

Bazel or Nx

When using Nx you can swap its default task runner with one using Bazel. You could make it work, but most people should not do it.

The core of Nx is technology-agnostic. You can use it to build anything, and folks do (there are third-party plugins for Go, Java, Python, etc.). A lot of the value Nx provides is in its plugins. These plugins use existing tools, many of which either don't work with Bazel at all or require significant workarounds.

This is the issue we faced. We built a Bazel-based runner for Nx. Some plugins (e.g., tslint) worked with it, but the majority didn't.

In many ways, Bazel is akin to something like Dart. It's a great piece of technology, but it doesn't play nicely with existing systems. Existing JS libraries didn't work well with Dart. Similarly, existing tools don't work well with Bazel.

Nx is more like TypeScript. Sometimes it results in suboptimal choices (Dart has int and floats, and TypeScript has only numbers), but most of the time it doesn't matter. It is straightforward to add to an existing project. Learning resources are plentiful. It integrates well with the rest of the stack.

Discovered a new tool, say [Snowpack](https://snowpack.dev_? Adding it to an Nx workspace is trivial. Any tool you want either "just works," or can be made to work with minimal effort. We value this and I believe a lot of folks do as well. Building a custom stack for your organization is not just a technical challenge. It's also a recruiting one.

You can also see some benefits after introducing Nx almost right away, which means it is a lot less risky for the business.

Of course, I think Nx is a better choice for most companies, otherwise I would not be working on it, but I know that for some Bazel might be the right tool. I recommend you to try out both. Go to nx.dev and try it out. Try out Bazel as well. And then make your own mind.

Fear of Being Ordinary

Victor Savkin — Wed, 28 Oct 2020 18:26:46 +0000

Reading "Zen and the Art of Motorcycle Maintenance" made me want to understand the tools I use, to tinker with them, to truly make them my own.

I already had an ErgoDox, a highly-customized editor, high income, and a lot of free time — a good foundation for a multi-year obsession with customization.

This post is the reflection of why I — and I believe many other programmers — get into this, how unproductive it can be, and how to snap out of it.

Reasons

Why do we get obsessed about the exactly right keyboard setup, color schemes, fonts, task management systems?

Better for Productivity

We programmers like to feel productive. It shouldn't be surprising that I told myself that having 7 layers on my keyboard is simply necessary for productivity. I'll get more PRs merged!

This is how you imagine yourself when you type on a split keyboard:

Of course not right away. It takes weeks to develop muscle memory (this is assuming you don't change the setup, and of course you do change it). No, these gains are realized in the long run. This is an investment!

I applied this across the board. A todo app? Tried all of them, and even built my own. Productivity systems? Tried every variation of every system.

But any time I actually tried to measure it, the result was always the same. I'm faster on my ThinkPad using the default settings, and I'm just as organized when I use a plain notebook.

Better for Health

No one in the right mind would spend $500 bucks on a keyboard. But what about a keyboard that is good for your health? Sign me in.

I tried a dozen ergonomic keyboards over the years. Most of them have pictures like this:

Why? I have carpal tunnel syndrome. At some point it was so bad I had to switch to using my left hand when brushing my teeth. I just could not hold a toothbrush in my right hand. Tried every keyboard and mouse under the sun. Nothing helped.

One day I started using a boring low-profile keyboard and paid a lot more attention to the position of my wrists. It didn't fix the problem completely, but it helped a lot.

That's actually what I was told when I had an assessment done at Google. But being a techy, it’s hard to believe that the solution is that simple.

What is Customization Actually Good For?

If we don't actually do it for productivity or health reasons, why do we do it?

Fear of Being Ordinary

Desire to be unique — not like others — is a deep psychological need for many, myself included. I grew up in a small Russian village. Half of the students in my school could barely read. So when I started moving from city to city and from country to country, I always carried with me the feeling of being "not quite as"; not being interesting enough.

But being ordinary is not bad. "Cogito, ergo sum" makes each of us irreplaceable and not comparable to each other, by construction. Nothing else is needed, folks. This is, of course, a challenging sell to many, especially in North America where the culture is obsessed with superheroes and outcasts.

Desire for Control

Country is on fire? Marriage is falling apart? We can’t fix that, but we can spend hours choosing the best font and color scheme for our editors.

Desire to Escape

Need to make a difficult decision? Make a risky bet in business? I could do that, but I could also switch my todo list cause my tasks are getting out of hand and it stresses me out.

What I Mean and What I Don’t Mean

Are you saying I don’t need to be productive?

I believe being overly obsessed with productivity is unhealthy. But putting that aside, in general you do want to be good at what you do. So, yes, learn the tools you use, but most of the gains are in understanding the tools themselves. Learn Bash instead of crafting a perfect .bashrc. Learn how to touch type fast, instead of rearranging keys on the keyboard.

And don’t forget: we are knowledge workers. So things that affect our productivity the most are high-quality sleep, good air, good diet, etc. Invest into that.

What is wrong with self-expression?

In general, there is nothing wrong with it. If you want to assemble and program your keyboard because that’s who you are, go ahead. That’s a great hobby. If it gives you joy, that’s fantastic. But it’s important to know that is what it is: a hobby, a means of self-expression. Choosing to use a 60% keyboard is like choosing to wear skinny jeans. It won’t give you the productivity boost you are looking for.

The problem is when it becomes an unhealthy coping mechanism. There are better ways to deal with the anxiety created by the lack of control (e.g., meditation, CBT/Stoicism, therapy).

Summary

Many great engineers enjoy customizing their dev setup, often obsessively. The given reasons are productivity and health. I think it doesn’t really help with either. Instead, the excessive customization is a way (often not the best one) to fulfil basic psychological needs.

Modern Angular

Victor Savkin — Wed, 28 Oct 2020 16:27:54 +0000

Angular Is Many Things

In my blog post "Angular is an Onion" I showed that Angular is many things.

In the middle there are the core capabilities and APIs of the framework. The team at Google is well positioned to build them: the team has the right expertise and feedback mechanisms. As we move away from the core, however, and go into state management, testing support, linting support, editor support, and GitHub integration, the Angular community becomes a more appropriate owner. We, the community, have the right expertise and feedback mechanisms.

I ended the post saying that if something in the Angular stack feels outdated, the community should modernize it. And today I want to show what a more modern Angular looks like.

Seeing is Believing

When it comes to dev tools, seeing is believing. No matter how conceptually beautiful your stuff is, if it is clunky in practice, no one will use it. Please watch this video, and you will see that you can use modern tools and techniques with Angular without losing its integrated development experience.

Nx is an advanced, pluggable build tool with first-class Angular support. Although Nx has its own CLI, it also works with the Angular CLI. You still have the ng command, the angular.json file, and the rest of it. But you also get modern testing and linting tools, modern state management libraries, enhanced Angular CLI, VSCode support, GitHub support, and more.

Modern Testing and Linting Tools

Jest (replaces Karma) Jest is a zero-config JavaScript testing framework that prioritizes simplicity. With robust documentation and a feature-rich API, Jest is a great solution for JS developers looking for a powerful, modern testing toolkit.
Cypress (replaces Protractor) Cypress supplies fast, reliable E2E testing for anything that runs in the browser. Cypress includes time travel debugging, readable errors and stack traces, real-time reloads, and more.
ESLint (replaces TSLint) ESLint uses static analysis to identify problems in your code, many of which are fixed automatically in a syntax-aware manner. ESLint is highly configurable; customize your linting to preprocess code, use custom parsers, or write your own rules.

Modern Component Design Tools

Design systems are collections of repeatable components and standards. For many companies, they are a keystone for high quality, consistent, and standardized development and branding.

And let’s face it: writing Karma tests for presentational components does not work well. For instance, we often use animations in design to engage and delight users — and animations are important to test. When testing details like animations, we want to make sure the necessary UI components are visible before clicking. Cypress does that. Karma does not. Neither Karma nor Jest are suitable for this job.

With Nx, you get Cypress for end-to-end testing of browser-based interactions, as well as built-in, seamless Storybook integration. Storybook is an open source tool for building UI components in isolation, making it an excellent platform for design systems that can be shared across an entire brand, including apps built with different frameworks and libraries.

Modern State Management Frameworks

Nx gives developers built-in support for NgRx to take advantage of reactive state management. Inspired by Redux, NgRx unifies events in your application and derives state using RxJS.

Modern CLI

The Angular CLI is one of the main reasons developers use Angular today. However, modern tooling for web development continues to advance rapidly. That’s why Nx seamlessly wraps the Angular CLI to add computation caching and build coordination.

Nx Uses Computation Caching

Computation caching is a valuable way to improve performance. Computing (tests, arguments, operations, etc.) is expensive and time-consuming, but computation caching means you never have to build the same code more than once.

WebPack, Jest, and TypeScript all perform computation caching. The Angular team attempted to integrate Bazel into the Angular CLI, but that effort has been canceled. Nx builds on inspiration from Bazel and similar tools, and implements computation caching in a way that works with any tool and requires no configuration. The result is much faster builds and continuous integration.

In addition, when connected to Nx Cloud, you can share the computation cache with everyone working on the same project.

Nx Integrated Development Experience

Nx provides a modern dev experience that is more integrated. Nx adds a high-quality VS Code plugin which helps you use the build tool effectively, generate components in folders, and much more.

Nx also supports optional free cloud support with Nx Cloud, as well as GitHub integration. Share links with your teammates where everyone working on a project can examine detailed build logs and get insights about how to improve your apps and your builds.

Clearing Potential Misunderstandings

To prevent erroneous analogies, this is nothing like Preact. The Angular framework and the Angular CLI are still here. All your builders / schematics / libraries will work the same way. This is an upgrade, not a replacement. The goal is to give Angular developers access to the tools other JavaScript developers use without losing the toolability and stability that Angular provides. It’s akin to what Spring did to Java. It showed that Java can be fast, lightweight, and fun.
It’s not a new project. Nx has been around for many years, and it’s used to build small and large applications.

Learn More

Check out Modern Angular on nx.dev and give it a try!