Thoughts on a Baseline for Front-End Development

I read an interesting article on Hacker News about a baseline for front-end development . The article resonated with me as it dealt with an issue that had been on my mind, both as I reflected on my own career path and as I interacted with other designers and developers on the job.

If you are a web designer or developer, or you work with someone who is, I highly recommend you read the article.

To summarize, the article mentions the changing nature of frontend development, and recommends that frontend developers need to pickup some new skills or be left behind. These skills include:

  • Javascript programming
  • Git and Github
  • Modular programming
  • Package and dependency management
  • Build tools and environments
  • In-browser development tools
  • Command-line interface
  • Client-side templating
  • CSS preprocessors
  • Testing
  • Automation
  • Code quality

There was a lot of discussion surrounding these items on the conversation at Hacker News. A lof of the discussion was around whether or not the list was exhaustive and whether or not it applied to everyone. My take on both those questions is, "no".

But that line of discussion is not what should be at issue. We should be asking ourselves whether the profession of web design and development has changed such that frontend developers need to adopt some subset of these new practices and tools or perish for not doing so. My take on that is, "yes".

Mocking up websites in photoshop, coding static sites and Wordpress themes, and uploading the results via FTP just doesn't cut it anymore. I'm sure there are exceptions, but, web design and development has matured as profession.

Best practices exist, and with those practices come processes, such as automation, version control, testing, and code review. And since most projects are sufficient enough in scope to require a team to build them, everyone must adopt these processes for the team to be successfully. That includes the frontend developers and the backend developers. Even those not working in teams would benefit from these practices as it helps backup your work, produce quality results, and will help you play better with others when the time comes to work on a team project.

I think my logic and reasoning above is sound and it supports the adoption of many of the tools and techniques covered in the source article that I am discussing. Most teams will probably pick up these things organically anyway, without even thinking about it, as they strive to improve quality and productivity.

I want to leave you with one final thought. A programmer, a backend developer, and a user interface developer, all need to understand programming. That really goes without saying. But what I think a lot of people don't realize, is that a designer - even a designer that never touches code - does need to understand programming and the mechanics of how a server works and how a web page is delivered and rendered.

When I studied communications, I learned that the medium is the message. That is, the same message on a different medium, could be perceived differently. And when I worked in marketing I saw this first hand. I also noticed that the best designers embraced this.

Great print designers understood the printing process from the ground up, including fine details about different types of inks and papers. This knowledge influenced their designs as much as their designs influenced the final product. The type of ink, the type of paper, and the printing process were intentionally selected during the design process and they directly affected the design. They were not an afterthought. It was never a matter of, ""great it's done. Now how do I print it?".

I expect the same from designers whose medium is the web. They need to understand and respect how things work before they can make things better.