How To Write High Impact Frontend Code
The Value Chain of Frontend Development With Examples
The hype of the 2010s is over. Frontend development is not that hot anymore. The SPA revolution is gone, React won and became a server side framework apparently. Reactive state updates don’t get anyone excited anymore, Redux became boring (including the Toolkit, sorry), we can now write CSS in all languages imaginable and unit test it to our heart’s content. GraphQL became a curse word for some people. And the list goes on. Also many of us got jaded by the soulless hype machine so Signals, Runes, HMTX or Server Actions don’t ignite the same spark in a lot of us.
So what do we do now? I think this is a perfect opportunity to take a step back and critically evaluate what we have been really doing while riding the hype train of the last decade and some. What did we achieve while learning all the hot stuff and what can we take away to do better in this current decade? Maybe frontend was always about more than what the industry put in our focus?
Innovation hasn’t stopped of course and I will share my views on what are the most influential current trends, but now I want us to think about some more fundamental questions:
What’s the real point of working on the frontend?
What are the problems we are really supposed to solve?
What’s the real value add of frontend engineers? In other words, what will prevent us from being replaced by sophisticated Figma to React tools?
What’s The Point of Doing Frontend?
It’s a crucial question, that we are honestly not conscious enough about as the FE community. Let’s clear this up once and for all. In my mental model, frontend has 2 pivotal roles:
It acts as an interface to the value provided by the backend systems. The frontend can block, hinder, deliver or enhance that value.
It adds its own unique features, that’s impossible to be created at any other point of network based applications.
We, frontend developers, work to create and deliver these two things. (Besides the meta-goal of improving work effectiveness and efficiency itself.)
Many recent innovations like Next.js API routes/handlers, RSCs or the Remix “paradigm” of loaders and actions fall into the first category, helping us in more effectively surfacing the value of the BE systems. Even the Qwik style 0 hydration, instant-on applications belong to this category as the application itself is initially “value provided by the BE (host) system”. Hyperfiddle takes this to the next level with compiler-level networking built into the apps. This space is still dynamically evolving. I think even more than the other category. Just think Prisma, or Drizzle.
Unique to the client value is less hot, but still going strong today, first things coming to mind are the View Transitions API, Container Queries or anything related to styling, accessibility, information architecture, SEO, observability or UX in general. Another, now well-established tool I learned to love during the recent years in this space is framer-motion.
To identify the specific value that any given frontend creates we need to identify the contents of these 2 broad categories for that given project.
The definition of “value” is a very contended one and I see a lot of developers who don’t understand it deeply. In the Full Context perspective I use the following form which I think captures the essence quite well: Value is anything that solves a real life problem of the users, that helps to achieve the mission of the businesses or that helps to reach the personal goals of the developers and other colleagues.
Customer experience, company mission and developer experience are some of the key reasons why we should be writing frontend code.
So let’s lay it out plain and simple. It all boils down to how your work helps with the matrix of:
(CX || Mission || DX) x ( BE Value || FE Value)
Here are some examples of what these categories could mean for a frontend developer:
Delivering BE value:
CX: Make the customer more happy with things like optimistic updates or streaming HTML responses, or a local first/offline first approach to enrich the BE capabilities. Improve request/response times by minimizing both the payload and the requested data. Understand your APIs and the http/websocket protocols deeply to improve performance and security.
Mission: A baseline example is meeting a feature requirement by integrating with an API, like adopting a new payment provider to enter a new market. More BE aspects related to mission are: achieving a non-functional requirement like https for regulatory compliance or even simpler stuff like setting up a proper cross domain policy across systems.
DX: Make work easier and more fun for both BE and FE engineers by adopting contract testing via Pact or by using tRPC to streamline communication. Maybe generating some TypeScript types from OpenAPI specifications, perhaps reusing validation logic or other code bits across the network divide.
Adding unique FE value:
CX: Better SEO, more accessibility, better rendering performance, fancier buttons, instantaneous UI feedback on interactions, meaningful error messages, well timed tips or recommendations.
Mission: The baseline example is similar here too: enabling delivery of a feature requirement by integrating a client-side tool/technique like: localization or branding/theming support to reach the target audience. It could also be about meeting non-functional requirements, like collecting analytics data to gain more user-insight (Snowplow SDK?).
DX: QwikCity, SolidStart, Astro, React Router v7 public-alpha, or simply ditch Webpack for Vite. Anything that the hype-train hauls our way. In all seriousness, anything that makes the codebase easier to understand and easier to change are the big wins here. Improving consistency, removing redundancy, eliminating flakiness and increasing productivity is the name of the game.
What Are The Problems We Are Supposed To Solve?
If you take this idea one step further, we are really doing all of this for the people who are interacting with the code/software we deliver. Working on the frontend could become a human-centric activity, even with its technical & abstract nature, if we ultimately focus on those interactions and their impact on the lives of others.
This sits at the heart of the Full Context approach too, the Beyond You idea, could be interpreted as: look at what would make the people from the 3 domains - business stakeholders, coworkers and users - love the software more. That’s our real job as frontend developers or in general as software engineers, to deliver improvements that will:
Make our company more profitable - so that business stakeholders will love it more.
Make our users’ lives better - so that customers will love and use it more.
Make our colleagues’ lives easier - so that your teammates will be happier and love their job a little more.
What do those problems look like in our FE dev day to day lives?
It all comes down to knowing the goals and pain points of the people from the 3 main groups. What makes the lives of the users, colleagues or business stakeholders hard at the moment, what are the inefficiencies or unmet needs?
Impact is fundamentally not technical but humane.
There are many ways to tackle this, but one super helpful tool I have up my sleeve is the 15 Product Qualities. All 3 dimensions can interpret software as a product in their own domain and map the Product Quality attributes to actionable insights that can guide a frontend developer or technical leader in finding the highest impact problems to tackle.
As this is very broad in scope (at least 45 aspects to think about…) I won’t repeat the mistake I’ve committed several times in the past and attempt to cover all of them here. Instead I will simply share 3 common issues that I believe have the highest chance to help you make some noticeable impact at your job… right as I cover the next big question:
What’s The Real Value Add Of Frontend Engineers?
Our coding ability is not the most important skill that we have! I would argue that’s just a baseline requirement. Where you should really focus on to make significant impact is finding the places where your unique professional and technical insights meet with the questions or needs of the people from the other dimensions and use it to answer/solve them in a way they could never achieve without your insights. That’s the true value add of any frontend or rather any software engineer and it won’t be replicated by code generating tools any time soon! Let’s see some tangible examples.
Three high-impact areas where frontend developers can really shine
Making collaborative decisions about what is the best place for data or computation. Putting a piece of information on any of the following places: client memory, browser cache, service worker, CDN, edge infra, a message queue or database, has tremendous user-experience, cost, and architectural implications and we can lead or contribute to these discussions in very meaningful ways. Same is true for computation, you can suggest where something is best calculated at and how often. All these decisions require a deep understanding of the project’s context and can steer it towards success or failure in major ways.
Personal example: In 2019 I was tasked with leading the frontend project setup of Gradyent AI, a web app that optimizes district heating networks with a digital twin (AI). One of the fundamental decisions to make was to decide how to render the interactive map displaying the near real-time properties of the heating networks. The company’s founder brought in a map expert consultant and the stack they were pushing for was BE focused both in terms of storage and computation. That’s until I’ve found DeckGL. I convinced the founder and the consultant that rendering the interactive map on the client is the best move for us both in terms of infra costs, available skills in-house and user experience. I think it’s one of the key technical driving forces of the success of this application to this day!
Making collaborative decisions about logging and analytics, that cuts to the heart of what happens, or covers unusual events the other colleagues couldn’t even think about. This requires your to understand the real life usage of the product as well as the perspective of key business stakeholders but is also an area where you have unique insights into the situations the frontend code can end up in, that’s often only visible to you, the developer. Should that case be visible in the logs/metrics? With what data? And what does it tell to the business stakeholders when it happens? Should it be reported on dashboards or alerts? All questions that you can raise and find the answers to, together with colleagues from other areas. In my experience, it’s often very helpful to increase your exposure/visibility, to deepen your understanding of the business domain and to make a better product, a win-win (3x)!
Personal example: When I implemented my own online product fullcontextdevelopment.com I’ve tried to log every error case in a way that’s emphatic and action oriented for end users. Not long after launching the product, I got a DM on X (Twitter at the time) from one of the first customers about them facing an issue with signup. It was very embarrassing, as the payment was taken but their account wasn’t activated. However they told me they were impressed by the error message, something along the lines of: “Sorry to fail you at the critical time of the first login! Don’t worry however, your payment was safely processed, this is an issue on our end, if it doesn’t resolve after a few more retries please reach out to support (link)”. One of the most memorable, organic appreciation that the extra effort I’ve put in ever received from someone who is not a colleague.
Making collaborative decisions about improving the UX/UI design. You as a developer might offer alternative approaches to the look and feel of the product that make more sense from some perspective. Often it’s about reuse, how to reuse or just slight tweak something-already-existing to achieve the same goal but for 20% of the effort. Another common topic is consistency, sometimes designs are made in isolation, but in the context of the whole application/site it might make sense to just stick to an already established pattern. You might be more familiar with those, bringing that perspective to the discussions. Frontend devs can also often shine a light on unhandled edge cases. What should we do when the network fails? What about a retry? What should happen while the request is in-flight?
Personal example: While working at Snowplow I was developing a wizard style, multi-step form for setting up a connection to different cloud storage solutions. As I was using it during development and went through the steps countless times I’ve realized, if we changed the UI a bit we could get to the same result while reducing the number of questions by 1/3. I’ve set up a call with the designer, explained my idea and got the green light right away. We both were happy about the outcome, and as an extra benefit this whole process helped in building a good working relationship between us while also improving the product for the end users.
Final Words
Hope this gives you some inspiration to look for ways to put your unique frontend skills and insights into good use! Let me know in the comments a story of how you did that, or what other techniques you have to make an impact. I believe by shifting our focus on the outcomes of our decisions rather than the options that we can choose from, we will make the next decade of frontend development better for everyone!
And now let’s get back to writing code that makes someone love the software even more!