Are Front-End Developers Real Developers?

I take it by now you have read Learning JavaScript in 2016 and taken a look at The State of JavaScript. This article will not be exploring the complexities of JavaScript in 2016; it will instead be providing an overview of what it means to be a front-end developer in 2016 and why front-end developers are real developers.

Before I start I will quickly let you know that I am employed full time as a front-end developer; however I am often expected to handle the companies overflow back-end development; this has given me a good understanding of the similarities and differences between both professions and a decent insight into what both fields contain.

I want to make it clear that I am not trying to start a flame war, or insinuate that front-end development is in anyway more difficult than back-end development. If anything I would like to convey why I think that in November of 2016 that front-end development deserves to be considered an equivalent profession in terms of technicality and skill required as to that of back-end development.

As a front-end developer I have found that there is a common stigma in the community that back-end development is considered to be the superior of the two, and that front-end development is in fact the easier alternative for people who can’t hack the back-end; in extreme cases I have even experienced back-end developers referring to front-end development as not real development. Five or six years ago this may have been true when web pages were inherently static, responsive web development did not exist, and single page applications were a frustration of the future. But it is not five or six years ago, it’s 2016 and front-end development is more complicated than ever, and to demonstrate this I am going to outline some of the more technical tasks a front-end developer faces in their daily development cycle. These tasks are what, in my experience make front-end development a qualifying rival when compared to something like back-end development.

**Pre-Processors / Compilers**Often when people think of the front-end the first thing that comes to mind is HTML/CSS/JavaScript, correct; these ultimately are the languages that make up the front-end. However, today it is very rare that you will find these languages used in their raw form, instead developers have opted to use pre-processors, tools which allow developers to write more compact code and then compile it down to its original form. These tools often provide better performance as a developer but with the large number and different pre-processors everywhere (Jade / Haml / Slim / Sass / Less / Stylus / CoffeeScript / TypeScript / Babel / etc…) it has become increasingly difficult to keep up.

Build ToolsWhen writing production level code there are many prerequisites that need to be met. These include things like minified CSS, uglified JavaScript, and image optimisation to name but a few. These prerequisites help with things like Google page speeds and faster load times of a site for the end user. All of the above prerequisites can be automated with a tool like gulp or webpack; however both of these tools take considerable set up and an in-depth understanding of how each tool works (especially webpack).

**Framework Expectation**Over the last year their has been a growing emphasis and expectation on the use of Front-end Frameworks. Building on the above two points, lots of these front-end frameworks encourage the use of ES6 JavaScript. this is usually achieved using a pre-processing / compiling tool called babel which is often implemented using a build tool like webpack. Front-end Frameworks have in many ways brought consistency and structure to front-end development, and they are one of the key reasons I think front-end developers should be considered real developers. This is because front-end frameworks often implement advanced programming concepts such as the MVC model, which helps developers modulate their code into more manageable components when working on large scale applications. Another example of this is the recent uptake of functional style programming within the community; this is less of a structural concept and more of a programming style. If you are interested in examples of this check out RxJS, Ramda, or my favourite elm.

**Industry Progression and Saturation**The front-end community is booming and as a result new frameworks come out every other day. New implementations of existing tools that are better or faster than the one before are released weekly and if you do not show an instant uptake you will quickly be considered outdated in the eyes of the community. This means not only are you expected to work within a saturated ecosystem, you are expected to have an in depth understanding of said saturated ecosystem in order to stay relevant.

Bugs versus TweaksOne of the things I really envy about my back-end developer co-workers is how little opinion the client has of their work. This is because in most cases when back-end functionality is implemented, it either works and does what the client wants, or does not; there is no in-between. Front-end development is an entirely different story. I can develop what the client expects from the given PSD, PDF, etc… but quite often once it is available in the browser I receive comments like “…could we just make this a bit smaller…” or “…maybe if we just made the background here a bit darker…” and it can go on, and on, and on. There are certainly occasions where I have got it wrong and it is a bug that I need to fix, but in most cases I find it would more appropriately be classified as a tweak and comes entirely down to the client’s opinion.

**Testing and Deployment**This is the point I am most excited to talk about because I think this is what gets over-looked the most in any website development life cycle.Everybody has to test their code this is just part of programming, however I would like to emphasise the level of automation that can be achieved between the two different professions. In my experience, most back-end code can be tested in an automated manner, while a large portion of front-end code can be tested automatically there is always going to be a manual aspect to it, whether it is manually clicking around 20 pages on 5+ browers, or reviewing 100's of browserstack images someone at some point is going to have to make sure everything is okay. In addition to this there are thousands of devices and resolutions out there and your website needs to work on all of them. Most people don’t fully comprehend what this means; in most back-end situations a developer is expected to write for one environment (the server) so this means that once the code is working that’s it. A front-end developer usually writes and tests their code in their preferred browser, and then has to test in every other browser. I have written code that has worked flawlessly in Chrome, IE, and Safari, only to find it fall short in Firefox and need a full re-write. Once that code is re-written it needs to be re-tested, now that might sound fairly minor but imagine if every time you make an update you have to re-live this process and every browser you test in can mean a potential re-write, this rapidly begins to take a toll on even the best developers.

So there you have it, while an exact comparison between front-end and back-end development may not be possible, given the differences between both fields, I do believe that front-end development has certainly come a long way in the last four years and having worked in both industries I like to think that it deserves its place as an equal to back-end development in terms of overall technicality and skill required. I would also love to see the community come together and get over this stigma that front-end developers are somehow second tier developers and give them the appreciation and respect they really deserve; come on folks let’s share the love.