Swizec Teller - a geek with a hatswizec.com

    In 2020's, what is "frontend"? 🀨

    He's a frontend guy, is this even a fair question to ask?

    The head of engineering was worried about our systems design question. Part of the standard process:

    • test algorithms
    • ask about systems
    • pair program on a skills-based test
    • culture

    I went through this in June. The algorithms question destroyed me and I thought about it for days πŸ˜…

    The systems design question was fun though.

    You design a social network newsfeed thingy. How would you store data? Which servers to use? What about caching? Where's the SQL? Schema design? Querying? Security?

    computers giphy

    Fair question if that's the work. Everyone's been doing everything. Small team.

    But will that stay true? Would you ask that question of someone who spent the last N years in a big company writing client JavaScript? πŸ€”

    Frontend vs. Backend

    Swizec Teller published ServerlessHandbook.dev avatarSwizec Teller published ServerlessHandbook.dev@Swizec
    Calling APIs, assembling HTML, and handling forms is frontend work even if the code runs on your server.

    Yes or no?

    Growing up in the early 2000's, there was no frontend and backend.

    You write PHP? Okay you're a web developer.

    You write HTML? Yep, web developer.

    You write CSS? Yep, web developer.

    You do everything. Designer makes pretty pictures. You turn them into websites.

    Code runs on the server, cobbles together HTML and CSS, inserts dynamic data, spits out a webpage. Browser renders and deals with user interaction. Anything a user clicks is a new request to the server and a full page reload.

    Around 2010 the industry decided this was a bad idea. JavaScript apps were born.

    We now had frontend and backend.

    Backend engineers wrote server code. They designed data models, handled API requests, dealt with servers and hosting and REST design.

    Frontend engineers wrote the UI. Build the HTML, fuss over CSS, write JavaScript for interactive widgets, sometimes call an API.

    The work was visual in nature. Main goal was creating a nice user experience and offloading business logic to the server.

    Frontend Infrastructure vs. UI

    As JavaScript apps became more complex the frontend world developed a split πŸ‘‰ infrastructure vs. UI.

    You build a design system and there's no UI work left.

    Design system ensures everything looks great. It's got a whole team. They write the CSS, the core design atoms, and self-contained interactive components.

    You don't think "Hm, how do I make a date widget?" or "I wonder how to add this animation and pleasant interaction on the type-ahead field"

    Heck no!

    You slap a <DateInput /> or a <Input typeahead={true} /> in there and move on. πŸ’ͺ

    What you're left with is the frontend infrastructure work.

    How do you design the data models? Where do the API calls go? How do you cache requests? How do you architect your app for speed and good developer experience? How does a widget bottom-left get state from top-right?

    Sound familiar eh πŸ€”

    Backend of the Frontend vs. Deep Backend

    You create a backend of the frontend.

    The data layer that handles business logic, talks to the API, handles performance, and tells your UI layer how to act.

    You can go days, weeks, entire projects, without touching UI code. But you're working on the frontend. Writing JavaScript that runs in the browser.


    Then you run this code on the server to create server-side rendering. Or on your own machine at deploy-time to create compiled JAMStack sites.

    wtf giphy

    What gives? Where's the backend?

    The true backend is no longer your data model and your business logic. It's that API you're calling.

    You treat the API as backend developers of old treated their database. GraphQL makes this even more obvious.

    But somebody builds that API. Makes it work. Makes it talk to other services. Ensures data's consistent. Deals with caching at scale.

    That's The Deep Backend. The folks who live their lives in data pipelines, JSON validations, API schemas, databases, and server monitoring software.

    It's hard work. Mind-bending work. Plagued with fundamental Two General paradoxes.

    Imagine if Redux or useState had a 1% failure rate. 1% chance that you call an action and nothing happens. Oops.

    That's Deep Backend work.


    DevOps is an area tangential to Deep Backend. Maybe orthogonal? πŸ€”

    The part that deals with servers and hosting. Used to be part of backend work.

    You provision a server, create a database, run scripts on the command line, write kubernetes configurations, and think about Docker and containers. Sometimes you play with the AWS console.

    You live and die by your monitoring metrics and alarms.

    Site goes down on Black Friday it's your fault we're losing millions per minute.

    gulp giphy

    I don't know anybody who likes doing DevOps. But being an SRE – site reliability engineer – is the highest paid position in software engineering right now.

    The future

    The future is bright my friend.

    With the rise of platforms like Netlify, Vercel, and Begin doing your DevOps, and serverless computing dealing with the repetitive backend work, you can focus on the business logic.

    Let AWS deal with servers. Let X deal with hosting. Let junior developers deal with fun UI challenges.

    You focus on Frontend Infrastructure, the Backend of the Frontend. The money maker.

    And hey with serverless, writing server code is like the JavaScript work you know and love.

    It's a JavaScript function. Platform handles the rest. ✌️

    What did I tell the head of engineering?

    That's the wrong question. Ask them an app architecture question. Like you're interviewing an iOS developer.

    Our Express "backend" is frontend even if runs on the server.

    think giphy

    Happy Friday ❀️


    PS: 79% votes for "this is frontend", 20% for "backend" ✌️

    PPS: all of the above is why I created Serverless Handbook – modern backend for frontend engineers

    Did you enjoy this article?

    Published on August 7th, 2020 in Backend Web, Frontend Web, Fullstack Web, JavaScript, Technical

    Learned something new?
    Want to become an expert?

    Here's how it works πŸ‘‡

    Leave your email and I'll send you thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

    Join Swizec's Newsletter

    And get thoughtful letters πŸ’Œ on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.

    "Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. πŸ‘Œ"

    ~ Ashish Kumar

    Join over 14,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. ✌️

    Have a burning question that you think I can answer?Β I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

    Ready to Stop copy pasting D3 examples and create data visualizations of your own? Β Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

    Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

    Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first πŸ’° on the side with ServerlessReact.Dev

    Want to brush up on your modern JavaScript syntax?Β Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❀️

    Created by Swizec with ❀️