The information in our interactive Radar is currently only available in English. To get information in your native language, please download the PDF here.


  • AssertJ is a Java library that provides a fluent interface for assertions, which makes it easy to convey intent within test code. AssertJ gives readable error messages, soft assertions and improved collections and exception support. Many of our teams choose AssertJ as their default assertion library instead of JUnit combined with Java Hamcrest.

  • Enzyme has become the defacto standard for unit testing React UI components. Unlike many other snapshot-based testing utilities, Enzyme enables you to test without doing on-device rendering, which results in faster and more granular testing. This is a contributing factor in our ability to massively reduce the amount of functional testing we find we have to do in React applications. In many of our projects it’s used within a unit testing framework such as Jest.

  • Kotlin has experienced an accelerated rate of adoption and rapid growth of tooling support. Some of the reasons behind its popularity are its concise syntax, null safety, ease of transition from Java and interoperability with other JVM-based languages in general, and that it doubles as a great introductory language to functional programming. With JetBrains adding the ability to compile Kotlin to native binaries on multiple platforms, as well as transpile to JavaScript, we believe it has the potential of much wider use by the larger community of mobile and native application developers. Although at the time of writing, some of the tooling such as static and coverage code analysis have yet to mature, given our experience of using Kotlin in many production applications, we believe Kotlin is ready for general adoption.


  • Since it was first introduced in the Radar, we’ve seen a steady adoption of GraphQL, particularly as a remote interface for a Backend for Frontend (BFF). As they gain more experience, our teams have reached consensus on Apollo, a GraphQL client, as the preferred way to access GraphQL data from a React application. Although the Apollo project also provides a server framework and a GraphQL gateway, the Apollo client simplifies the problem of binding UI components to data served by any GraphQL backend. Notably, Apollo is used by Amazon AWS in their recent launch of the new AWS AppSync service.

  • CSS is the preferred choice for laying out web pages, even when it did not provide much explicit support for creating layouts. Flexbox helped with simpler, one-dimensional layouts, but developers usually reached for libraries and toolkits for more complex layouts. CSS Grid Layout is a two-dimensional grid-based layout system that provides a mechanism to divide available space for layout into columns and rows using a set of predictable sizing behaviors. Grid does not require any libraries and plays well with Flexbox and other CSS display elements. However, since IE11 is only partially supported, it ignores users who still depend on a Microsoft browser on Windows 7.

  • Most large CSS codebases require complex naming schemes to help avoid naming conflicts in the global namespace. CSS Modules address these problems by creating a local scope for all class names in a single CSS file. This file is imported to a JavaScript module, where CSS classes are referenced as strings. Then, in the build pipeline (Webpack, Browserify, etc.), the class names are replaced with generated unique strings. This is a significant change in responsibilities. Previously, a human had to manage the global namespace, to avoid class naming conflicts; now that responsibility rests with the build tooling. A small downside we've encountered with CSS Modules: functional tests are usually out of the local scope and can therefore not reference classes by the name defined in the CSS file. We recommend using IDs or data attributes instead.

  • The Hyperledger project has grown into a broader collaboration and now contains a series of subprojects. It supports Blockchain implementations for different purposes; for example, Burrow is dedicated to build a permissioned Ethereum and Indy is more focused on digital identity. Among these platforms, Fabric is the most mature one. Most of time when people talk about adopting Hyperledger they are actually thinking about Hyperledger Fabric. However, the programming abstraction of chaincode is relatively low level given it manipulates the state of the ledger directly. Moreover, it always takes a lot of time to set up infrastructure before writing the first line of blockchain code. Hyperledger Composer, which builds on top of Fabric, accelerates the process of turning ideas into software. Composer provides DSLs to model business assets, define access control and build a business network. By using Composer you could quickly validate your idea through a browser without setting up any infrastructure. Just remember that the Composer itself isn't Blockchain — you still need to deploy it on Fabric.

  • Security is the cornerstone of the blockchain economy. In the last issue of the Radar, we highlighted the importance of testing and auditing smart contracts dependencies. OpenZeppelin is a framework to help build secure smart contracts in Solidity. The team behind OpenZeppelin summed up a series of pitfalls and best practices around smart contracts' security and embedded these experiences into the source code. The framework is well reviewed and validated by the open source community. We recommend the use of OpenZeppelin instead of writing your own implementation of the ERC20/ERC721 token. OpenZeppelin is also integrated with Truffle.


  • Historically, Google's Android documentation examples lacked architecture and structure. This changes with the release of Android Architecture Components, a set of opinionated libraries that help developers create Android applications with better architecture. They address longstanding pain points of Android development: handling lifecycles; pagination; SQLite databases; and data persistence over configuration changes. The libraries don't need to be used together — you can pick the ones you need most and integrate them into your existing project.

  • A multi-app strategy is really controversial, particularly at a time when fewer and fewer users are downloading new apps. Instead of introducing a new app and struggling with the download numbers, multiteams have to deliver functionality via a single app that is already widely installed, which creates an architectural challenge. Atlas and BeeHive are modularization solutions for Android and iOS apps, respectively. Atlas and BeeHive enable multiteams working on physically isolated modules to reassemble or dynamically load these modules from a facade app. Both are Alibaba open source projects, since Alibaba encountered the same problem of dwindling downloads and single-app architectural challenges.

  • Our first rule of thumb in selecting a rules engine is normally: you don't need a rules engine. We've seen too many people tying themselves to a hard-to-test black-box rules engine for spurious reasons, when custom code would have been a better solution. That said, we've had success using Clara rules for scenarios where a rules engine does make sense. We like that it uses simple Clojure code to express and evaluate the rules, which means they are amenable to refactoring, testing and source control. Rather than chasing the illusion that business people should directly manipulate the rules, it drives collaboration between the business experts and developers.

  • Flutter is a cross-platform framework that enables you to write native mobile apps in Dart. It benefits from Dart and can be compiled into native code and communicates with the target platform without bridge and context switching — something that can cause performance bottlenecks in frameworks such as React Native or Weex. Flutter’s hot-reload feature is impressive and provides superfast visual feedback when editing code. Currently Flutter is still in beta, but we’ll continue keeping an eye on it to see how its ecosystem matures.

  • The ability to compile the Go programming language to bare metal targets has raised interest among developers in using the language for embedded systems. Gobot is a framework for robotics, physical computing, and the Internet of Things, written in the Go programming language and supporting a variety of platforms. We've used the framework for experimental robotic projects where real-time response hasn't been a requirement, and we’ve created open source software drivers with Gobot. Gobot HTTP APIs enable simple hardware integration with mobile devices to create richer applications.

  • Given the number of JavaScript application frameworks we’ve featured in the Radar over the years we asked ourselves, do we really need to call out another one? We decided that Hyperapp is worth a look because of its minimalist approach. It has a very small footprint, less than 1KB, and yet covers all the essential functionality for writing a web application. This is only possible with an elegant design that reduces everything to the absolute minimum, which in turn makes it easier to understand and use the framework. Despite being relatively new, it has attracted a good-size community and we recommend to at least consider it when picking a framework for a new application.

  • PyTorch is a complete rewrite of the Torch machine learning framework from Lua to Python. Although quite new and immature compared to Tensorflow, programmers find PyTorch much easier to work with. Because of its object-orientation and native Python implementation, models can be expressed more clearly and succinctly and debugged during execution. Although many of these frameworks have emerged recently, PyTorch has the backing of Facebook and broad range of partner organisations, including NVIDIA, which should ensure continuing support for CUDA architectures. ThoughtWorks teams find PyTorch useful for experimenting and developing models but still rely on TensorFlow’s performance for production-scale training and classification.

  • Rasa is a new entrant in the area of chatbots. Instead of using a simple decision tree it uses neural networks to map intent and internal state to a response. Rasa integrates with natural language processing solutions such as spaCy; and, unlike other solutions we've featured in the Radar, Rasa is open source software and can be self-hosted, which makes it a viable solution when ownership of data is of concern. Our experiences with using Rasa Stack for an internal application have been positive.

  • Reactor is a library for building non-blocking applications on the JVM — version 8 and above — based on the Reactive Streams specification. Reactive programming emphasizes moving from imperative logic to asynchronous, non-blocking and functional style code, especially when dealing with external resources. Reactor implements the reactive stream specification and provides two publisher APIs — Flux (0 to N elements) and Mono (0 or 1 element) — to effectively model push-based stream processing. Reactor project is well suited for microservices architecture and offers back pressure–ready network engines for HTTP, WebSockets, TCP and UDP traffic.

  • RIBs — which is short for router, interactor and builder — is a cross-platform architecture mobile framework from Uber. The key idea of RIBs is to decouple business logic from the view tree, and thus ensure the app is driven by business logic. This is actually an application of Clean Architecture in mobile application development. By applying consistent architecture patterns across native Android and iOS, RIBs provides clear statement management and good testability. We advise putting business logic in the back-end service rather than leak it into the view, so if you do have a complicated mobile application, RIBs can help manage this complexity.

  • Programming for smart contracts requires a more expressive language than a scripting system for transactions. Solidity is the most popular among the new programming languages designed for smart contracts. Solidity is a contract-oriented, statically typed language whose syntax is similar to JavaScript. It provides abstractions for writing self-enforcing business logic in smart contracts. The toolchain around Solidity is growing fast. Nowadays, Solidity is the primary choice on the Ethereum platform. Given the immutable nature of deployed smart contracts, it should go without saying that rigorous testing and audit of dependencies is vital.

  • We’re in favor of asynchronous and reactive styles of programming especially for network I/O-bound distributed systems. Reactive libraries often sit on top of a lower level nonblocking communication framework such as Netty. Recently SwiftNIO, an open source nonblocking networking framework from Apple, has grabbed our attention. SwiftNIO is similar to Netty but written in Swift. It’s currently supported on MacOS and Ubuntu and implements HTTP as a higher-level protocol. We’re excited to see the usage of this framework and integration of it into higher-level application frameworks and other protocols.

  • In the last issue we featured PyTorch, a deep-learning modeling framework that allows an imperative programming style. Now TensorFlow Eager Execution provides this imperative style in TensorFlow by enabling execution of modeling statements outside of the context of a session. This improvement could provide the ease of debugging and finer-grained model control of PyTorch with the widespread popularity and performance of TensorFlow models. The feature is still quite new so we’re anxious to see how it performs and how it’ll be received by the TensorFlow community.

  • TensorFlow Lite is the designated successor of TensorFlow Mobile, which we mentioned in our previous Radar. Like Mobile it is a lightweight solution tuned and optimized for mobile devices (Android and iOS). We expect the standard use case to be the deployment of pretrained models into mobile apps but TensorFlow Lite also supports on-device learning which opens further areas of application.

  • We’re trying out troposphere as a way of defining the infrastructure as code on AWS for our projects where AWS CloudFormation is used instead of Terraform. troposphere is a Python library that allows us to write Python code to generate CloudFormation JSON descriptions. What we like about troposphere is that it facilitates catching JSON errors early, applying type checking, and unit testing and DRY composition of AWS resources.

  • Truffle is a development framework that brings a modern web development experience to the Ethereum platform. It takes over the job of smart contract compiling, library linking and deployment, as well as dealing with artifacts in different blockchain networks. One of the reasons we love Truffle is that it encourages people to write tests for their smart contracts. You need to take tests really seriously as smart contract programming is often related to money. With its built-in testing framework and integration with TestRPC, Truffle makes it possible to write the contract in a TDD way. We expect to see more technologies similar to Truffle to promote continuous integration in the blockchain area.

  • WebAssembly is a big step forward in the capabilities of the browser as a code execution environment. Supported by all major browsers and backward compatible, it's a binary compilation format designed to run in the browser at near native speeds. It opens up the range of languages you can use to write front-end functionality, with early focus on C, C++ and Rust, and it's also an LLVM compilation target. When run in the sandbox, it can interact with JavaScript and shares the same permissions and security model. When used with Firefox’s new streaming compiler, it also results in faster page initialization. Although it's still early days, this W3C standard is definitely one to start exploring.


    Unable to find something you expected to see? Your item may have been on a previous radar


    ThoughtWorks Technology Radar looks at things in motion that we feel are worth paying attention to. In this instance, the flight path got rather crowded, and a blip — Keras — made an unexpected re-appearance on our Radar. We've subsequently archieved it, as per our original intention.

    New or moved,No change


    ThoughtWorks Technology Radar looks at things in motion that we feel are worth paying attention to. In this instance, the flight path got rather crowded, and a blip — Keras — made an unexpected re-appearance on our Radar. We've subsequently archieved it, as per our original intention.