How do you solve a problem like front end developer

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

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

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

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

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

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

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

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?

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

We’ve got so much ground to cover

https://twitter.com/slicknet/status/555040076078391297

People are recognizing, there is a gulf between those who focus on JS or on CSS, and others are now wondering, what the hell should they call themselves?

rmurphey.com/blog/2015/03/23/a-baseline-for-front-end-developers-2015/

Maybe we do start having different, more specific titles? Would that solve things?

https://twitter.com/hereinthehive/status/481509193774792705

Maybe we’re going extinct altogether?

https://twitter.com/trek/status/582551543871836160

I don’t think it’s quite so bad, so while things might not be as clear as we’d like, I think if we take a step back things start making a little more sense

https://twitter.com/monsika/status/503995369492316161

FED ain’t deadAt least not yet!

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

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

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

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

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

We hoped the FED team would be seen from this perspective

Instead, reactions were a little more skeptical

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

• 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

• 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/

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

We started with the basics like whitespace

Slowly becoming more specific, looking at naming conventions

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.

In the same way we built a JS styleguide

And so, another round of discussions

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

…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

• 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

A toolkit for all• a way to pool our efforts • share code and answers to common

problems • a starting point for new projects

Toolkit Features• Responsive workflow • Performance considerations • Accessibility considerations • Shared Components (you know, some HTML,

CSS, and JS)

Responsive workflows• our default breakpoints as Sass variables

(overridable as needed)

Responsive workflows• our default breakpoints as variables

(overridable as needed) • shared helpers (to show/hide content at

breakpoints)

Responsive workflows• our default breakpoints as variables

(overridable as needed) • shared helpers (to show/hide content at

breakpoints) • shared mixins to apply media queries

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

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!

#RWD✓

Performance• image_optim as a pre-commit hook

• github.com/toy/image_optim • ~20% size savings, whole seconds off page loads

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

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

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

#perfmatters✓

Accessibility• colour contrast audits in a single place

Accessibility• colour contrast audits in a single place • JS helpers for common a11y fixes

• eg keycodes & focus handlers

Accessibility• colour contrast audits in a single place • JS helpers for common a11y fixes

• eg keycodes & focus handlers

• common form helpers

#a11y✓

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

#FED✓

Toolkit• responsive design, performance,

accessibility, and shared UI modules • documented • a work in progress available for all

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

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

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

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.

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

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

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.

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

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

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

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

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.

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

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

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/

Thanks! Questions?@monsika