It's 2015 and as a discipline, front end development (FED) has recently seen enormous growth as new design patterns, build tools, and libraries and frameworks emerge and mature. Given this wide range of topics, FED can start meaning different things to different people, and it can be easy to lose track of what exactly a “front end developer” does on any given team and why it's important. At Shopify, we’ve been exploring the role more closely as our FED team continues to grow. In this talk, I will share my perspective on front end development and discuss how by investing in shared tools like design standards, processes, and style guides, we’ve been able to find common focus for our team and a stronger understanding of our role across disciplines. “Front end developer” can be an ambiguous title - here’s one team’s approach to finding some clarity.

1. How do you solve a problem like “front end developer”?
I don’t think front end developers are a problem, but our scope of work can be a little hard to
pin down

2. I’ve been calling myself a front end developer for the past 7 years, and I’ve always assumed people just kind of got
what that meant.
FED is recognized in job postings, job titles, learning material, but a lot of people write HTML, CSS, and JS and
might not call themselves FEDs, or two front end developers might have very different interests and skill sets
despite sharing the same title

3. Today, I’ll share my perspective after building a FED
team for the past year, on what front end dev can mean
from a practical point of view.
We build specific types of applications so much of this
might be specific to my team, but I hope this will
continue the discussion and leave you with some insight
on how you think about your day to day

4. At the dawn of the internet, it was a simpler time, and there was but one webmaster to rule
them all

5. Since then things have changed, and nowadays, there’s a common split between between
design, the “back end”, server-side code for your application logic, and the “front end”,
browser code

6. This definition of the “front end”, the HTML, CSS, JS portion of your app I think served us well
served us well until very recently

7. When all of a sudden this simple list of 3 turned into a much longer list as languages and
capabilities matured

8. Maybe the definition of FED as “HTML, CSS, and JavaScript” is too
wide.
e.g. you can write JS on a server now using Node, and that’s
definitely not front end.
So maybe it’s just whatever runs in the browser. But looking at
heavy JavaScript apps, they tackle the types of concerns usually
handled by application developers on the server.
So, it’s not just the browser, maybe only the UI part then? Where
does that leave tooling like Grunt? It’s not part of the UI, but helps
build out parts of the UI like CSS, and what about all the other
things that would affect presentation, like performance, caching
and offline storage?

9. I don’t think I’ve said anything particularly new so far, I’ve
been seeing more and more discussion about this kind of
stuff on Twitter among well respected people in the
industry
https://twitter.com/
ryanflorence/status/
569983054728425473

10. We’ve got so much ground to cover
https://twitter.com/slicknet/
status/555040076078391297

11. People are recognizing, there is a gulf between those who focus on JS or on CSS, an
are now wondering, what the hell should they call themselves?
rmurphey.com/blog/2015/03/23/a-baseline-
for-front-end-developers-2015/

12. Maybe we do start having different, more specific titles? Would that solve things?
https://twitter.com/hereinthehive/status/
481509193774792705

13. Maybe we’re going extinct altogether?
https://twitter.com/trek/status/
582551543871836160

14. I don’t think it’s quite so bad, so while things might not be as clear as w
take a step back things start making a little more sense
https://twitter.com/monsika/status/
503995369492316161

15. FED ain’t dead
At least not yet!

16. UI can suffer if there’s no one minding it specifically

18. It’s easy to create technical debt when the HTML, CSS, and JS side of things aren’t taken
seriously. This can create a lot of spaghetti code that’s very hard to maintain

19. and your users pay the price because you can’t push features and fixes out fast enough

20. A “front end developer” with a broad HTML, CSS, JS scope can mind the UI and
help make sure it’s set to the same high standards as design and application
development.
In this way, FED can help solve UX problems with designers and take an engineering
approach to the implementation, the best of both worlds

21. This is the approach we’ve taken, keeping a broad definition of FED as a first
class citizen among design and app development our
focus is the building and supporting UI layer our users interact with m

22. We hoped the FED team would be seen from this perspective

23. Instead, reactions were a little more skeptical

24. So we realized we’d have to do a little more than just show up and we created styleguides,
toolkits, and a way to share knowledge within and outside our team

25. • shared coding standards
• consistency is key
• helps team members read each other’s code
• helps you read your own code 6 months
from now
Language Styleguides

26. • borrow!
• throw something into a shared doc
• fight it out
Starting Out
• http://cssguidelin.es/
• http://sass-guidelin.es/
• https://github.com/rwaldron/idiomatic.js/

27. Trust me, there will be discussion! People can be passionate about whitespace and whether or
not you should alphabetize your CSS rules!

28. We started with the basics like whitespace

29. Slowly becoming more specific, looking at naming conventions

30. Finally, moving towards architectural approaches.
By documenting these, people accidentally learned a little bit about CSS architecture by having
to learn about our naming conventions, free new knowledge for the team.

31. In the same way we built a JS styleguide

32. And so, another round of discussions

33. Code Reviews…
• support your guide
• if hard to enforce, it might not be useful
• help grow your guide

34. …can also be automated!
• scss lint - github.com/brigade/scss-lint
• jshint - jshint.com
• jscsc - github.com/jscs-dev/node-jscs
• Sublime Linter - www.sublimelinter.com

35. • understand the logic
• more questions, less judgement
• collect common questions and use cases
• “Anyone know of any good plugins for…?
• “Hey FYI I built this re-usable module in case you
need it”
• “How did you deal with this similar situation?”
Reviews beyond syntax

36. A toolkit for all
• a way to pool our efforts
• share code and answers to common
problems
• a starting point for new projects

37. Toolkit Features
• Responsive workflow
• Performance considerations
• Accessibility considerations
• Shared Components (you know, some HTML,
CSS, and JS)

38. Responsive workflows
• our default breakpoints as Sass variables
(overridable as needed)

39. Responsive workflows
• our default breakpoints as variables
(overridable as needed)
• shared helpers (to show/hide content at
breakpoints)

40. Responsive workflows
• our default breakpoints as variables
(overridable as needed)
• shared helpers (to show/hide content at
breakpoints)
• shared mixins to apply media queries

41. Responsive workflows
• our default breakpoints as variables
(overridable as needed)
• shared helpers (to show/hide content at
breakpoints)
• shared mixins to apply media queries
• JS for responsive images, resize events, etc

42. Responsive workflows
• our default breakpoints as variables
(overridable as needed)
• shared helpers (to show/hide content at
breakpoints)
• shared mixins to apply media queries
• JS for responsive images, resize events, etc
• a mobile lab too!

43. #RWD✓

44. Performance
• image_optim as a pre-commit hook
• github.com/toy/image_optim
• ~20% size savings, whole seconds off page loads

45. Performance
• image_optim as a pre-commit hook
• github.com/toy/image_optim
• ~20% size savings, whole seconds off page loads
• shared SVG icon workflow

46. Performance
• image_optim as a pre-commit hook
• github.com/toy/image_optim
• ~20% size savings, whole seconds off page loads
• shared SVG icon workflow
• FastClick JS across projects
• github.com/ftlabs/fastclick

47. Performance
• image_optim as a pre-commit hook
• github.com/toy/image_optim
• ~20% size savings, whole seconds off page loads
• shared SVG icon workflow
• FastClick JS across projects
• github.com/ftlabs/fastclick
• shared perf documentation

48. #perfmatters
✓

49. Accessibility
• colour contrast audits in a single place

50. Accessibility
• colour contrast audits in a single place
• JS helpers for common a11y fixes
• eg keycodes & focus handlers

51. Accessibility
• colour contrast audits in a single place
• JS helpers for common a11y fixes
• eg keycodes & focus handlers
• common form helpers

53. #a11y✓

54. some HTML, CSS, & JS
• documented, re-usable common modules

55. #FED✓

56. Toolkit
• responsive design, performance,
accessibility, and shared UI modules
• documented
• a work in progress available for all

57. Other stuff
• FED talks
• Design/FED process
• FED/App Dev process

58. FED Talks
• talk about standards
• talk about common problems
• share work from in and out of day-to-day

59. FED works closely with design. Both teams help balance design and implementation details,
making common UI modules possible. Those building blocks are only as good as how closely
FED & Design work together to define them

60. FED also works closely with application developers. Sometimes your backend can help solve
presentational issue that FED is focused on solving. Both teams compromise and FED can be a
sophisticated part of your software.

61. With our broad approach to front end dev, through language styleguides, code
reviews, weekly meetings and with the support of other teams, we’ve been able
to build a very strong foundation

62. Rules and standards enable our team to work more closely with other disciplines and gives us
the freedom to keep innovating.

63. It’s this core, maintained by rules and standards thats gives us the freedom to keep
innovating and build better and better user experience.
Everyone is confident in our front end, it’s not a pile of spaghetti HTML, CSS, and JS.
It’s an integral part of the great user experience all disciplines are working together to build.

64. So what is “FED” then?
•And how does this relate to YOU?

65. FED IS broad -
• Comfortable in all thee of HTML, CSS, and Javascript
• Looking at these from the perspective needed
• e.g. performance, accessibility, design requirements, back end requirements.
• Has a bird’s eye view of UI, that’s how your users will experience it too.
• All of those individual pieces from the start come together to create that interface, and FED
helps make sure they come together seamlessly

66. An alternative approach would create silos, difficulty filling roles, and what happens in 6
months when new specialties are needed?

67. This doesn’t mean you you need to be an expert in all things Front End to be able to write
any CSS, JavaScript, or HTML

68. It’s great to specialize, but HTML, CSS, and JavaScript work together so it’s good to know at
least a little about all 3.

69. No matter what you call yourself, hopefully you love solving problems and that’s what we all
have in common no matter how we do it
https://twitter.com/gortok/status/
584026996168118272

70. Back to FED
• beyond just some HTML, CSS, and JS
• depends on what you do with it!

71. FED For Thought
• Great posts on being a front end generalist:
• http://www.nczonline.net/blog/2007/08/15/what-makes-a-
good-front-end-engineer/
• https://the-pastry-box-project.net/dan-donald/2014-july-2
• Tips on keeping up with Front End Development
• https://css-tricks.com/video-screencasts/125-how-to-stay-up-
to-date-with-web-technology/
• http://uptodate.frontendrescue.org/
• Learn from other teams
• http://styleguides.io/

72. Thanks! Questions?
@monsika