Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Becoming a Great Web Front-end Developer

Becoming a Great Web Front-end Developer

Leia em Português

This item in japanese


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.”

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Front-end != web

    by Dev eloper,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There are a lot of other platforms, where people don't have to deal with the mess of JS and HTML.

  • test code

    by Beren Erchamion,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hmmm...most of this seems kinda obvious, no? Test code? Write quality code?

  • Philip Walton nailed it

    by Richard Richter,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Often I hear "it's kinda obvious", but more often I see it isn't. Yeah, it was mentioned often too, but it doesn't seem obvious to me when people don't do it. On average, people read too little about their craft (or average people? :-)), they leave the topic at the moment it works and try to figure out the same problem week later again and again. Even people who are not under constant pressure and can get better and more effective for tomorrow... they just don't do it - at least not systematically, maybe just incidentially. Finally, I concur that writing (presenting in any way) about the problem helps it even more. It actaully forces to dig deeper if you really want to write something meaningful.
    The second part of the article was related to the whole business, not just the front-end (actually maybe to many other crafts too :-)).

  • Re: Philip Walton nailed it

    by Mark N,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yeah. It is sad. But ... we have to say it again and again. And again. It usually is mostly needed in "web UIs" arena because it is so easy to get started without tools and so many people just start coding.

    What kills me is how unimportant most people - customers, management, any non-developers in IT, many developers, etc - don't see that any of this is needed. They only care if the customer is "happy". "If it does not blow up in production and the user does not complain, it is good". What they never see is that it is a "pay now or pay tons more later" situation. Of course you had better not violate their rules (i.e. ITIL and PMO).

  • Re: Philip Walton nailed it

    by Mark N,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    OK. Somehow this got linked to a diff post. HMMM

  • Who the hell calls JavaScript ECMAscript?

    by Rebecca Berry,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, I know that is what it's officially called, but I've never heard that name actually used in any context other than referring to the fact that it's the languages real name.
    Anywho to get back on topic, it's good to push yourself and test your skills with coding tests, check out the ones from TestDome:
    Good luck!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p