I love to reminisce about the internet in the early 2000s. It was around that time that I wrote my first line of code on a scrappy website builder to profess my allegiance to my favorite musical act – an origin so many people, especially women, femmes, and queer folks, have in our industry.
Just like this early iteration of the internet, front-end web development started off with few rules. Since then it has evolved into a complex ecosystem, built upon the social currency of our industry.
When there were no labels
Back in the early 2000s, “webmaster” was the coined term – though I preferred the moniker “webmistress”! I was a starry-eyed internet tween who would find excuses to skip recess to play around on the school library computer. At that time, we weren’t brand or thought leaders with name recognition, but rather aliases defined by niche hobbies.
It was the Wild West of writing HTML, CSS, and JavaScript. Knowledge was limited and community learning along with thought leadership was self-directed. The “what you see is what you get” editor ruled them all. You wrote a line of code, uploaded your files, and refreshed the page – all while your landline phone lost its mind.
In those days, right-clicking and viewing source was the Stack Overflow of understanding what was going on. Best practices included copy-pasting and saving your money to buy laminated cheat sheets. There were tutorial sites that listed out useful code snippets for common things you wanted to do, for example, embed MIDI files or render a sparkly marquee. *Plays the MIDI file for Steal My Sunshine by (Toronto icons) LEN.*
As a teenager, I made WordPress and static websites for local businesses, and in the early 2010s, started working in the tech industry. The terms “frontend” or “backend” weren’t in job titles, they were in labels in architectural diagrams written in unified modeling language (UML). And when you did front-end work, you were boxed into the web designer or a UI/UX developer box. You were restricted to writing visual code and, oftentimes, took on designer duties.
The rise of the frontend and backend binary
Throughout the 2010s, websites rapidly evolved into dynamic and robust web applications. The buzziest term that trickled down was model view controller (MVC) – this was when Ruby on Rails shined brighter than a diamond. Web applications were multi-page apps that required servers running in the background to render pages and a sitemap of routers for RESTful endpoints. They were monolithic and, as the years went by, needed more layers to be able to scale.
In the early 2010s, “frontend” and “backend” entered our developer vernacular. Back-end developers worked in the model. In most of these MVC frameworks, the controller was written in back-end languages like Ruby, Java, and Python. Engineers who primarily worked at the controller level could comfortably make changes in the backend, whilst frontend were full-stack developers, working in the view.
The view was no longer just for rendering. It was needed for fetching server-side data asynchronously and facilitating an understanding of object-oriented programming (OOP) principles to make decisions that kept error handling, performance, and client-side data storage in mind. These were all things that were previously seen as back-end work.
People became more defensive and overly assertive about their areas of expertise. Being a full-stack developer made you the most hireable and respected. Discussions about being a generalist and specialist were abuzz. You were either one or the other, and there was no room for anything in-between.
Societal impact
Our work, though rooted in decades of computer science and software engineering research, can take on a life of its own. Wider societal dynamics affect this reality, influencing how we assign and assume areas of expertise in people.
Femmes and women are widely presumed to be “just” front-end developers. Back-end work is seen as more “technical”, hard, or masculine. Of course, this is not true. As engineers, all the work we do is inherently technical. Nevertheless, I’ve encountered women who distance themselves from front-end work because of the associated preconceptions.
As with anything, there are double standards as well. Most of the well-respected front-end thought leaders are cis white men – though the same could be said for back-end developers, and indeed realms outside of writing code. No surprises, people who are part of underrepresented or marginalized groups in our industry get the short end of the stick in this game of perception.
Recognizing the fluidity of it all
In today’s world, perception bias around front-end, back-end, or full-stack developers hasn’t changed much.
What has changed is the seemingly endlessly expansive landscape of front-end development. Now, the architecture of web applications is largely constructed by microservices. The legacy monoliths that weren’t reorganized as such have become distributed monoliths, which essentially have a microservice-like architecture that is tightly coupled to a monolith.
Front-end engineering is no longer just product engineering. Building a page in mostly single-page web applications requires a web platform or infrastructure team with deep expertise. And within front-end infrastructure, there’s so much to work on.
Some examples include:
- Documenting and evangelizing best practices
- Developer tooling, observability, and monitoring
- Strong partnerships with engineering experience teams such as application programming interface (API), site reliability engineering (SRE), and design systems
- Building continuous integration (CI) pipelines for various server environments, middleware upkeep, and manual and automated testing infrastructure
- Prioritizing performance metrics in client-side and server-side rendering, and Image and CSS asset management
- Third-party, open-source dependency management
- On-call and incident reporting and management
Native mobile and mobile web experiences often go neglected. In the 2010s, when cross-platform mobile application frameworks like Apache Cordova (formerly PhoneGap) and Adobe Flex were phasing out in favor of prioritizing native mobile development, I never anticipated a cross-platform comeback today in the form of React Native. For many engineering organizations, their front-end infrastructure extends to supporting native mobile.
So much of corporate open source and developer advocate work is maintaining front-end frameworks. Some of the biggest open-source projects include freeCodeCamp (where front-end development learning resources dominate), React Native, and DefinitelyTyped (a library of type definitions for TypeScript).
Being able to implement wireframes is no longer enough to sustain a successful product engineering team. Although product engineers are not required to be infrastructure experts, in order to deliver usable, accessible, performant, and data-driven (through experimentation) experiences, knowledge of front-end engineering fundamentals is paramount.
How can we be ourselves in our knowledge?
With all this history in the books, how do we keep up? Sometimes, it can feel like the goalpost is constantly moving. It often seems as if being a front-end developer is more about winning the résumé buzzword bingo than anything else. The truth is, you’ll never know everything, and honestly, what a relief! However, we can be strategic when choosing to go deep and when we opt to delegate to our teams.
Things to think about as individuals
What do you genuinely want to work on? Where do you want to be challenged? Identify the things you don’t know and, for each point, list at least one reason you should be learning about it.
Is your current team setting you up for success? Remember, it’s important to communicate and develop your goals and expectations with your manager. Beyond them, make sure to have both people in and outside your team who are willing to sponsor you.
Are you able to set aside time during work hours to simply learn? Leverage your organization’s educational resources and stipends to brush up on front-end engineering fundamentals.
You don’t have to choose between doing product or infrastructure engineering if you don’t want to, the same applies for doing front-end or back-end work. But doing one or the other, or both, doesn’t make you more “technical”. There will be multiple points in your career, you’ll inevitably have to diversify your skills in order to deliver work, so it’s always beneficial to think about how your current efforts can be strengthened.
Besides courses or training, a good way to learn fundamentals is to read direct documentation. By way of example, reading the documentation for the React rendering lifecycle will serve as a foundation to learn more complex features of the framework. And if you find you don’t understand everything, that’s okay. Ask for help!
On the path to broadening your knowledge base, it can be helpful to go back to basics. Make sure your knowledge of core fundamentals is sound; do you know how the browser works and how the document object model (DOM) serves resources to a page and when that happens for each resource? Can you roughly translate the framework’s version of writing JavaScript to what is actually happening under the hood and leverage developer and browser tools? Be familiar with the World Wide Web Consortium (W3C) standards, especially in terms of accessibility when writing proper HTML and CSS.
Things to think about as teams
A single front-end infrastructure team cannot sustainably address all the needs of the system. In my experience, having sub-teams for each main priority, working in constant alignment, will be more effective and long-lasting.
On a product team, it’s valuable to have a good mix of engineers who are product- and infrastructure-focused. Learning works both ways, so develop a strong partnership with your infrastructure and design systems teams.
Language matters, and we need to challenge ourselves to describe people’s skills beyond the front-end, back-end, or full-stack labels. Go into specifics of where they add value. Are they experts in CSS animations, for instance? Identify and hold yourself accountable for any biases that affect people who benefit the most from diversity, equity, and inclusion.
Engineers who expand front-end knowledge beyond code through documentation, better project management practices, and thought leadership should be supported and rewarded for that impactful work. This is technical labor, not just glue work.
Things to think about as organizations
We need to invest in the long-term sustainability of front-end infrastructure teams. Employee attrition is common, so we can’t restrict valuable knowledge to specific individuals and perpetuate a hero-worship culture around them.
We need to be bringing folks of all backgrounds into this work with opportunities for advancement, especially entry and mid-level engineers. Even though most infrastructure teams do not have product managers, designers, quality assurance (QA) engineers, or data scientists, that shouldn’t stop you from factoring in the expertise of those disciplines when your decision-making.
There’s also a need to invest in knowledge development for your product engineers. I’ve spent time at many places where working on infrastructure teams is seen as the only way to get to staff+ levels. There should be room for engineering growth as a product engineer, and that shouldn’t mean having to be tech lead on every project.
Final thoughts
Approaching engineering as a craft that needs to be cultivated will ultimately help to build better products and reduce technical debt in front-end development.
In difficult times, such as a recession, where there are limited resources and huge pressures to meet the bottom line, we need to communicate our expectations clearly through the management chain. Front-end teams are just as important in keeping our systems afloat as back-end or full-stack teams.
Our hiring process for front-end developers should also account for everything I’ve recommended on individual, team, and organizational levels. To get the best candidates, the cultural and technical questions we ask have to go deeper than trivia. So hire someone who can comfortably ride the ever-changing waves of the frontend!
Please also check out my LeadDev talk Navigating front-end architecture like a Neopian!
