The power of frontend

When I was applying for my current job, I remember saying something like “Well, I’ll start with frontend, but in the long run it would be cool to go full stack.” Doing frontend felt just like half of the skill set. After I’ve watched the talk of Chris Coyier at the JAM stack conference, it no longer does. Doing frontend is awesome and is getting more and more visibility. In this article I gonna tell you why.

[TL;DR: More visibility by clients and managers, site-level decision-making, more backend/frontend overlap in the new tech stacks, more server-independency, and, hence, more work]

First of all, what do we, frontend developers, have in common? We care about the experience of people that use a browser*. How do we do that? By designing for people with various needs and by implementing beautiful, performant and usable websites or apps that run in multiple browsers and devices. This is a very noble job.

What the client and user sees

Motivation is fueled by success. With frontend you can achieve the first results already with a couple of html tags. You can literally see your progress, which is really rewarding.

With the majority of people relying on their sight (the so-called visual learners), the communication is often based on what we can see. In my experience, frontend results get more appreciation from clients, because they are more visible. As Chris Coyier said, “managers get involved here”. Perfomed a complex SQL-request in miliseconds? Ok. Added a fancy animation and a hover-effect? Wooo-hoooo!

I’ve also noticed that many feature discussions start only when the frontend guys has done their job. Suddenly, the client brings up one idea after another, once they have the visuals. “Oh, what if we add a nice overview here?” “How about a little banner there?”

So, the frontend work is being noticed. This has been always my motivation, nothing new here. How about some recent developments, that make this job even more attractive? Let’s get to it.

Decision making

IT architects are the ones who have the power to decide about the overall structure and logic of the app. You might think about huge infrastructure landscapes printed on giant sheets of paper or some debates on the tech stack. Those are the things that are more often associated with the backend. However, with the introduction of web components, we got to rule, too. Frontend developers now also decide how to split the web app into meaningful chunks, where and how to do templating and data handling, divide and share responsibilities, chose design patterns and methodologies (e.g. BEM — block, element, modifier) etc. This shift to more decision making in the frontend happened not only due to the modular approach, but also because we’ve got more things to do. This is my next point.

Backend of the frontend

A lot of things moved from the backend to the frontend via JavaScript (e.g. node.js). since as a frontend developer I am not scared of it. Though I like the moment, when I can say something like “oh, it’s just a dumb frontend, too bad backend should take care of it”, there are more and more use cases where we guys can actually do something about it. For example, fetching and even updating data with GraphQL, managing app state with Redux, sending emails with Sparkpost API. Do you feel (almost) allmighty? I do.

Chris Coyier has another interesting observation. With JS taking over web development, the technology stack enables more and more backend/frontend overlap. With LAMP, the devision was clear. MEAN enabled mutual understanding through the common language. Serverless/STAR makes the boarder blurred or even not relevant (see the graphics on the left side).

So, with all these new JS-based features and stack shift, it sometimes seems like we are doing front of the frontend and back of the frontend, so it is ok to feel a bit “fullstacky”.

Many tasks

Well, being fullstacky implies a lot of work. Here are some new topics: component-driven design, site-level architecture, routing, talking to APIs, data and state management. Project work also requires the knowledge of git, tests, build processes, deployment pipeline… But wait! The old responsibilities are still there — design system, accessibility, performance, browsers compatibility, responsiveness, IX, UX etc.

The good news is — you don’t have to do it alone and to focus on each of these tasks. So, welcome the era of frontend engineers, UX engineers, frontend architects or even fullstack frontend developers!

Frontend is powerful.

Frontend is fun.

Frontend is a lot of work.

If you wanna see the whole talk of Chris Coyier, check this out:

https://www.youtube.com/watch?v=lFOfQsi5ye0

*Sure, not only web apps have frontend, but it is more common to talk about it in the context of web developement.

[Disclaimer: you think the author misses the point or provides incorrect information? Blame the author AND provide missing / relevant / correct information in your comments — help other readers (and the author) to get it straight! a.k.a. #learningbysharing]