Frontend is simple
Introduction
If you’re an experienced frontend developer, there are good chances you have heard this sentence before. I wonder what were your thoughts. Did you agree with it? Did you start a big discussion fighting hard to convince whoever said, the opposite, with blood in the eyes🤬?
Before focusing on frontend development, I was also full-stack working with Java for 2,5 years and also Php (for also 2,5 years) in agile teams. I was always inclined towards the frontend ecosystem, as it’s how I started, but I had to experiment with backend development before taking a decision for my career.
In my case, I chose frontend because, among many things, I really like to build things other people will see. I like building interfaces for websites that my friends located anywhere in the world will interact with. IMO it’s easier to get other people’s feedback and it makes my day when they do it. I just feel proud of it, you know?
Back when I started, in 2010, jQuery was still the king and the challenges in the frontend were to cut some images from PSD files and optimize them for better performance and make the page as lighter as possible to be competitive for Search Engine Optimization(SEO — mark this word, I’ll talk a bit later about it).
We used to do a lot of animations as well, and jQuery and other libraries were making it really easy. I know many people at that time that didn’t even know Javascript. They knew jQuery. On StackOverflow, all the answers used to be jQuery-based. VanillaJS seemed to be quite far from becoming popular.
Well… there were many reasons for that and I won’t extend too much on it as it’s not the purpose.
The point here is that jQuery used to make the developer’s life quite easy, but many people were using it without a proper context. They were just learning Javascript through that library.
One of the main reasons why jQuery became popular is simply because, besides easy, it was also providing cross-browser support especially when we had to care about Internet Explorer (make no mistake… I’m not talking about IE10 or IE11… I’m talking about IE5.5 and maybe even earlier versions… who remembers quirks mode?🤬 )
The code structure used to be quite straightforward as well. It was common to have a folder for storing all the CSS files and another one for all JS files. And there were some basic performance tips like importing CSS at the top and JS at the bottom of the HTML files. Some other techniques like CSS sprites were also popular, and these were all best practices that became super common when Steve Souders released the book High Performance Websites.
Improvements
Well… one of the good things in the frontend world is that it evolves super fast. Over the years, many frameworks and libraries appeared to solve different problems that big companies had, and over time they started to become more popular (some just because we love the hype, but some because they are really good).
For example, one of the biggest problems we have in Javascript is DOM manipulation, because it causes lots of unnecessary calculations in the browser. This can imply performance costs for the end-user.
Let’s have a simple example:
Imagine that you have a list than contains 5 items. If you remove the first item, most JavaScript frameworks would rebuild the entire list. That is 5 times more work than necessary.
ReactJS solves this problem with something called virtual DOM, which instead of updating the entire list, will focus only on the updated content, avoiding a huge DOM manipulation being more effective. This is a big advantage of using it.
Now, remember that I mentioned I’d talk about SEO? That’s the moment! If you work in a web product that is not an internal tool, SEO is crucial. You need to compete with others and you want your website to be listed in the first search results on Google.
If your competitors are using technologies that help them perform better, you have to adapt yourself to also be competitive. Now, my dear friend, building animations might not be as easy as it was with jQuery, and in the end, because ranking better on Google is a strong argument, you end up sacrificing time you’d spend building some nice animations, to dedicate to building a nice web performant product, as page speed is critical. And there’s more. Google actually evaluates many metrics based on Google web vitals, so now, besides speed, you found out you actually need to also care about the largest content that is rendered on the page and ensure that the most important one is actually rendered as expected. You also found out that you have to make sure that there’s no content layout shifting on the page, to ensure a better UX. Well.. the list goes on, and we’re just talking about one topic using a very very simple example.
The list is big and can look endless:
- We need to understand the tools we use (e.g.: bundlers like Webpack, fully customizable that allow us to analyze and optimize the bundle size of our JS code)
- Image optimization techniques
- Tree shaking
- build techniques
- etc.
This is all performance-related, and the good thing is that there are frameworks like Next.JS that try to abstract most of this work for us so that we don’t need to remember all of it.
We also have to:
- Compose the application in components for better reusability
- Track user navigation (data is gold and mapping all the user interactions is super important to increase conversion)
- Handle translations and number formatting (i18n and l10n)
- Write unit tests and integration tests
- Customize stuff because our requirements are not matching with what the framework we’re using supports.
- Handle different breakpoints (responsive behavior)
- Code transpilation (because even if we avoid supporting IE, you found out while tracking your users that some of them are using IE 😬)
- Build Animations 🤓
- Update the libraries we introduced to avoid reinventing the wheel
- Care about security
- Care about Accessibility
- etc.
Well… Nowadays it’s so common to spend months without touching CSS* files that we even miss this meme:
It’s shocking, I know, right? 😱
Well… welcome to frontend development in 2022 😅!
Conclusion
If you came to this point and still agree with the title, I propose you build a form in pure HTML, CSS and Javascript, and do the same form using a Javascript framework or library(and why not typescript 😉), making both of them high performing, and then compare all the boilerplate code necessary to do one vs the other (and hey, don’t cheat… don’t use CLI tools). I’m pretty sure you’ll see how things have changed. For the comparison, you can use Lighthouse (It's a tool available in the Chrome dev tools).
Many devs I know say that the problem in the FE is that it’s always changing too fast.
Well… Like everything in life, it has its ups and downs… IMO, this fast evolution is beneficial, especially for the end-user, who should benefit from faster navigation and, hopefully, better UX… and for us… well… you know that “book”:
In the end, we don’t just refactor because we love it. Sometimes it’s what we need to do so that we are able to provide the best user experience to our customers and rank better than our competitors.
My goal with this article is to help everyone to expand their minds and get to know some of the many responsibilities that Frontend engineers have to care about.
So, what do you think? What other old frontend optimization techniques did you use? What other things do frontend engineers have to care about that I forgot to mention? Do you remember some?
