Part I. Origins
In the beginning was the Web, and the Web was good. Well, in this case, the beginning was the early 90s, and “good” meant a site had found its way onto the Yahoo! index page and the visitor counter was spinning at the bottom of the table-laden, animated GIF–infected page.
But that’s all you really needed in those days. As long as you were feeding your fellow webring subscribers with click-throughs, all of the webmasters were happy. And those webmasters? Yes, they were masters of their domain...literally! Websites were simple creatures, and the webmaster was their keeper, tending to the tangle of HTML and wondering if these new Cascading Style Sheets were something to be bothered with; most had already written off JavaScript as a passing fad.
But like any medium, the Web grew. JavaScript stuck around. CSS was useful for more than just setting the page’s font family and font color. Webmasters eventually found themselves at a crossroads. Their website traffic continued to grow, and the technologies of the Web continued to expand (transparent GIFs!). There were too many new things to keep track of, too much work to do; eventually webmasters were forced to specialize. On one hand, they really liked their “under construction” signs, and the ubiquitous marquee tags, but on the other hand Perl was the best language ever to be created and will undoubtedly power every website from here into eternity.
When it came to hiring a second person to help run their precious domains, webmasters needed to decide if they wanted to continue to be <blink> tag masters and hire Perl script kiddies, or the other way around.
Eventually these decisions had all been made, and the modern web team began to assemble like a news team called to a large seashell. At every stage, every crossroad, former webmasters found themselves needing to focus on a smaller chunk of the web process. Some of them focused on serving files over a server, while others improved their skills in accessing a database, while still others found joy in creating graphics and images.
Newer, more focused roles also attracted artists, writers, business analysts, engineers, and mathematicians to the industry. As these roles developed, and their members become more and more proficient, the Web began to form a new set of designations...or disciplines.
Those Who Strategize About Content
Early on in the development of the Web, there was a particular personality that believed the words on any given page were as important as the design, the code, or even the search engine optimization (everyone knew that keyword stuffing was the way to go). Before they came along, content had always been a problem to deal with later. “Just throw some lorem ipsum into the design and move on.” The client will eventually fill it in with real, quality, inspired content before the site goes live...really...always.
These lovers of words were ultimately quite vocal that the Web was content, and that this content deserved our time and attention. It was always a battle, but they began to be invited into early planning meetings, and on occasion asked to develop editorial strategy. They were making progress! The fight was difficult and lonely, but the results were worthwhile.
Thus went each of these lone warriors until the fateful day where they happened to come across another logophile, and they realized that they weren’t alone in this struggle! This kindling of a friendship quickly grew into a blaze of new connections. Eventually a community was formed, and they continued to focus their efforts on convincing others to treat content as a valuable asset.
Years passed and the fight for content was far from over. But even as one more designer was asked to “just make something up” for the homepage copy, a new rallying cry could be heard in the distance. December 16, 2008, was the day that Kristina Halvorson stood up high atop the “A List Apart” blog and raised a banner for content strategy. She asked us all to “take up the torch” and begin “treating content as a critical asset worthy of strategic planning and meaningful investment.” Those who practice content strategy were to “Learn it. Practice it. Promote it.” They were to become content strategists. And like that, a discipline was born.
Kristina’s article was not the first one to broach the topic of content strategy, but it was the first to define the heart, soul, and purpose of content strategy. Overnight, this group of word disciples had been given a name for their collective calling. These disciples would usher in an era of blogs, podcasts, and conferences revolving around the simple notion that “content mattered.”
A Responsive Web Was Born
Around the same time, a man in a black turtleneck got up on stage and utterly ruined everyone’s conception of what an Internet-connected device was. For the first time in the history of the Web, we were forced to accept that websites were not browsed solely on 1024 × 768 pixel screens in the comfort of our offices and living rooms with the fat pipes of broadband Internet. The introduction of the iPhone ushered in a new era of web-connected devices with a multitude of screen resolutions, varying capabilities, fluctuating connection speeds, and inconsistent input modes. As developers, we could no longer make assumptions about our user and the properties of the device they were using to view our websites.
In response, we tried a number of solutions. We tried relying on pinch and zoom, or double tap to zoom, leaving our sites mostly untouched, or we redirected any mobile device to a stripped-down, mobile-friendly “m.dot” website. Neither solution really solved the problem. Pinch and zoom sites were difficult to navigate in order to finalize purchases or sign up for services, and increasing mobile traffic meant increasing lost revenue. Although m.dot sites were more user friendly for mobile devices, they required development teams to maintain two separate websites.
Many m.dot sites languished, failing to be updated as frequently as their larger siblings, or the reduced feature set of the m.dot site forced users to switch to desktop devices to do anything more than get directions or place a phone call. Something needed to be done. Though some considered the iPhone a passing fad, it was soon quite obvious that the future of the Web lived inside of these small, personal screens.
On May 25, 2010, three years after the release of the iPhone, Ethan Marcotte penned a lengthy article on A List Apart called simply, “Responsive Web Design.” This article did not describe some new discipline, or a banner for embattled developers to gather under. Instead, it described a method for creating a new breed of website that would respond to the size of the user’s device and mold itself to that viewport. Responsive web design (RWD) was not some new or emerging technology, but rather a collection of existing tools and techniques, including the following:
- Fluid grids
- Percentage-based widths rather than fixed-pixel dimensions.
- Flexible images
- 100%-width images fill the container they are put inside of, and flex as the viewport changes size.
- Media queries
- Being able to specify different styles for different viewport sizes, we could now change page layout based on the size of the screen.
All of these techniques had been available in the browser for years before Ethan’s article, but just like Kristina’s call to arms for content strategy, his description of RWD clearly defined the solution everyone was desperately looking for.
In a single article, the web development industry had been transformed.
The Seeds of Frontend Architecture
It was with this history in mind that I started to think about the notion of frontend architecture. As a Drupal frontend developer, I knew full well the frustration that content strategists had felt. The frontend styling was always an afterthought. It was a layer of “pretty” applied to the default markup after the designers and backend developers had finished their work. The challenges we faced couldn’t have been better exemplified than in the order in which people were brought onto a project. I saw projects start, designs debated over, functionality developed...and then a frontend developer was pulled onto the project to apply whatever design was tossed over the wall to whatever markup our CMS chose to output.
Having gone through this process several times, I knew the pain I was going to experience as I tried to deconstruct a set of mobile and desktop Photoshop files. The goal was to form them into a theme that could be applied to the div soup that Drupal spit out. Speaking to Rails friends about the challenges of styling a website navigation, I eagerly confessed, “One does not simply change Drupal navigation markup,” and it was true! Once that markup was set, and the developer had moved on to another task, the chance of modifying the combination of divs, lists, and links was all but a dream. This inevitably led to some ridiculous CSS hacks to make a design that was never meant to fit the default navigation markup actually work in production.
For many years, frontend developers’ worth was measured by their ability to create these Frankenstein-style design patterns. “Now if I put a pseudo element on the third nested div, and use a background image from this sprite...” was our battle plan, and it was terrible. We were patching up holes in a failing levy, hoping that we could launch the site before we got swept away by waves of technical debt.
This process wouldn’t be sustainable as the complexity of our projects grew. So instead of doing things the way we’ve always done them (because they’ve always worked in the past), I began to imagine how a project would differ if we made frontend development “a critical asset worthy of strategic planning and meaningful investment.” What if we had a voice in things like CSS frameworks, documentation tools, build processes naming conventions, or even the markup itself?! I started to wonder what a large-scale project would look like if UX development fed backend development, instead of the other way around.
Would this create a revolution? Would others pick up the same torch and start to “Learn it. Practice it. Promote it.”? Before we could all rally under a single banner, we needed to understand what that banner stood for. What should we demand? How could we accomplish our goals? What might we be called?
What’s in A Name?
In backend development, where planning and scalability are key, software architects are highly valued. They are invited onto a project long before development begins, and they have discussions with clients about the architectural needs for their soon-to-be-built platforms. What technology stack are they going to use? What are their content types? How is content created, stored, and displayed back to the screen? The role of a software architect is to make sure that nothing is ever created by chance, but rather guided by an overarching architecture.
I realized that what frontend development was missing was architecture. We were being asked to do all our work piecemeal, as an afterthought. It didn’t take long for me to convert databases and web servers to Sass folder structures and build systems, and the title of frontend architect was born.
Now, every job title needs a job description. What would a frontend architect do? How would they impact a project given the proper opportunity? These ponderings led to a lightning talk about frontend architecture at my company’s annual retreat, and a speaking opportunity at CSS Dev Conf that led me to focus my thoughts into a concise 45-minute presentation.
On October 13, 2014, given to a packed room inside a New Orleans conference center, “Raising a Banner for Frontend Architecture” was a rallying cry for the developers who had already been on the front lines of this fight. I wanted them to know that they were not alone, and that there were others out there to support them and back them up. I spoke to project managers, salespeople, and developers alike, outlining the power of a properly architected frontend and the value that it brought to the team and to the client.
After the talk, I heard story after story of developers who finally understood who they were, and the role they played in their organization. Many people found themselves performing the role of frontend architect, but had never taken on that title, or felt confident enough to ask for the authority the position should carry. The weeks after CSS Dev Conf saw many people changing their Twitter bios to read “frontend architect.” And I, being one of those to make the change, haven’t looked back since. No matter the title I currently hold at my present job, I am a frontend architect.