I've been working on many different projects as a tech leader. At some projects we were hiring people, and during interview I was realizing that actually majority of devs don't have fundamental understanding of basic concepts. By understanding I don't mean learning them by heart. I mean understanding why things work the way they do. For example, why do we have to use binary in programming? Or what is a computer? How can you build a software for a computer if you don't know what a computer is?
This article is not a complete overview of the whole frontend knowledge map. Instead, I will try to show things from a different angle: how to apply systems approach and generic research techniques to learn anything. I hope this will boost you somehow. Let's start.
What is the goal of Software?
Let's break it down: hardware and software.
Hardware is a physical device. Hardware can be programmed though. Initially, all the programming was done on hardware.
This led to a problem of slow iterations. If you want to change something in hardware, you have to replace or patch the hardware. It was complicated and expensive.
Later people came up with software. Basically ability to build and deliver program to a hardware. The hardware would still have some firmware, but in this case it was more generic and flexible.
C language was the revolution, because it allowed to give very high level of abstraction and to write code that is very close to the hardware. It's funny that nowadays C is considered low level language.
For the last 80 years people have been working on improving development process to reduce time from idea to the production and to improve quality.
What is backend
First programming was used in military and government. Later it came to business as well. Backend developers at that time were developing programs to support business processes like accounting, manufacturing.
I won't cover this in details, but keep in mind, that backend is something that is running required business processes, using tools like database, messaging systems, cron jobs, in-memory databases.
What is Frontend anyway
First programs were just simple terminal applications that would take input from the user, do some calculations and would display some output.
However, to optimize more complex processes terminal was not enough. Therefore, GUIs were invented — Graphical User Interfaces. They would allow to interact with the software in a more natural way. Basically documents and blank forms were displayed on the screen using some code.
The reason to separate Frontend development from Backend was because the context of the problems was too different. In backend you deal with distributed systems, databases, networks, uptime.
In frontend you deal with UI/UX, different devices, different screen sizes, different browsers, and many niche specific problems.
What you need to know
First, consider key components. They are:
- Computer
- CPU
- GPU
- RAM
- Display
- SSD
- Data bus
- Power supply
- Keyboard
- Mouse
- Other input devices
- Backend
- Servers
- Databases
- APIs
- Network
- Users
- UI/UX designers
- Backend developers
- Product managers
- QA engineers
- DevOps engineers
You need to understand this pipeline
- User types in the browser address bar
https://your-application.com - Browser parses the URL to identify protocol (HTTPS), domain, and path
- Browser checks its cache to see if the DNS resolution is already available
- If not cached, browser initiates DNS lookup through the operating system's resolver
- OS resolver checks its local hosts file and DNS cache
- OS resolver sends a DNS query to the configured DNS server
- DNS server returns the IP address of the nearest CDN edge server
- Browser initiates TCP connection to the CDN edge server IP on port 443 (for HTTPS)
- TCP three-way handshake occurs (SYN, SYN-ACK, ACK)
- Browser and CDN server perform TLS handshake to establish encrypted connection
- Client sends "Client Hello" with supported cipher suites
- CDN server responds with "Server Hello", certificate, and selected cipher
- Keys are exchanged and encryption is established
- Browser prepares HTTP request headers (User-Agent, Accept, Cookie, etc.)
- Browser sends the HTTP GET request to the CDN server through the encrypted connection
- CDN edge server receives the request and checks its cache for the requested content
- CDN server retrieves the cached static files (HTML, CSS, JS) without backend processing
- CDN server prepares response headers (Content-Type, Content-Length, caching directives)
- CDN server sends the HTTP response with status code and HTML content
- Browser receives the response and begins processing it based on Content-Type
- Browser validates the response (status codes, security headers)
- Browser begins parsing the HTML document, creating tokens for each tag, attribute, and text
- Browser constructs the DOM (Document Object Model) tree from these tokens
- Browser discovers and prioritizes resource requests (CSS, JavaScript, images)
- Browser sends requests for critical CSS and blocking JavaScript (also served from CDN)
- Browser constructs the CSSOM (CSS Object Model) tree from CSS responses
- DOM and CSSOM are combined to create the Render Tree (only visible elements)
- JavaScript parser compiles and executes scripts based on async/defer attributes
- Browser performs layout/reflow (calculating exact positions and sizes of elements)
- Browser creates layers for content that should be independently composited
- Browser performs painting (converting render tree to pixels in each layer)
- Browser performs compositing (combining layers with proper stacking and blending)
- GPU processes the composited framebuffer data
- Display controller sends the pixel data to the physical screen at the refresh rate
- Browser establishes event listeners for user interactions
- UI is continuously updated in response to user interaction, timers, and network events
It's ok if something doesn't look familiar at the moment. You should google it right away. Or check some source code of v8.
You need to understand what people want from you
To understand what people want from you, you need to understand what kind of people there are involved.
In outsourcing companies there is a customer and team of developers. There are also end users that will use the product.
If you are working in a product company, customer is actually stakeholder within a company.
Also depending on type of product, whether is's B2B or B2C, you will also have different considerations, constraints and requirements.
Customers don't know what they want
This is what product team is for. But customers always almost know what they don't want. With proper investigation you will be able to find out what they actually want.
The point of this is to understand core process of customer development:
- Define business objectives and success metrics for the product
- Stakeholder interviews to understand organizational goals and constraints
- Market research to identify trends, competitors, and opportunities
- Create user personas based on research data, not assumptions
- User interviews with target audience to uncover pain points and needs
- Journey mapping to visualize current user workflows and pain points
- Job-to-be-done analysis to understand what users are truly trying to accomplish
- User flow mapping to determine optimal navigation paths
- Wireframing key screens to establish layout hierarchy without visual design
- Content strategy development to plan messaging and information hierarchy
- Design system updates to establish consistent UI patterns and components
- Prototyping at appropriate fidelity level (low to high) based on testing needs
- Usability testing with representative users to validate design solutions
- Visual design refinement to create aesthetically pleasing, on-brand interfaces
- Animation and transition design to enhance user understanding and engagement
You don't have to know how to do all of this yourself. But it's important to see how frontend implementation is related to the design process which is behind the scenes. This way you can see the meaning of what you do.
Do you have team/tech leader?
There is a probability that on your project you will have someone actually responsible for the whole result. Decent team leader will support you, teach you, help you to grow.
Unfortunately, sometimes there are communication issues between devs and team leader. For example, developer delivers the code and team leader checks it on code review and tells that it's looking shitty.
Yes, I think it would be hurtful for anyone to hear that. Especially if you are junior developer, busting your ass 12 hours a day to get things actually done while the team leader is drinking coffee working literally 20 minutes per day.
How to deal with it?
Understand the root of the problem. Be pragmatic, use system thinking. If someone is not satisfied with the result, first thing is you have to understand — why are they not satisfied? Did you both agree on certain criteria? If not, why did you start proceed to task without agreeing? Why did your team leader allow this process to work that way?
If something happens and people are blaming each other — it's a sign that there is a problem with the process. And it's more of a sign where the person responsible doesn't want to admit his mistakes.
Everyone makes mistakes, it's not a big deal. The only important question is — are you learning from them? If you are in an environment where nothing gets done, and mistakes aren't getting fixed — you need to change your environment.
Find problems and act
If you want to grow, it doesn't matter if you are frontend developer, designer or car washer. Your employer wants to live in a better future. If you help them to achieve that, you have a chance of setting up more strategic looking relationship with them.
In terms of Frontend development, here are the most common problems that you can find:
- Time to market is not reducing or doesn't even get tracked
- No clear definition of done, lack of requirements
- Developers can't answer question — why are they doing what they are doing, what is the real value and purpose
- margin-top: 15px — 15 is not divisible by 4, and margins are anti-patterns as hell, this is why
- No dev and testing workflow defined
- Requirements are changing during the work sprint
- Backend API is not documented
- Backend API is using REST (huge anti-pattern, but people believe that's the standard)
Keep the professionalism
Other people see and remember what you do in public. You have to keep professionalism. See the goal clearly. Make sure everyone is seeing the same goal. If there are conflicts, propose a solution, stand on it, but be respectful.
This is mostly enough to be a good developer. All the rest — you can learn any time. Most of the problems come not from the lack of knowledge, but from missing the right initiative. I hope that you readers see the point. Now since I've finished this article you can go and google all new words I've mentioned.
Good luck!
