Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How do you solve a problem like front end developer

5,022 views

Published on

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.

Published in: Technology
  • Be the first to comment

How do you solve a problem like front end developer

  1. 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. 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. 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. 4. At the dawn of the internet, it was a simpler time, and there was but one webmaster to rule them all
  5. 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. 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. 7. When all of a sudden this simple list of 3 turned into a much longer list as languages and capabilities matured
  8. 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. 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. 10. We’ve got so much ground to cover https://twitter.com/slicknet/ status/555040076078391297
  11. 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. 12. Maybe we do start having different, more specific titles? Would that solve things? https://twitter.com/hereinthehive/status/ 481509193774792705
  13. 13. Maybe we’re going extinct altogether? https://twitter.com/trek/status/ 582551543871836160
  14. 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. 15. FED ain’t dead At least not yet!
  16. 16. UI can suffer if there’s no one minding it specifically
  17. 17. 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
  18. 18. and your users pay the price because you can’t push features and fixes out fast enough
  19. 19. 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
  20. 20. 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
  21. 21. We hoped the FED team would be seen from this perspective
  22. 22. Instead, reactions were a little more skeptical
  23. 23. 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
  24. 24. • 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
  25. 25. • 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/
  26. 26. Trust me, there will be discussion! People can be passionate about whitespace and whether or not you should alphabetize your CSS rules!
  27. 27. We started with the basics like whitespace
  28. 28. Slowly becoming more specific, looking at naming conventions
  29. 29. 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.
  30. 30. In the same way we built a JS styleguide
  31. 31. And so, another round of discussions
  32. 32. Code Reviews… • support your guide • if hard to enforce, it might not be useful • help grow your guide
  33. 33. …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
  34. 34. • 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
  35. 35. A toolkit for all • a way to pool our efforts • share code and answers to common problems • a starting point for new projects
  36. 36. Toolkit Features • Responsive workflow • Performance considerations • Accessibility considerations • Shared Components (you know, some HTML, CSS, and JS)
  37. 37. Responsive workflows • our default breakpoints as Sass variables (overridable as needed)
  38. 38. Responsive workflows • our default breakpoints as variables (overridable as needed) • shared helpers (to show/hide content at breakpoints)
  39. 39. Responsive workflows • our default breakpoints as variables (overridable as needed) • shared helpers (to show/hide content at breakpoints) • shared mixins to apply media queries
  40. 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 • JS for responsive images, resize events, etc
  41. 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 • a mobile lab too!
  42. 42. #RWD✓
  43. 43. Performance • image_optim as a pre-commit hook • github.com/toy/image_optim • ~20% size savings, whole seconds off page loads
  44. 44. 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
  45. 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 • FastClick JS across projects • github.com/ftlabs/fastclick
  46. 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 • shared perf documentation
  47. 47. #perfmatters ✓
  48. 48. Accessibility • colour contrast audits in a single place
  49. 49. Accessibility • colour contrast audits in a single place • JS helpers for common a11y fixes • eg keycodes & focus handlers
  50. 50. Accessibility • colour contrast audits in a single place • JS helpers for common a11y fixes • eg keycodes & focus handlers • common form helpers
  51. 51. #a11y✓
  52. 52. some HTML, CSS, & JS • documented, re-usable common modules
  53. 53. #FED✓
  54. 54. Toolkit • responsive design, performance, accessibility, and shared UI modules • documented • a work in progress available for all
  55. 55. Other stuff • FED talks • Design/FED process • FED/App Dev process
  56. 56. FED Talks • talk about standards • talk about common problems • share work from in and out of day-to-day
  57. 57. 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
  58. 58. 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.
  59. 59. 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
  60. 60. Rules and standards enable our team to work more closely with other disciplines and gives us the freedom to keep innovating.
  61. 61. 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.
  62. 62. So what is “FED” then? •And how does this relate to YOU?
  63. 63. 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
  64. 64. An alternative approach would create silos, difficulty filling roles, and what happens in 6 months when new specialties are needed?
  65. 65. 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
  66. 66. 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.
  67. 67. 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
  68. 68. Back to FED • beyond just some HTML, CSS, and JS • depends on what you do with it!
  69. 69. 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/
  70. 70. Thanks! Questions? @monsika

×