DEV Community: Alexey Karpov

Frontend predictions for 2028 and reflections on the last 5 years

Alexey Karpov — Sat, 25 Mar 2023 11:38:32 +0000

Why I think that WebAssembly will rise, ignite SSR and tooling (r)evolution, but something will remain the same.

tl;dr:

There will be even more server-side rendering and frontend tools written in other (fast) languages.

WebAssembly will be the next hot thing. It's too cool not to be.

Something will remain the same, so React, Angular and Node.js will continue mostly as they're today.

Some reflections on the last five years.

Around five years ago I posted a silly joke on LinkedIn: "Five years later: angular 15, react 25, babel 17, webpack 20."

It was a time of innovative tools, a hunger to explore the latest trends, and a frontend hype train eagerly embracing the latest advancements. Turns out, I was right only on one point, Angular, and missed all the others. Still, it was fun to find this note five years later and think about what changed since 2018. I'm posting this note to share how I see the near future, and I also hope to amuse myself another 5 years later. And maybe some readers will be amused right now 😄

Prediction 1: We are moving back to square one.

Curiously, at the beginning of the 2010s, the majority of web applications were server-side rendered with occasional interactive JS add-ons.

And now again, we will see even more server-side rendering! This time it's different, though. We went a long way, browsers offer much better APIs, and we have WASM.

Back in the day, the Ember framework pioneered the idea of CLI that accompanies the frontend framework and helps with bootstrapping, and managing the app components and upgrades. Angular adopted the idea as well and successfully uses it today. Following Create React App, other React-based frameworks offer the same idea.

Given the popularity of Go and the raising popularity of Deno, it looks like we will see more full-fledged solutions that offer you everything: compiler, dependency management, linter, code formatter, language server and so on.

that's what our future looks like, even though it might use some font (and perhaps color) improvements 🧐

Prediction 2: WebAssembly is the next hot thing.

During the next 5 years, we might see a rise of WebAssembly. Today, it still has to rely on JS bindings to update the DOM elements. WASM develops fast, and we can see a way to directly update DOM from WASM. Everybody will suddenly discover that they can create full-stack web applications in their language of choice – and all of that will be directly compiled to WASM.

Perhaps it will start another gold rush of front-end or full-stack frameworks. And then we will have an entirely new generation of web developers who are complaining about framework fatigue!

Jokes aside, I see the potential improvements in WASM as a very positive thing. WASI (WebAssembly System Interface) can help on servers, on edge devices and even in blockchains (whaaat?.. well, they also need a compile target for smart contracts and stuff). That's a portable byte code that one day might even eat Docker's lunch and partially replace it. But perhaps 5 years won't be enough for such a futuristic vision.

Plugins for the existing software might become a common practice. Here, let's quickly step back a little. JavaScript's original goal was to modify or extend the behavior of browsers when they open web pages. WASM can do the same for the existing software. And WASM can probably do the same for the existing software if developers integrate support for extensions.

Some quick speculations on this technology in general:

WASM will get direct integration with DOM. Or at least it will be streamlined. WASM will also get direct access to the browser's APIs.
It will lead to a boom of frontend frameworks written in other languages. It's already started, but I'm convinced that the absence of direct DOM integration/APIs is a limiting factor for them.
We will see entirely new languages that compile to WASM. They will attempt to invent a straightforward syntax to operate on the front end. Inspired by Svelte and JSX.
One of the interesting properties of such languages will be feature completeness. Just like Go or Deno, they will offer the entire toolchain to develop and ship the software. In some cases, it will also include hosting/deployment. I hope to see more players like Vercel and Netlify.

Prediction 3: Angular 25 and Node.js 29.

Did you ever wish that something simply remains in this crazy world? Well, there is Angular and Node.js!

Even though React cemented itself as the standard, there is still a niche for other approaches, like a more traditional Angular. I will make the most boring prediction: Angular will still be alive in 5 years, and it will still follow the same release cycle. And it will still be relatively popular. So I kinda exercise the naïve weather forecast, "tomorrow the weather will be the same as today". It's often not that far off!

And I think it's even easier to make such a prediction for Node.js. A foundation develops it and given its huge impact on the entire frontend development, I assume that everything will remain the same.

Did it even worth a prediction? Well, I want to hit at least one of them right. I also want to remember a simple idea. There will be new trends, but something will likely remain the same. And yes, of course, React and its hooks will still be with us in 2028, definitely no need to worry here.

Reflections on the past half-decade

it sounds like a lot of time when you put it this way!

On Node.js

Let's play some archaeology and revisit some news from the past. In the frontend community, Angular wasn't the first to adopt a strict release schedule. After IO.js rejoined with Node.js in 2015, the Node.js team committed to following the release schedule and shipping a major release every 6 months. It helped to avoid stagnation, which was the main reason behind the IO.js fork in the first place. Great decision! Because Node.js regained its momentum and continued to be a backbone for most of the frontend innovations.

React

Well, we don't have version 25, but look at how many things changed in the last 5 years! We had version 16.1 back in the day, and we're sitting on 18.2 now, which was released in June 2022.

Main changes in the last 5 years:

Finalized Context API (at last!)
Function components are mainstream now thanks to hooks. In their turn, function components helped to achieve much better integration with Typescript. Oh, it was such a pain to write class components with Typescript 🤕

We are relieved now!
Gradually shifting focus to server-side rendering.

As it seems to me, React reached its productivity plateau. We still might see more new stuff like signals and perhaps beyond that too. But I personally hope that the React team will stop with the current feature set. I don't want to see any groundbreaking shifts in the core of React again, and I'd rather accept it as-is with all its strengths and weaknesses.

almost a mandatory photo of a code editor from an oblique angle. still looks cool!

Build tools

In fact, there was only one major release for Babel and two major versions for Webpack. Retrospectively, it makes a lot of sense. With the rise (and fall) of Create React App and other ways to bootstrap applications, the focus of app developers finally shifted away from building tools. Yes, it's still a fascinating and crucial piece of software, but the underlying machinery should be just an abstraction layer for the app developers.

Tools like Vite and Parcel can replace Webpack when we need a somewhat custom build process, but without too many degrees of freedom. It's costly to do the precision control of the build process.

Tools like Esbuild and SWC offer faster ways to compile the code thanks to their implementation languages (Go and Rust respectively).

There is also Turbopack which is inspired by everything else! I can only welcome the new generation of build instruments that don't compromise performance.

Angular 15

Yeap, it's here! Just as the Angular team promised us back in 2016 with the long-awaited release of Angular 2. In fact, the only reason why I got this one right is that the Angular team committed to releasing a major version twice per year. They still follow this rule. Which is great! Sometimes they delay a major release by a month or two, but otherwise, there weren't any significant interruptions in the flow. The predictable release schedule helps to plan development and migrations and also brings confidence that there won't be hard pieces. 6 months isn't enough to build something entirely groundbreaking, but it's still enough to make gradual improvements and deprecate some old patterns. The Angular CLI makes most of the breaking changes easy to manage: you simply run the command, and it automatically replaces old code with the new one or at least gives you a bit of advice on how to update things manually. And I really like the progress of Angular. Since 2018, the team introduced many great features and delivered a very stable framework. Despite many other (very cool) tools being released, Angular remains a solid choice for classic SPA apps.

If you are interested in Angular, please feel free to check out my other article: Clean Architecture in Frontend.

Clean Architecture in Frontend

Alexey Karpov — Sun, 21 Aug 2022 11:21:08 +0000

I wanted to share several insights that I found helpful for large-scale front-end applications. I want to talk about ideas that proved reliable in practice. At the same time, I pursue simplicity in my explanations.

I also implemented an uncomplicated To-Do List application to support the verbal explanation. The application uses the same design principles I apply on a much larger scale. I will use this application to give examples of individual components. You are also welcome to check out the source code on Github to examine the complete picture yourself.

The examples use Angular and tools around it. The general principles can be applied in any other ecosystem.

Screenshot of the final application. You can play with it here.

Clean Architecture

I'm inspired by Bob Martin's book, Clean Architecture. That's a great read with a lot of insights about software architecture in general. It's an excellent and well-structured overview of things that matter during system design. I found the ideas of Clean Architecture are applicable in frontend development too.

I found this diagram in the book and The Clean Code Blog.

Clean Architecture is a way to isolate an application from frameworks, UI, and databases and ensure that individual components are testable. It leverages SOLID principles and shows how to put them together on a larger scale.

In this article, I'm describing just one way of Clean Architecture implementation. I use Angular as a framework and as a dependency injection container.

High-level frontend architecture

When I approach a new feature, I think about the underlying entity and the operations it needs. This diagram shows a high-level architecture of a new feature. Let's take a closer look at each of these layers.

Entity

The application layers have a hierarchy. Entities are on the top, and UI is on the bottom. A layer must not have a dependency on any other underlying layer. For example, the entity should know nothing about the UI. As trivial as it sounds, Entity is probably the most crucial part of clean architecture. That's where I start designing completely new features. This part I protect from the changes the most. Although it's not on the diagram, the Entity flows between all these layers.

Looks simple enough, right? Yes, an entity can be as simple as a Typescript interface. The core idea is to include only those properties that describe the domain of a new feature. Any state that can be derived from these properties doesn't belong here.

One of the typical mistakes is putting to the entity additional information that helps with rendering. Any time you modify the entity, you must double-check that the new data belongs to the domain. This information must be relevant regardless of the UI, data management framework, or API.

Data layer

The role of this layer is to provide a toolchain for the entity. What operations do you need? What are the boundary conditions before/after the operation is done? How often adapter (API) is called? Do you need optimistic updates? What about sorting, filtering, and pagination? Perhaps, you also need to search? And you probably need some specialized operations like done/undone for a to-do element.

There are many possibilities but make sure not to over-engineer your application. The business must require certain features before you implement the new operations to the data layer. Otherwise, the application might become too complex without a proper reason. In other words, why implement a feature if nobody needs it? Less code means less maintenance and faster implementation of new requirements.

The rest of the application depends on the logic in the data layer. It decides if UI receives an object from a cache or the remote API.

You can implement the data layer with any library or pattern you find appropriate for your application. It depends on how complex the app must be according to the business requirements. Some possibilities:

Class with internal state. It might employ RxJs Subjects/Observables.
Any Redux-inspired library. In this case, Facade will trigger actions instead of calling the data layer's methods directly.
Any other state-management library.
Facade can call the Adapter directly. Essentially it ignores the data layer if you don't need any caching logic.

Adapter

Strictly speaking, the Adapter belongs to the data layer too. That's a powerful concept to ensure that the application is well-isolated from the API and its potential changes. Data services depend on the adapter's abstraction that we fully control. It is an implementation of the dependency inversion principle: I create an abstract class for the adapter and then use it in the data services. I also write an adapter implementation that is entirely hidden from the rest of the application. As a result, the data layer dictates its technical requirements for the adapter implementations. Even though data flows from the adapter implementation to the data services, the adapter still depends on the data layer, not the other way around.

You can design your application in a way that the entire API interaction is fully isolated from the logic of your application. A couple of my favorite benefits:

If the API changes, then all I have to do is to adjust adapter implementation.
If the API isn't available, I can implement my application nevertheless. And after API is available, I still have to adjust only the adapter implementation.

In this application, I went with a localStorage-based implementation of the persistence layer. Later it can be easily replaced with API calls. This pattern saved me countless hours in my practice.

Facade

In today's example, a facade is an object that acts as an interface between UI and the data layer. Whenever UI needs to load todos or create a new one, it calls one of the facade methods and receives a result as an observable.

The facade, on the other hand, can be anything inside.

In simple scenarios, I directly call methods of adapters if I don't need any caching or data management.
In other cases I might trigger a redux-like action, e.g. dispatch(loadTodos()) and then listen for subsequent loadTodosSuccess and loadTodosFailure actions.
I can also pass the call from the facade to another service that orchestrates the interaction with adapters. It might be a self-written service based on RxJS Subjects or a third-party service like the ones from @ngrx/data (not to confuse with bare NgRx)!

I distributed responsibility over different classes. Data service is supposed to request data from the adapter, save data to the repository and orchestrate optimistic updates if needed. Data service defines how to alter the state after each operation.

Facade, on the other hand, exposes data API to the UI. It can request the list of to-dos or create a new one and then receive the response from the unified todos$ observable that hides all the responses' complexity. At the same time, you can notice that I use subscribe() inside the facade method and then return an observable itself.
I made such a decision for the convenience of application logic. Sometimes components that trigger an operation and the ones that receive the result are different. They also have different lifecycles. In this to-do application sometimes a trigger component is destroyed right after it requests some data, so I need to ensure that something else will receive the result and keep at least one subscription active. Facade conveniently feels this gap by introducing mandatory subscribe() inside. In addition, it ensures that the underlying data service doesn't have extra logic that is relevant only to the data consumers.

UI

Why, UI has logic too! It's a different one though. The UI talks exclusively to the facade. The job of the UI is to call facade at the right time, e.g. initialization of a component or some specific user action. In addition, UI is responsible for managing its state. *Not all the state goes to the data layer. UI-layer must operate the UI-specific state. *

There are many approaches to dealing with UI state. And again, the choice depends on the business requirements. Sometimes it's acceptable to store state simply in a component. In other cases, there should be a way to exchange data between UI components. I won't cover this topic today, and it might be a conversation for another day.

Putting everything together

The data layer consists of the data service and the repository. Data service orchestrates operations and logic while the repository is responsible for in-memory caching. I use @ngneat/elf for the repository implementation. Although it can be any other library or even fully custom code.

The data service interacts with the abstract adapter to fetch the data. For the sake of simplicity, I scrapped the backend altogether and used a local-storage-based implementation. Remember, when the backend is available, the adjustments in our frontend application will likely be trivial.

What's next?

I intentionally pasted only part of the code in the article to illustrate the ideas. I encourage you to browse the source code and see everything yourself.

Would you like to read more on this topic? Perhaps, something else? Would you like to contact me? Feel free to leave a comment or find my contact on my personal page.

Attributions

The cover image: Crystal of copper sulfate. CC 4.0 Wikimedia Commons