Languages & Frameworks

Our teams developing in TypeScript are finding io-ts invaluable, especially when interacting with APIs that ultimately result in the creation of objects with specific types. When working with TypeScript, getting data into the bounds of the type system (i.e., from the aforementioned APIs) can lead to run-time errors that can be hard to find and debug. io-ts bridges the gap between compile-time type checking and run-time consumption of external data by providing encode and decode functions. Given the experiences of our teams and the elegance of its approach, we think io-ts is worth adopting.

Kotest (previously KotlinTest) is a stand-alone testing tool for the Kotlin ecosystem that is widely used among our teams across various Kotlin implementations — native, JVM or JavaScript. Its key advantages are that it offers a variety of testing styles in order to structure test suites and that it comes with a comprehensive set of matchers, which allow for expressive tests in an elegant internal DSL. In addition to its support for property-based testing, our teams like the solid IntelliJ plugin and the support community. Many of our developers consider it their first choice and recommend those who are still using JUnit in Kotlin consider switching over to Kotest.

In the past, we've cautioned about Node overload, and we're still cautious about the reasons to choose it. However, in scenarios where Node.js is required to build back-end applications, our teams are reporting that NestJS is a suitable option to enable developers to create testable, scalable, loosely coupled and easily maintainable applications in enterprises. NestJS is a TypeScript-first framework that makes the development of Node.js applications safer and less error-prone. NestJS is opinionated and comes with SOLID principles and an Angular-inspired architecture out of the box.

React Query is often described as the missing data-fetching library for React. Fetching, caching, synchronizing and updating server state is a common requirement in many React applications, and although the requirements are well understood, getting the implementation right is notoriously difficult. React Query provides a straightforward solution using hooks. It works hand-in-hand with existing async data-fetching libraries like axios, Fetch and GraphQL since they are built on promises. As an application developer, you simply pass a function that resolves your data and leave everything else to the framework. We like that it works out of the box but still offers a lot of configuration when needed. The developer tools, unfortunately not yet available for React Native, also help developers new to the framework understand how it works. For React Native, you can use a third-party developer tools plugin utilizing Flipper. In our experience, version 3 of React Query brought the stability needed to be used in production with our clients.

When introduced in 2014, Swift didn't come with a package manager. Later, Swift Package Manager was created as an official Apple open-source project, and this solution has continued to develop and mature. Our teams rely increasingly on SwiftPM because most packages can be included through it and the processes for both creators and consumers of packages have been streamlined. In the previous Radar, we recommended trialing, but we now believe it makes sense to select it as the default when starting new projects. For existing projects using tools like CocoaPods or Carthage, it might be worth a quick experiment to gauge the level of effort to migrate and to check whether all dependencies are available.

Conflict-free replicated data type (CRDT) algorithms are proven to be able to automatically distribute and merge changes among peers without conflicts. But in practice, even for small enough data, these algorithms usually require a significant amount of memory to trace all the changes made by different peers, thus making them impractical. Yjs is a carefully optimized CRDT implementation that keeps memory consumption at a reasonable level for large data sets and millions of modifications. It also provides bindings for popular text editors, which greatly reduce the cost of building collaborative tools.

For those who prefer a more natural language than JSON for infrastructure code, Azure Bicep is a domain-specific language (DSL) that uses a declarative syntax and supports reusable parameterized templates for modular resource definitions. A Visual Studio Code extension provides instant type safety, intellisense and syntax checking, while the compiler allows bidirectional transpilation to and from Azure Resource Manager (ARM) templates. Bicep's resource-oriented DSL and native integration with the Azure ecosystem make it a compelling choice for Azure infrastructure development.

Since we last mentioned Camunda, we've seen many of our teams and clients use the platform, making it one of our preferred workflow engines in cases where a workflow engine is a good fit for the domain. Camunda offers workflow and decision engines that can be integrated as a library in your Java code. This makes it easy to test, version and refactor workflows, alleviating some of the downsides of other more low-code workflow engines. We've even seen Camunda used in environments with high performance requirements. Teams also like how easy it is to integrate with Spring Boot and its nice user interface.

Previously, we blipped about the Android Gradle plugin Kotlin DSL, or Gradle Kotlin DSL, which added support for Kotlin Script as an alternative to Groovy for Android projects using Gradle build scripts. The goal of replacing Groovy with Kotlin is to provide better support for refactoring and simpler editing in IDEs and, ultimately, to produce code that is easier to read and maintain. For teams already using Kotlin, it also means working on the build in a familiar language. We now suggest trialing Kotlin DSL as an alternative language to Groovy for Gradle projects in general, especially if you have large or complex Gradle build scripts. Many IDEs now include support for the migration of existing projects. Some caveats remain, and we suggest checking the documentation for the most up-to-date details, including the prerequisites. We had a team with an at least seven-year-old, 450-line build script migrate successfully within a few days.

Android had several media APIs: Jetpack Media, also known as MediaCompat, Jetpack Media2 and ExoPlayer. Unfortunately, these libraries were developed independently, with different goals but overlapping functionality. Android developers not only had to choose which library to use, they also had to contend with writing adaptors or other connecting code when features from multiple APIs were needed. Jetpack Media3 is an API that takes common areas of functionality from the existing APIs — including UI, playback and media session handling — and combines them into a merged and refined API. The player interface from ExoPlayer has also been updated, enhanced and streamlined to act as the common player interface for Media3. After an early access phase, Media3 is now in beta. Although its first release is forthcoming, we've already had positive experiences using it in apps.

As Storybook grew in popularity, it became more and more of a behemoth. If all you really care about is isolating and testing your React UI components, then Ladle is the alternative. Ladle supports most of the Storybook API (MDX files are not supported yet) and can be used as a drop-in replacement. It is lightweight and has better integration with Vite. It also provides simple and clean APIs that can be easily integrated with other testing frameworks.

We're hearing that our Kotlin-based teams are seeking alternatives to Java frameworks such as GSON when handling JSON. Although it's been around for some time, Moshi has now emerged as a preferred framework for many of these teams. It's easy to migrate from GSON and Moshi provides native support for Kotlin non-nullable types and default parameters. Moshi makes working with JSON faster and easier. If you're currently using a Java framework from within Kotlin to handle JSON, we recommend giving Moshi a try.

Among web component frameworks, Svelte stands out by moving reactivity out of the browser and into the compiler. Instead of optimizing DOM updates by using a virtual DOM and browser optimization tricks, Svelte compiles your code into vanilla framework-less JavaScript code that surgically updates the DOM directly. In addition to the run-time performance benefits, this also allows Svelte to optimize the amount of code the browser has to download without sacrificing features for developers; moreover, it's proven to be performant and battery-friendly for mobile web applications as less code has to execute in the browser itself. Performance benefits aside, our teams have appreciated its friendly learning curve and the maintenance benefits that come from writing less code. Svelte itself is only the component framework, but SvelteKit adds features to build full web applications.

There is certainly no shortage of frameworks to build web applications in JavaScript/TypeScript. We've featured many of them in the Radar, but what sets Aleph.js apart in this crowded field is that it's built to run on Deno, the new server-side run time created by the original developer of Node. This puts Aleph.js on a modern foundation that addresses several shortcomings and problems with Node. Aleph.js is still new — it’s approaching the 1.0 release at the time of writing — but it already offers a solid developer experience, including hot module replacement. With Deno now way past its 1.0 release, this is a modern choice for projects that can take the risk.

It's hard to believe, but in 2022, the developer community continues to pump out interesting new frameworks for building web applications. Astro is a recent, open-source, multi-page application framework that renders HTML on the server and minimizes the amount of JavaScript sent over the wire. Astro seems particularly well-suited to content-oriented websites that pull from many different sources. We like the fact that although Astro encourages sending only HTML, it still supports — when appropriate — select active components written in the front-end JavaScript framework of your choice. It does this through its island architecture. Islands are regions of interactivity within a single page where the necessary JavaScript is downloaded only when needed. Astro is relatively new but seems to support a growing ecosystem of developers and code. It's one to watch as it develops.

BentoML is a python-first framework for serving machine-learning models in production at scale. The models it provides are agnostic of their environment; all model artifacts, source code and dependencies are encapsulated in a self-contained format called Bento. It's like having your model "as a service." Think of BentoML as the Docker for ML models: It generates VM images with pre-programmed APIs ready for deployment and includes features that make it easy to test these images. BentoML can help speed up the initial development effort by easing the start of projects which is why we included it in Assess.

When looking at reducing the carbon footprint of an application — the carbon dioxide emissions caused indirectly by running the software — attention is usually directed at making the software more efficient. The thinking is clear: more efficient software needs less electricity and fewer servers, reducing the emissions from electricity generation and manufacturing of the servers. An additional strategy is to make the application carbon aware. This is because the same workload does not always have the same carbon footprint. For example, when run in a data center in a cooler climate, less power for air conditioning is needed; or, when run at a time when more renewable energy is available (more sunshine, stronger winds), less electricity from carbon-based sources is required. With the Carbon Aware SDK, software engineers can query data sources to discover less carbon-intensive options for a given workload and then move it to a different location or run it at a different time. This makes sense for large workloads that are neither time nor latency sensitive, such as training a machine-learning model. Although the SDK and available data sources are not very comprehensive yet, we believe it's time to start looking at how we can make our systems carbon aware.

Cloudscape is an open-source design system that not only has a rich set of components but also 35 interaction and content representation patterns. In addition, it uses design tokens for theming and provides element wrappers for all components, which greatly simplifies unit testing. This makes it stand out from other design systems out there.

Connect is a family of libraries for building browser- and gRPC-compatible HTTP APIs. Similar to gRPC, you write Protocol Buffer schema and implement the application logic, and Connect generates code to handle marshaling, routing, compression and content type negotiation. However, Connect tries to improve on gRPC in several ways. This includes native support for gRPC-Web without a translating proxy; interoperability with third-party routers or middleware, because connect-go is built on top of net/http (unlike grpc-go); and fully generated type-safe clients with the ergonomics of hand-crafted code. We mostly prefer REST and are not a big fan of the RPC approach to building APIs. That said, Connect does seem to address some of our concerns with RPCs, and we encourage you to assess it.

As smart devices continue to embed themselves in our lives, we are starting to see new use cases emerge that span across multiple devices. The classic example is a text we start reading on a phone but prefer to finish on a tablet. Other examples include plotting a cycling route on a laptop and then transferring the data to a bike computer for easier navigation or using a mobile phone as a webcam. Such use cases require very specific kinds of features, like the discovery of nearby devices, secure communication and multi-device sessions. Apple started introducing such features a while ago to its own SDKs, and now Google has released the first preview of its Cross device SDK. Although the preview has several limitations — for example, only phones and tablets are supported and only two devices at a time — the technology is exciting and can be utilized as it is rolled out over time.

Cypress Component Testing provides a testable component workbench to quickly build and test UI components. You can write component visual regression tests with the same API that you write end-to-end (E2E) UI tests. Although still in beta, component testing will be the most important feature in Cypress 10.

JobRunr is a library for background job processing in Java and an alternative to the Quartz scheduler. Our teams have enjoyed using JobRunr's built-in dashboard, which is easy to use and allows the monitoring and scheduling of background tasks. JobRunr is open source and free for commercial use; for features such as job migration and recovery, however, you need to get a paid license.

Million is a new virtual DOM JavaScript library. Similar to Svelte, it leverages the compiler, Vite, to create small JavaScript bundles with exceptional rendering performance. The Million library ships as a single NPM package with several modules — including router, jsx-runtime and a module for React compatibility to create single-page applications. Although React popularized the virtual DOM a decade ago, it's fascinating to see new innovations in this space.

Soketi is an open-source WebSockets server. If your application is compatible with the Pusher protocol, you can plug Soketi in directly as it fully implements the Pusher Protocol v7. We find the beta support for Cloudflare Workers particularly interesting because it opens the door to using WebSockets at the network edge.

OpenAI's DALL·E caught everyone's attention with its ability to create images from text prompts. Now, Stable Diffusion offers the same capability but, critically, it's open source. Anyone with access to a powerful graphics card can experiment with the model, and anyone with sufficient compute resources can recreate the model themselves. The results are astounding but also raise significant questions. For example, the model is trained on image-text pairs obtained via a broad scrape of the internet and therefore will reflect societal biases, which means it could possibly produce content that is illegal, upsetting, or at the very least undesirable. Stable Diffusion now includes an AI-based safety classifier; however, given its open-source nature, people can disable the classifier. Finally, artists have noted that with the right prompts the model is adept at mimicking their artistic style. This raises questions about the ethical and legal implications of an AI capable of imitating an artist.

Synthetic Data Vault (SDV) is a synthetic data generation ecosystem of libraries that can learn the distribution of a data set to generate synthetic data with the same format and statistical properties as the source. In the past, we talked about the downsides of using production data in test environments. However, the nuances of data distribution in production can hardly be replicated manually, resulting in defects and surprises. We believe SDV and similar tools can address this gap by generating production-like data for single-table, complex multi-table and multivariate timeseries data. Although SDV isn't new, we quite like it and decided to highlight it.

We're seeing some interest in the Carbon programming language. That doesn't come as a surprise: it has Google's backing and is presented as a natural successor to C++. In our opinion C++ can't be replaced fast enough as software engineers have shown, over the past decades, that writing safe and error-free C++ code is extremely difficult and time-consuming. While Carbon is an interesting concept with its focus on migration from C++, without a working compiler, it's clearly a long way from being usable and there are other modern programming languages that are good choices if you want to migrate from C++. It's too early to tell whether Carbon will become the natural successor to C++, but, from today's perspective, we recommend that teams look at Rust and Go rather than postponing a migration because they're waiting for Carbon to arrive.