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.
Beginners Guide to TikTok for Search - Rachel Pearson - We are Tilt __ Bright...
How do you solve a problem like front end developer
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
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
16. UI can suffer if there’s no one minding it specifically
17.
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
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!
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.
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)
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!
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/