Keeping up with the "constant catching up" in Frontend engineering

The frontend engineers face a challenge "Constant catching up" there almost every day a new thing to learn or a new framework to check, and that needs a lot of energy and a long breath to do.

Furthermore, frontend apps are getting more complex, and the use cases are going beyond building a website or an app. We start seeing architectures and solutions to simplify the technology we learned in a few weeks, and those solutions need a few weeks to learn.

In this article, I will try to focus on the frontend constants that each of us should know to overcome the main challenge of the frontend engineering -"Constant catching up "- by abstracting the frontend frameworks/libraries.

What are the constants in frontend engineering?

• Everything should run in a browser.
• We have to communicate with servers to load data, save data, or load assets.
• Users have to interact with our apps.
• We, as engineers, have to write code to make the above happen.

The entire history of software engineering is that of the rise in
levels of abstraction. Grady Booch

Everything should run in a browser.

This fact should be a relief for all of us, because if we understood how browsers work, then we have come a long way of establishing our career as frontend engineers based on its core.

Two main things you need to focus on:

1. DOM Manipulation
2. Event Loop

DOM manipulation is crucial, and you need to understand how it works and what it does, and what might go south. Frameworks leverage DOM in different ways, but still, they are using the same APIs.

When looking at any FE Framework, please look at how they deal with DOM manipulation and how they deal with the fact that DOM operations are performance expensive.

For example, React deals with that with the Virtual DOM to optimize the rendering process.

Here is a gist from Paul Irish, listing the most expensive methods and properties that make the browser reflow - the process of synchronously calculate the style and layout, and ask the browser to repaint the affected elements -.

Event Loop, it's known that each tab has a single thread, but still we write async code all the time with JS on the browser; how is that possible?

Event loop is the answer. Wikipedia defines it as "In computer science, the event loop is a programming construct or design pattern that waits for and dispatches events or messages in a program. The event loop works by making a request to some internal or external "event provider", then calls the relevant event handler."

The event loop interacts with web APIs such as ( DOM, XMLHttpRequest, and more ). We have a task queue, which has all the tasks to be run, including your callbacks, and we have the call stack something being processed and the event loop, which takes from the queue to the call stack when the call stack is empty. Call stack adds to the queue ( Callbacks ) and interacts with the web APIs.

Check this excellent talk by Philip Roberts, What the heck is the event loop anyway? | Philip Roberts | JSConf EU also Loupe that visualizes the event loop by Philip as well.

Client-server communication

Our app runs in the browser, and it needs to load assets, load data, and save data.

Loading Assets

How the browser load assets will affect the performance, and the user experience is one reason we have bundlers and different HTML attributes of prefetching and lazy loading.

This topic is crucial because you will know why some tools exist, handle specific performance issues, and mostly why specific features exist in some frameworks such as React.lazy().

Look at how we started with client-server communication and ended with mentioning a feature from one of the most popular frontend libraries.

Loading Data / Saving Data

Loading & Saving data need a client-server communication; it might be a pulling technique or pushing such as sockets. Browsers have limits on the number of concurrent requests per domain, affecting how we show our users' data and how they interact with our application.

HTTP interceptors might take place in our apps, validate data or transform it, etc. Those interceptors will use the browser fetch/XMLHttpRequest API or and add some logic around it despite that they come with a framework or a separate library.

User experience

FE Apps are interactive, so we need input from the user or wait for her action to apply logic, such as updating the DOM.

Updating the DOM task can be pretty straight forward such as

document.getElementById("myDiv").innerHTML = "New Content";

or a very complex one such as managing two way data binding in VueJS

<input v-model="message" placeholder="edit me">

<p>Message is: `{{ message }}`</p>

At the low level, they will both use the event loop and let the browser take the right action.

User experience is not only about DOM manipulation or performance, but some frameworks also provide a design system to maintain UI consistency.

Developer experience

The rise of frontend frameworks & libraries focuses a lot on how engineers interact with this tool, and we are grateful for that. They care about our productivity, the clarity of code we write, the amount of code we produce, how it can scale, and how easy and fast we can go.

The community around a specific tool is crucial for its success, its problems, and how it resolves it is what gives it its early adopters.

Developer experience, or DX, doesn't stop here but goes to cover the learning curve, productivity, tools, and much more.

To keep with the constant change, you have to know what value is the tool adding to you as an engineer, and DX is directly impacting the UX, don't compromise over it.

Let's try to abstract a feature from React and Angular.

React

In React, let's take the first feature, Composition.

"The key feature of React is composition of components. Components written by different people should work well together. It is important to us that you can add functionality to a component without causing rippling changes throughout the codebase."

What it affects?

1. Developer experience, reuse the code easily.
2. User experience, consistency.

JSX contributes the most to the composition feature, but the browser doesn't understand JSX. That's why we have transpilers to convert a component to JS code that can interact with the DOM APIs; nevertheless, it has VirtualDOM, it will use the DOM.

Angular

SPEED AND PERFORMANCE / Code splitting

"Angular apps load quickly with the new Component Router, which delivers automatic code-splitting so users only load code required to render the view they request."

What it affects?

1. User experience, the performance of the apps will be faster.
2. Developer experience, you don't have to worry about this. We got your back.

Code splitting will be done internally in Angular AOT compiler to decide how to split the code, and the browser has to determine when to load which chunk and how.

Summary

We should focus on understanding the constant things or the things that are hard to change in frontend engineering. We should understand how our apps are running internally inside the browser to correctly use the right tool, framework, library, or even the line of code to achieve our goal.

Becoming a sound frontend engineer implies that we have a smooth learning curve journey, our minds are open to quickly grasping new frameworks, concepts, or features. The code we write, the passion we feel while writing it, and our pride after achieving our goals are priceless.

For a simple reason, we write frontend apps, deliver value for our users, and the value will not be enough if we, as engineers, haven't enjoyed the journey.