There is some sentiment out there that front end development isn’t real development. It’s a swaggering, trollish sentiment. Still, it’s fun to puff our chests back sometimes. Let’s try to put a point on why front end development is every bit as difficult and worthy of the title as any other subset.
This is a continuation of my post last week on how the expected skills of a front end developer are hard to nail down and how different we all can be. That post struck a chord with a good chunk of readers, and the comments that came in were full of interesting stories and experiences about what front end development means in both the technical and personal sense.
The practice of front end development is similar to playing the bass: it’s easy to learn but difficult to master. There is a lot more to it than HTML and CSS (which are plenty difficult onto themselves).
Chris posed the question on Twitter in fill-in-the-blank form:
Front end development is hard because _________.
— Chris Coyier (@chriscoyier) August 16, 2015
And while the majority of responses were certainly entertaining and LOL-worthy, there were some nuggets of wisdom in there as well. Let’s take a look at the common themes that make front-end development, uh, development!
We have to deal with cross browser compatibility.
Inconsistent browser behaviour
— Nathaniel Flick (@nathanielflick) August 16, 2015
This was far and away the most cited gripe in the group. While Internet Explorer continues to be the brunt of most jokes, every browser has its own quirks that often require special development techniques to overcome.
It’s rather expected of us that we know how to build websites that can work cross-browser. We should know what browsers support what and how to debug and overcome browser-specific issues. We should know how to do emulate or otherwise test on a variety of browsers.
We should know tools that help us with cross-browser problems either automatically or enable us to write code to handle situations of support and nonsupport of features. We should know how to do fallbacks. We should know about progressive enhancement and graceful degradation.
Cross browser compatibility is a hugely complex development task.
Oh my, all those devices!
Varying screen sizes and browsers.
— Nicholas Bumgarner (@NickBumgarner) August 16, 2015
In addition to dealing with browser inconsistencies, front-end developers are also charged with developing for as many screen sizes, screen orientations, pixel densities, and input types as possible.
The burden of the massive landscape of different screens, browsers, and capabilities lies most heavily on front end developers.
Frameworks, libraries, preprocessing, dependencies, plugins…
So many new things everyday and no idea what will become standard.
— dean (@visualcookie) August 16, 2015
All the lame frameworks out there
— Rick Blalock (@rblalock) August 20, 2015
Today’s development feels a lot different. The toolchain is a lot thicker. We’re making choices about build processes, which libraries to use, what languages to write in, how invested in future syntaxes we want to be, how much we want to depend on frameworks, which third-party tools make sense and feel safe to use.
Not only is it fatiguing to think about the choices, it’s increasingly difficult to know what the best choices are and if these choices are smart in the long term.
There are just as many choices, or more, at the front end level of development than there are anywhere else. Not to mention the landscape moves extremely quickly.
We’re the bridge between visual designers, back end developers, and other disciplines.
because it doesn’t feel entirely “front-end” anymore
— Ara Abcarians (@ItsMeAra) August 17, 2015
Many of today’s frameworks and CMS’s, straddle the line between lots of different disciplines. Front end developers are right in the middle of it all. We’re ultimately responsible for design—how the site looks. We’re helping content people ensure they have what they need and they give us what we need. We’re working in templates prying out the data we need in the formats we need. We’re handling user input and ensuring it funneling where it goes for more back end concerns.
You get confused between who you are – programmer or a designer
— Priyanka N Majumder (@PriyankaNM) August 17, 2015
The chain of blame starts with front end
— Chris (@chrisdebelen) August 16, 2015
Not only do we sit in the intersection of a lot of disciplines, there is some expectation that we know enough back end languages to be useful. You’d be pretty sorry WordPress developer if you didn’t know any PHP. You wouldn’t be very useful on a Rails project if you didn’t know any Ruby or Rails conventions at all. The more you know, the more agile and self-sufficient you can be for your team.
Everybody and their dentist thinks they can do it.
It’s easy, make it like this..wait-now like this…ok now that we’re done, can we change everything to this? it’s easy…
— Andrew League (@aleague888) August 16, 2015
The barrier to entry for front end development is fairly low. Everyone has heard of HTML. They “know enough to be dangerous” as it were. Because that barrier is low and because it so easy to dabble, it makes sense people assume there isn’t that much to know and that front end development isn’t particularly difficult.
Naming things. And we have to name a lot of things.
You have to name things.
— Stuart Robson (@StuRobson) August 16, 2015
I imagine you’ve heard the maxim about naming things being one of the hardest problems in computer science. Us front enders are naming things all the time. Class names and IDs, data attributes, file names, communicating patterns with your team. It’s endless. It feels like there are dozens of name choices on an average day.
Not to mention the task of copywriting often falls to us, which isn’t quite naming but is in a similar vein of difficulty.
“The right way” and “the wrong way” aren’t as cut and dry as with back end development.
No standard production pipeline. No reference browser implementation. No right answers, but tons of wrong ones.
— Pelle Bjerkestrand (@pcbjerkestrand) August 16, 2015
In back end development, if what you are expecting to happen happens, you’ve succeeded. Surely they are different ways to get there, some better than others. But in front end development, the paths to completing a task seem endless. Even if you’ve seemingly succeeded, it can feel like just a matter of time until a bug is found in how you’ve done it.
CSS is very hard to test.
Bugs can be subtle, confusing, and unexpected. Worse, a seemingly little change may have an adverse effect in an unexpected place where you don’t notice until it’s too late.
There are linting tools, which help a little. There are some styleguide enforcement tools, but they don’t really help enforce more important things like adherence to naming standards.
Front end developers need to hold a very strong understanding of the entire website in their head in order to be most effective and efficient.
Performance is 80% on our shoulders.
The rule of thumb is that 20% of the waiting for a website to load is from back end concerns. Once HTML document has arrived, the rest of loading time is the concern of front end developers. What resources are loaded, how many resources are loaded, how optimized they are, in what fashion they load in and how that feels, etc.
It’s where accessibility happens.
Building sites that are visually stunning is one thing and the accessibility of them is another. Designers care very much how users interact with a site and that might not always be a visual interaction. Designing and developing for disabilities is a dicipline onto itself, but is most tightly tied to front end development. Accessibility has its own set of specifications that sadly aren’t typically taught along with traditional front end development training.
It’s hard to hire for.
Front end developers are typically the hardest seats to fill.
And, of course…
Because we make it hard.
— (@mikeyb) August 16, 2015
So what do you think? Is front end development “real” development? I’d like to think so and believe the feedback provided here—especially by others—is solid proof. Are there more things that make it hard? SEO? Is this a conversation worth having?