Managing complexity of Angular applications

Let’s say you are a newcomer to modern front-end development and you need to implement a single page application. You already know HTML, CSS, and some JavaScript. You have heard that Angular is a solid framework and you like the fact that it is based on OOP principles you are familiar with. So you start learning it by taking an online course teaching its basics while at the same time reading the official documentation in order to explore various building blocks in more detail.

After a while, you feel quite comfortable using the framework and you decide to start building your application. Since you are a newbie in this area, you try to follow Angular Style Guide to avoid bad architectural decisions right at the beginning. You build small reusable components and fetch data from the API in singleton services as you have been taught. You are making a good progress, creating a lot of components and seeing the first results on a few screens of a really nice user interface you have already built.

But you feel that something is fundamentally wrong with your application. It is still quite small but there is already a huge complexity when it comes to interactions between components and data management. You have figured out how to avoid redundant API calls by remembering the data needed by multiple components but your adhoc solution seems to be a little bit messy and error-prone. You need to be very careful not to introduce a bug when extending some functionality. It is already such a pain developing this application and you cannot image how it will look like if it grows ten times or more.

The problem is that neither the online course nor the official documentation has taught you how to manage the application state. They have only introduced various Angular concepts such as services which they recommend for data sharing between components. But once your application starts growing, using services to manage its state is a way to hell.

Fortunately, there is a whole set of state management libraries that try to solve this problem. The most popular is Redux which is mostly used by React developers although it can be used with Angular as well. There are also some libraries designed especially for Angular such as NgRxNGXS, or Akita which are based on RxJS so you can keep using observables that you are already familiar with. I would recommend using NgRx as it is the most popular one among Angular developers. But feel free to try out more of them and choose the one that best fits your use cases.

I am not going to explain the concepts of FLUX architecture these libraries are based on as many others have already covered this topic quite well. What I wanted you to know is that you have encountered a common problem in front-end development that have already been solved by people much smarter than you (no offense). So there is no need to implement your own solution or hack your application until it becomes unmaintainable. Using a robust state management solution is the only way forward if your application is going to grow significantly.

How I switched from Java to JavaScript

A year ago, I was using Java for everything. Although I had previously used languages such as C/C++, Haskell, JavaScript, Pascal, and PHP for several school, hobby, and contract projects, I was not really good at any single one of them. At that time, the only language I felt pretty confident writing code in was Java. I had already been using this language for almost five years and knew both the ecosystem and the language quite well so it seemed like a good idea to dive deeper into it and become an expert in this area. But then something changed.

I graduated university and realized that although working for a corporation during my studies was a good experience as well as an easy source of moderate income, it was not something I would like to do in the near future. At the same time, I was asked to join a team forming a new company as a co-founder and technical lead and since I had always wanted to start my own company I could not have said no to that offer.

They had already been developing Lumeer, a modern data definition and processing platform, for a few months when I joined the team. The back-end of this application was written purely in Java so I was able to start contributing almost immediately. However, the application was intended to be used by non-technical end-users which meant that the vast majority of the work would need to be done on the front-end side. A simple user interface based on the latest version of Angular was already being developed. Since I was supposed to be the technical lead responsible for the whole development process but did not have much experience with front-end, I knew I had to become pretty good at it in order to do my job well.

As I was quite familiar with the Java ecosystem, I could remember what huge amount of technical problems I had already solved in this area and was still far from being an expert. When I though of going through similar problems in the JavaScript world once again and imagined how much time it would take just to get to the point where I was with Java at that moment, I was a little bit worried if that was the best investment of my time. But I said to myself if a lawyer was able to become a front-end developer, I could do it as well and it would probably be a lot easier for me since I had already been familiar with many principles which can be reused across different programming languages.

So I started reading a lot. I somehow found JavaScript Weekly, a weekly digest of the JavaScript news and articles, which was and still is for me a great way how to keep up to date with all the changes in the JavaScript ecosystem. I was always looking forward to the next week so I would be able to further broaden my knowledge of this whole new world. I read many articles about the language and new useful JavaScript libraries. At the same time, I started reading Angular documentation and took a course at Udemy in order to develop better understanding of the framework we were using. However, I think the best investment of my time was reading two great books, Speaking JavaScript and Exploring ES6, which are available online for free and go really into the depth on various language features. Had I not read them, I would have probably wasted a lot of time debugging problems caused by unexpected language behavior.

Fast forward nine months and (luckily I am not a father but) I feel quite confident with my JavaScript skills so much that I can even fix a bug in a popular library. Last year, I read much more about the JavaScript ecosystem than I had ever read about Java and related technologies before. Although I am still learning and dealing with new problems, I can say that the worst part is over and there is a bright future ahead of me. But more on that next time.