Just to clarify up front, this post is about Angular 2 (or 4 or most recently just Angular™) and is rather “meta” in its nature. Also please forgive me and entertain a little story in the beginning which sets the stage for the main points later :)

Over the last couple of years I took part in many software engineering interviews both in role of interviewee but lately mostly as an interviewer. With my colleagues, we have seen many very talented frontend developers while searching for the right teammate to join our forces and help us building our product.

As a general rule (there are always exceptions), most of these guys had background in web design / website development and while you may argue that you can’t really get much closer to the frontend than that, there is a slight problem with this approach. On the other hand, people with previous backend experience who switched sides and focused on frontend proved to have an non obvious advantage.

Developer vs Engineer

Most of us can still remember our humble beginnings when we tried to code for the first time. Web development is a huge domain and there is just so much to learn. That magical feeling when you created your first HTML document and you opened it in a browser and voila, it displayed your content in all its glory!

Fortunately, this wasn’t the end of story… You ventured deeper and started to deal with the dark arts of CSS (and browser inconsistencies ) with the goal to make things pretty and shiny and user friendly and all those things we strive for. But there was a problem, it looked nice but it didn’t really do anything.

The next natural step was to discover Javascript and start copying and tweaking small snippets of code from the internet to achieve the desired results. As time went on you probably discovered libraries like jQuery and frameworks like Ember, Angular or React. You learned their APIs and slowly mastered craft we know as frontend development. You could actually bring ideas into being, create webapps and for a time it was good…

After some years you probably asked yourself questions like these:

Is there more to it? How do these things actually work? What makes my arrays and objects tick deep down under the hood of a browser or node?

The projects you are now contributing to changed too. Instead of websites and simple CMS solutions you are now working on the full blown web applications with their complexity, unique problems and challenges.

At this stage, your skills are tested from different angles than previously and you have to start to thinking about more advanced concepts on the higher level of abstraction. Stuff like application architecture, performance and maintainability. Welcome! You entered the domain of software engineering.

Repeated (but limited) interviewing experience showed that there is quite a supply of frontend devs who can make things pretty and attach click handlers. On the other hand, not so many of them possessed deeper knowledge about the whole stack, didn’t shy away from internal working of browser and node and had experience with shaping of large modern frontend codebases.

Frontend software engineering know-how represents an unique opportunity to set yourself apart from the crowd

And the good news is that you’ll meet quite some unexpected allies on your journey to software engineering mastery.

Leverage and learn from frameworks and libraries

Software engineering is an unique domain where people actually share their know-how with others without expectation of any monetary compensation. You can learn from work of some of the brightest minds in the industry by following their open source projects and blogs.

In fact, these open source project represent crystallized state of the art know-how of the whole community. All the best practices and approaches tested by hundreds of teams across the globe who employ these solutions in their own projects.

All the time invested and people thinking very hard about how to improve current processes to push it to the next level bring us many great frameworks and libraries to use and learn from.

Library is a set of useful functions that helps you to deal with particular problem, framework on the other hand enforces application structure, patterns and best practices

Levels of abstraction

While it is very useful to understand whole stack and you definitely should, (you know, the vanilla.js stuff, DOM and whatnot), people created so many frameworks for a reason. We don’t want to spend our time dealing with everything on the lowest level possible.

Registering and cleaning up of click handlers to prevent memory leaks by hand can be quite tedious and error prone activity

What we want is to abstract away everything unessential so that we get to a level where we can focus on what really matters - delivering useful features to our users - while still preserving flexibility to get our hands dirty when necessary. Modern frontend frameworks are actually doing pretty good job and operate on level of abstraction that is just right to achieve exactly that.

In my personal opinion, libraries like React are great because they allow you to shape your stack as you see fit by selecting a set of additional libraries to manage stuff like state or routing. On the other hand, opinionated frameworks like Angular represent better option for people who would like to learn best practices on their way to software engineering mastery

Lessons taught by Angular

Opinionated framework like Angular (other frameworks too for that matter, remember React is a library) can teach you many of the industry’s best practices and help you to adopt mindset necessary to successfully implement nontrivial web applications.

Their goal is to support nontrivial apps and that’s exactly the reason why some people consider these frameworks to be overkill. But hey some people have to build large applications with tens to hundreds of screens together with the team of 20+ developers. There has to be some method to this madness…

Divide and conquer

In practice, successful projects have tendency to grow quite large, like really large, like unmaintainable humongous large. This usually results in all sorts of problems with maintainability and we’re usually standing in front of challenge on how to split this SPA monolith into manageable logically independent chunks of code.

CAUTION! Symptoms of overgrown codebase may include: feelings of being lost, fear of touching old code, unexpected side-effects and a ritual harakiri ot the guy you hired last week…

Angular has a concept of Module which can group and hide (encapsulate) its internal parts while clearly defining interface with imports /exports for the outside world. This can significantly reduce the amount of code you have to read and understand before you can see a big picture of the particular codebase because you don’t have to deal with unnecessary details. It will make you ask yourself questions about what functionality should you expose when creating a new module.

Hint: You can change private parts of your module without breaking colleagues code…

Dependency Injection

For some arcane spell from Java interviews, for others their daily bread and butter. Dependency injection (DI) is an implementation of inversion of control design pattern which sounds all fancy and complicated. In fact it’s a rather simple concept which boils down to the way we approach creating of new instances of components and services in our applications.

Let’s say component uses two other sub-components and a service to perform its functionality. Instead of creating them by itself, it will receive ready to use instances from container which in our case is the Angular framework.

This has many positive implications on testing and maintainability. For instance, it becomes easy to mock network or database communication in our tests. Angular takes this concept one step further with support of multiple nested DI containers called hierarchical injectors.

Routing

One of the most important features of Angular router is that it supports lazy-loading of your routes out of the box. This has some interesting consequences. The code of the module which is loaded when navigating to lazy loaded route is physically not present in a browser until that navigation happens. Obviously this lead to less network traffic and faster load times but it also results in cleaner architecture!

Angular router also enables preloading of the lazy routes without user navigation but that doesn’t change the fact that initially the lazy code just wasn’t available at the application startup

Absence of the module’s code forces you to think about how are your modules (and their components and services) depending on each other and this results in architecture with one way dependency tree where whole large chunks of code become completely independent from each other. This enhances maintainability and testability of whole application and lowers cognitive load needed to reason about some specific part. More engineers can work on a project without stepping on each others toes. It also makes you think twice about what is the essential shared functionality which has to be accessible by all other modules of your application and lives in application’s Core Module.

See? These are the engineering concerns par excellence…

Shared stuff

Most of the times you will realize that there is a clearly defined subset of components and services which are independent from a particular business feature and are reused across the multiple parts of your application.

As an example, let’s take a domain specific calendar widget with normal and special dates. You might need it while implementing various business forms across many different parts of your application. Naturally it makes sense to implement it in such a way that the component itself doesn’t contain any specific business logic.

In fact, this kind of architectural requirements is present in most of the projects and therefore easily anticipated. Angular documentation deals with the concept too under the name Shared Module.

Bonus: Unexpected killer feature of Angular

I would say that the ultimate killer feature of Angular is in fact it’s online documentation with all the best practices and recipes on how to optimally tackle your challenges when building an application. Officially defined style guide can bring much needed harmony on bigger projects where many engineers are required to work on many different parts of the application in parallel!

Much praise and thanks to the team and all the contributors who created such an extensive documentation!

Yes, we made it to the end!

Don’t forget to recommend and share this article if you found it helpful and check out other interesting front-end related posts like…

Follow me on Twitter to get notified about the newest blog posts and useful front-end stuff.