Becoming a Great Web Front-end Developer

This article contains advice written for web developers by two engineers, one recommending useful tools and techniques while the other providing suggestions on addressing some of the challenges faced writing for the browser.

Rebecca Murphey, a Software Engineer at Bazaarvoice, wrote earlier this year the blog post A Baseline for Front-End [JS] Developers: 2015, providing advice for JavaScript developers on what tools and approaches to use for client-side web development. In summary, she said:

Learn ECMAScript 2015, recommending several resources: Understanding ES6, ES6 Rocks, and BabelJS. We add to this list the new book Exploring ES6 by Axel Rauschmayer. Considering that it is not a “must” to know everything about ECMAScript 2015 today, Murphey recommends to know in depth how to use asynchronous calls, callbacks and promises.

Use modules. Murphey believes that “there’s no debate that modules should be the building blocks of client-side web applications.” She had been using webpack lately, but she was looking at the day when everybody will use standard ECMAScript modules.

Test the code. It is important to add tests to code and to write testable code, according to Murphey. Although she finds Intern “particularly pleasing”, she has been using Mocha, mostly perhaps out of habit. On this topic, she also recommends Michael Feathers’ book, Working Effectively with Legacy Code.

Automate the process. Having used Grunt and Gulp in the past, Murphey has ended up using Yeoman which “really shines” when “starting projects from scratch using unfamiliar tech” and when standardizing the development of third-party JavaScript applications. She also mentions Broccoli, which might replace Grunt and Yeoman in the future.

Write quality code. She recommends refactoring code that “violates a project’s well-documented style guide” and using linter tools such as JSCS and ESLint.

Use Git. Use Git with feature branches in order to build on the “work of others, squashing commits using interactive rebase, and doing work in small units that are unlikely to cause conflicts whenever possible,” and run pre-push and pre-commit hooks with ghooks.

Generate HTML on the server. For performance reasons, for larger projects Murphey recommends generating the HTML on the server possibly “pre-generating it, and storing it as static files that can be served quickly – and then ‘hydrating’ that HTML client-side, updating it with client-side templates as events warrant.”

Embrace Node. Murphey advises web developers to be knowledgeable about Node.js, to know at least how to initialize a Node project, how to setup an Express server, and how to use the request module to proxy requests.

In his recent blog post How to Become a Great Front-End Engineer, Philip Walton, a Software Engineer at Google, takes a different approach: he does not advise on tools and frameworks, but rather how to deal with some of the challenges found in this field. He considers that what “separates the good people from the really good people isn’t what they know; it’s how they think.” His words of wisdom are:

Figure out what is going on. Writing some code that works is not good enough for Walton. He met too many people who play with CSS and JavaScript until they “find something that works, and then they just move on.” There are times when a piece of code works, but the developer doesn’t know why. Walton recommends going deeper:

Taking the time to figure out why your hack works may seem costly now, but I promise it’ll save you time in the future. Having a fuller understanding of the systems you’re working within will mean less guess-and-check work going forward.

Anticipate changes in the browser landscape. Web developers should constantly watch out for browser changes which can break existing code. The following line of code has created malfunction of a JavaScript framework when IE10 came out:

var isIE6 = !isIE7 && !isIE8 && !isIE9;

Read the specifications. While reading specifications may be an arduous task, Walton points out that it is necessary when browsers render a page differently, providing the following example:

A timely example of this is the default minimum size of flex items. According to the spec, the initial min-width and min-height value for flex items is auto (rather than 0), which means by default they shouldn’t shrink to smaller than the minimum size of their content. For the past 8 months, Firefox was the only browser to implement this correctly.

If you encountered this cross-browser incompatibility and noticed that your site rendered the same in Chrome, IE, Opera, and Safari, but looked different in Firefox, you’d probably assume Firefox had it wrong. In fact, I’ve witnessed this happen a lot. Many of the issues reported on my Flexbugs project were actually due to this incompatibility, and the workarounds proposed, if implemented, would have failed two weeks ago when Chrome 44 came out. Instead of these workarounds following the spec, they were unknowingly penalizing good behavior.

Review code. There is a lot to learn from reading other people’s code, opening one’s mind to “new ways of doing things,” according to Walton. It also helps working in a team. Actually, this is quite necessary because “most of your time as an engineer is spent adding to or changing an existing codebase,” not writing new code from scratch.

Work with smarter people. Walton “strongly” recommends at least for the beginning of one’s career to work in a team, in order to learn from more experienced people and have the code reviewed. If one still chooses a freelance career later on, he suggests contributing to open source projects to get the benefits of working in a team.

Reinvent the wheel. While agreeing that “reinventing the wheel is bad for business”, Walton believes it is great for learning. Not all the time, but in some cases, instead of using third party code he recommends writing your own code because there is a lot to learn in the process.

Write on lessons learned. The last piece of advice from Walton is about putting in words some of the lessons learned along the way: “In my experience, writing, giving talks, and creating demos has been one of the best ways to force myself to dive in and fully understand something, inside and out. Even if no one ever reads what you write, the process of doing it is more than worth it.”