This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.”
The moment I fell in love with front-end development was when I discovered the style.css file in WordPress themes. That’s where all the magic was (is!) to me. I could (can!) change a handful of lines in there and totally change the look and feel of a website. It’s an incredible game to play.
By fiddling with HTML and CSS, I can change the way you feel about a bit of writing. I can make you feel more comfortable about buying tickets to an event. I can increase the chances you share something with your friends.
That was well before anybody paid me money to be a front-end developer, but even then I felt the intoxicating mix of stimuli that the job offers. Front-end development is this expressive art form, but often constrained by things like the need to directly communicate messaging and accomplish business goals.
Front-end development is at the intersection of art and logic. A cross of business and expression. Both left and right brain. A cocktail of design and nerdery.
I love it.
Looking back at the courses I chose from middle school through college, I bounced back and forth between computer-focused classes and art-focused classes, so I suppose it’s no surprise I found a way to do both as a career.
The term “Front-End Developer” is fairly well-defined and understood. For one, it’s a job title. I’ll bet some of you literally have business cards that say it on there, or some variation like: “Front-End Designer,” “UX Developer,” or “UI Engineer.” The debate around what those mean isn’t particularly interesting to me. I find that the roles are so varied from job-to-job and company-to-company that job titles will never be enough to describe things. Getting this job is more about demonstrating you know what you’re doing more than anything else¹.
Chris Coyier
Front-End Developer
The title variations are just nuance. The bigger picture is that as long as the job is building websites, front-enders are focused on the browser. Quite literally:
- front-end = browsers
- back-end = servers
Even as the job has changed over the decades, that distinction still largely holds.
As “browser people,” there are certain truths that come along for the ride. One is that there is a whole landscape of different browsers and, despite the best efforts of standards bodies, they still behave somewhat differently. Just today, as I write, I dealt with a bug where a date string I had from an API was in a format such that Firefox threw an error when I tried to use the .toISOString() JavaScript API on it, but was fine in Chrome. That’s just life as a front-end developer. That’s the job.
Even across that landscape of browsers, just on desktop computers, there is variance in how users use that browser. How big do they have the window open? Do they have dark mode activated on their operating system? How’s the color gamut on that monitor? What is the pixel density? How’s the bandwidth situation? Do they use a keyboard and mouse? One or the other? Neither? All those same questions apply to mobile devices too, where there is an equally if not more complicated browser landscape. And just wait until you take a hard look at HTML emails.
That’s a lot of unknowns, and the answers to developing for that unknown landscape is firmly in the hands of front-end developers.
The most important aspect of the job? The people that use these browsers. That’s why we’re building things at all. These are the people I’m trying to impress with my mad CSS skills. These are the people I’m trying to get to buy my widget. Who all my business charts hinge upon. Who’s reaction can sway my emotions like yarn in the breeze. These users, who we put on a pedestal for good reason, have a much wider landscape than the browsers do. They speak different languages. They want different things. They are trying to solve different problems. They have different physical abilities. They have different levels of urgency. Again, helping them is firmly in the hands of front-end developers. There is very little in between the characters we type into our text editors and the users for whom we wish to serve.
Being a front-end developer puts us on the front lines between the thing we’re building and the people we’re building it for, and that’s a place some of us really enjoy being.
That’s some weighty stuff, isn’t it? I haven’t even mentioned React yet.
The “we care about the users” thing might feel a little precious. I’d think in a high functioning company, everyone would care about the users, from the CEO on down. It’s different, though. When we code a <button>, we’re quite literally putting a button into a browser window that users directly interact with. When we adjust a color, we’re adjusting exactly what our sighted users see when they see our work.
That’s not far off from a ceramic artist pulling a handle out of clay for a coffee cup. It’s applying craftsmanship to a digital experience. While a back-end developer might care deeply about the users of a site, they are, as Monica Dinculescu once told me in a conversation about this, “outsourcing that responsibility.”
We established that front-end developers are browser people. The job is making things work well in browsers. So we need to understand the languages browsers speak, namely: HTML, CSS, and JavaScript². And that’s not just me being some old school fundamentalist; it’s through a few decades of everyday front-end development work that knowing those base languages is vital to us doing a good job. Even when we don’t work directly with them (HTML might come from a template in another language, CSS might be produced from a preprocessor, JavaScript might be mostly written in the parlance of a framework), what goes the browser is ultimately HTML, CSS, and JavaScript, so that’s where debugging largely takes place and the ability of the browser is put to work.
CSS will always be my favorite and HTML feels like it needs the most love — but JavaScript is the one we really need to examine The last decade has seen JavaScript blossom from a language used for a handful of interactive effects to the predominant language used across the entire stack of web design and development. It’s possible to work on websites and writing nothing but JavaScript. A real sea change.
JavaScript is all-powerful in the browser. In a sense, it supersedes HTML and CSS, as there is nothing either of those languages can do that JavaScript cannot. HTML is parsed by the browser and turned into the DOM, which JavaScript can also entirely create and manipulate. CSS has its own model, the CSSOM, that applies styles to elements in the DOM, which JavaScript can also create and manipulate.
This isn’t quite fair though. HTML is the very first file that browsers parse before they do the rest of the work needed to build the site. That firstness is unique to HTML and a vital part of making websites fast.
In fact, if the HTML was the only file to come across the network, that should be enough to deliver the basic information and functionality of a site.
That philosophy is called Progressive Enhancement. I’m a fan, myself, but I don’t always adhere to it perfectly. For example, a <form> can be entirely functional in HTML, when it’s action attribute points to a URL where the form can be processed. Progressive Enhancement would have us build it that way. Then, when JavaScript executes, it takes over the submission and has the form submit via Ajax instead, which might be a nicer experience as the page won’t have to refresh. I like that. Taken further, any <button> outside a form is entirely useless without JavaScript, so in the spirit of Progressive Enhancement, I should wait until JavaScript executes to even put that button on the page at all (or at least reveal it). That’s the kind of thing where even those of us with the best intentions might not always toe the line perfectly. Just put the button in, Sam. Nobody is gonna die.
JavaScript’s all-powerfulness makes it an appealing target for those of us doing work on the web — particularly as JavaScript as a language has evolved to become even more powerful and ergonomic, and the frameworks that are built in JavaScript become even more-so. Back in 2015, it was already so clear that JavaScript was experiencing incredible growth in usage, Matt Mullenweg, co-founder of WordPress, gave the developer world homework: “Learn JavaScript Deeply”³. He couldn’t have been more right. Half a decade later, JavaScript has done a good job of taking over front-end development. Particularly if you look at front-end development jobs.
While the web almanac might show us that only 5% of the top-zillion sites use React compared to 85% including jQuery, those numbers are nearly flipped when looking around at front-end development job requirements.
I’m sure there are fancy economic reasons for all that, but jobs are as important and personal as it gets for people, so it very much matters.
So we’re browser people in a sea of JavaScript building things for people. If we take a look at the job at a practical day-to-day tasks level, it’s a bit like this:
- Translate designs into code
- Think in terms of responsive design, allowing us to design and build across the landscape of devices
- Build systemically. Construct components and patterns, not one-offs.
- Apply semantics to content
- Consider accessibility
- Worry about the performance of the site. Optimize everything. Reduce, reuse, recycle.
Just that first bullet point feels like a college degree to me. Taken together, all of those points certainly do.
This whole list is a bit abstract though, so let’s apply it to something we can look at. What if this website was our current project?
Our brains and fingers go wild!
- Let’s build the layout with CSS grid.
- What fonts are those? Do we need to load them in their entirety or can we subset them? What happens as they load in? This layout feels like it will really suffer from font-shifting jank.
- There are some repeated patterns here. We should probably make a card design pattern. Every website needs a good card pattern.
- That’s a gorgeous color scheme. Are the colors mathematically related? Should we make variables to represent them individually or can we just alter a single hue as needed? Are we going to use custom properties in our CSS? Colors are just colors though, we might not need the cascading power of them just for this. Should we just use Sass variables? Are we going to use a CSS preprocessor at all?
- The source order is tricky here. We need to order things so that they make sense for a screen reader user. We should have a meeting about what the expected order of content should be, even if we’re visually moving things around a bit with CSS grid.
- The photographs here are beautifully shot. But some of them match the background color of the site… can we get away with alpha-transparent PNGs here? Those are always so big. Can any next-gen formats help us? Or should we try to match the background of a JPG with the background of the site seamlessly. Who’s writing the
alttext for these? - There are some icons in use here. Inline SVG, right? Certainly SVG of some kind, not icon fonts, right? Should we build a whole icon system? I guess it depends on how we’re gonna be building this thing more broadly. Do we have a build system at all?
- What’s the whole front-end plan here? Can I code this thing in vanilla HTML, CSS, and JavaScript? Well, I know I can, but what are the team expectations? Client expectations? Does it need to be a React thing because it’s part of some ecosystem of stuff that is already React? Or Vue or Svelte or whatever? Is there a CMS involved?
- I’m glad the designer thought of not just the “desktop” and “mobile” sizes but also tackled an in-between size. Those are always awkward. There is no interactivity information here though. What should we do when that search field is focused? What gets revealed when that hamburger is tapped? Are we doing page-level transitions here?
I could go on and on. That’s how front-end developers think, at least in my experience and in talking with my peers.
A lot of those things have been our jobs forever though. We’ve been asking and answering these questions on every website we’ve built for as long as we’ve been doing it. There are different challenges on each site, which is great and keeps this job fun, but there is a lot of repetition too.
Allow me to get around to the title of this article.
While we’ve been doing a lot of this stuff for ages, there is a whole pile of new stuff we’re starting to be expected to do, particularly if we’re talking about building the site with a modern JavaScript framework. All the modern frameworks, as much as they like to disagree about things, agree about one big thing: everything is a component. You nest and piece together components as needed. Even native JavaScript moves toward its own model of Web Components.
I like it, this idea of components. It allows you and your team to build the abstractions that make the most sense to you and what you are building.
Your Card component does all the stuff your card needs to do. Your Form component does forms how your website needs to do forms. But it’s a new concept to old developers like me. Components in JavaScript have taken hold in a way that components on the server-side never did. I’ve worked on many a WordPress website where the best I did was break templates into somewhat arbitrary include() statements. I’ve worked on Ruby on Rails sites with partials that take a handful of local variables. Those are useful for building re-usable parts, but they are a far cry from the robust component models that JavaScript frameworks offer us today.
All this custom component creation makes me a site-level architect in a way that I didn’t use to be. Here’s an example. Of course I have a Button component. Of course I have an Icon component. I’ll use them in my Card component. My Card component lives in a Grid component that lays them out and paginates them. The whole page is actually built from components. The Header component has a SearchBar component and a UserMenu component. The Sidebar component has a Navigation component and an Ad component. The whole page is just a special combination of components, which is probably based on the URL, assuming I’m all-in on building our front-end with JavaScript. So now I’m dealing with URLs myself, and I’m essentially the architect of the entire site. [Sweats profusely]
Like I told ya, a whole pile of new responsibility.
Components that are in charge of displaying content are almost certainly not hard-coded with data in them. They are built to be templates. They are built to accept data and construct themselves based on that data. In the olden days, when we were doing this kind of templating, the data has probably already arrived on the page we’re working on. In a JavaScript-powered app, it’s more likely that that data is fetched by JavaScript. Perhaps I’ll fetch it when the component renders. In a stack I’m working with right now, the front end is in React, the API is in GraphQL and we use Apollo Client to work with data. We use a special “hook” in the React components to run the queries to fetch the data we need, and another special hook when we need to change that data. Guess who does that work? Is it some other kind of developer that specializes in this data layer work? No, it’s become the domain of the front-end developer.
Speaking of data, there is all this other data that a website often has to deal with that doesn’t come from a database or API. It’s data that is really only relevant to the website at this moment in time.
- Which tab is active right now?
- Is this modal dialog open or closed?
- Which bar of this accordion is expanded?
- Is this message bar in an error state or warning state?
- How many pages are you paginated in?
- How far is the user scrolled down the page?
Front-end developers have been dealing with that kind of state for a long time, but it’s exactly this kind of state that has gotten us into trouble before. A modal dialog can be open with a simple modifier class like <div class="modal is-open"> and toggling that class is easy enough with .classList.toggle(".is-open"); But that’s a purely visual treatment. How does anything else on the page know if that modal is open or not? Does it ask the DOM? In a lot of jQuery-style apps of yore, yes, it would. In a sense, the DOM became the “source of truth” for our websites. There were all sorts of problems that stemmed from this architecture, ranging from a simple naming change destroying functionality in weirdly insidious ways, to hard-to-reason-about application logic making bug fixing a difficult proposition.
Front-end developers collectively thought: what if we dealt with state in a more considered way? State management, as a concept, became a thing. JavaScript frameworks themselves built the concept right in, and third-party libraries have paved and continue to pave the way. This is another example of expanding responsibility. Who architects state management? Who enforces it and implements it? It’s not some other role, it’s front-end developers.
There is expanding responsibility in the checklist of things to do, but there is also work to be done in piecing it all together. How much of this state can be handled at the individual component level and how much needs to be higher level? How much of this data can be gotten at the individual component level and how much should be percolated from above? Design itself comes into play. How much of the styling of this component should be scoped to itself, and how much should come from more global styles?
It’s no wonder that design systems have taken off in recent years. We’re building components anyway, so thinking of them systemically is a natural fit.
Let’s look at our design again:
A bunch of new thoughts can begin!
- Assuming we’re using a JavaScript framework, which one? Why?
- Can we statically render this site, even if we’re building with a JavaScript framework? Or server-side render it?
- Where are those recipes coming from? Can we get a GraphQL API going so we can ask for whatever we need, whenever we need it?
- Maybe we should pick a CMS that has an API that will facilitate the kind of front-end building we want to do. Perhaps a headless CMS?
- What are we doing for routing? Is the framework we chose opinionated or unopinionated about stuff like this?
- What are the components we need? A
Card,Icon,SearchForm,SiteMenu,Img… can we scaffold these out? Should we start with some kind of design framework on top of the base framework? - What’s the client state we might need? Current search term, current tab, hamburger open or not, at least.
- Is there a login system for this site or not? Are logged in users shown anything different?
- Is there are third-party componentry we can leverage here?
- Maybe we can find one of those fancy image components that does blur-up loading and lazy loading and all that.
Those are all things that are in the domain of front-end developers these days, on top of everything that we already need to do. Executing the design, semantics, accessibility, performance… that’s all still there. You still need to be proficient in HTML, CSS, JavaScript, and how the browser works. Being a front-end developer requires a haystack of skills that grows and grows. It’s the natural outcome of the web getting bigger. More people use the web and internet access grows. The economy around the web grows. The capability of browsers grows. The expectations of what is possible on the web grows. There isn’t a lot shrinking going on around here.
We’ve already reached the point where most front-end developers don’t know the whole haystack of responsibilities. There are lots of developers still doing well for themselves being rather design-focused and excelling at creative and well-implemented HTML and CSS, even as job posts looking for that dwindle.
There are systems-focused developers and even entire agencies that specialize in helping other companies build and implement design systems. There are data-focused developers that feel most at home making the data flow throughout a website and getting hot and heavy with business logic. While all of those people might have “front-end developer” on their business card, their responsibilities and even expectations of their work might be quite different. It’s all good, we’ll find ways to talk about all this in time.
In fact, how we talk about building websites has changed a lot in the last decade. Some of my early introduction to web development was through WordPress. WordPress needs a web server to run, is written in PHP, and stores it’s data in a MySQL database. As much as WordPress has evolved, all that is still exactly the same. We talk about that “stack” with an acronym: LAMP, or Linux, Apache, MySQL and PHP. Note that literally everything in the entire stack consists of back-end technologies. As a front-end developer, nothing about LAMP is relevant to me.
But other stacks have come along since then. A popular stack was MEAN (Mongo, Express, Angular and Node). Notice how we’re starting to inch our way toward more front-end technologies? Angular is a JavaScript framework, so as this stack gained popularity, so too did talking about the front-end as an important part of the stack. Node and Express are both JavaScript as well, albeit the server-side variant.
The existence of Node is a huge part of this story. Node isn’t JavaScript-like, it’s quite literally JavaScript. It makes a front-end developer already skilled in JavaScript able to do server-side work without too much of a stretch.
“Serverless” is a much more modern tech buzzword, and what it’s largely talking about is running small bits of code on cloud servers. Most often, those small bits of code are in Node, and written by JavaScript developers. These days, a JavaScript-focused front-end developer might be writing their own serverless functions and essentially being their own back-end developer. They’ll think of themselves as full-stack developers, and they’ll be right.
Shawn Wang coined a term for a new stack this year: STAR or Design System, TypeScript, Apollo, and React. This is incredible to me, not just because I kind of like that stack, but because it’s a way of talking about the stack powering a website that is entirely front-end technologies. Quite a shift.
I apologize if I’ve made you feel a little anxious reading this. If you feel like you’re behind in understanding all this stuff, you aren’t alone.
In fact, I don’t think I’ve talked to a single developer who told me they felt entirely comfortable with the entire world of building websites. Everybody has weak spots or entire areas where they just don’t know the first dang thing. You not only can specialize, but specializing is a pretty good idea, and I think you will end up specializing to some degree whether you plan to or not. If you have the good fortune to plan, pick things that you like. You’ll do just fine.
The only constant in life is change.
– Heraclitus – Motivational Poster – Chris Coyier
Great write-up Chris! Thanks.
A great read. And thanks for the signoff. My imposter syndrome started to kick in by the end.
What a great read, Chris! Such a nicely put together article.
Thanks Chris this for this article.
While reading I was in another world. Very well written.
React is the oldest of the big frameworks and it shows.
Popularity is the simplicity. Great for noobs. But horribly outdated in so many ways compared to Angular, Svelte, Vue
Angular is older than React.
Vue is literally a mix of Angular and React.
Svelte is the only framework trying something completely different, and that’s most likely the reason it hasn’t taken hold.
As for React being great for noobs, Vue is widely considered vastly easier than React, and React is already vastly easier than Angular.
Great article on this topic as always. I’d say security is another growing responsibility as the front-end gets more complex.
I share a similar backstory, being both interested in art and computers when I was younger, and finding a love for all this web stuff through the power and simplicity of CSS. When I was building my first website I remember the frustration before I discovered the Web Inspector in Chrome, which in turn helped me grasp the CSS box model. That was also when I found CSS-Tricks. I ended up dabbling with other programming languages, design, and then oil painting for a bit, before eventually coming back to the web – building sites with WordPress. I never truly got comfortable with WordPress or PHP – just tackled each task as it came and tried to do everything the ‘correct’ way. By the time I was really getting stuck into JavaScript, jQuery already seemed to be on the way out, and I always preferred to avoid using libraries and frameworks back then.
That was 2015. I learnt of Node and npm from Zell Liew’s ‘Gulp for Beginners’ article on here (and I loved using Gulp!). Then in 2016 I read about the MEAN stack, Meteor, React, ES6, Babel, Webpack, modules etc. etc., and felt more confused than ever. I found the ShopTalk Show podcast and felt a bit better (which reminds me that I need to start listening to that more!).
I feel like half the battle is understanding what does what, the problems it solves, and why or when you’d reach for it. Once you start to understand some of the things it helps the other things fall into place and you can build on the knowledge. I’m still behind on a lot of this stuff, and sometimes it’s overwhelming, but other times it’s empowering. There’s so much a front-end dev can do – JAMstack, Progressive Web Apps, SVG animations, the canvas API… you can pretty much build whatever you want and it’s all happening on the web, which has only become more and more convenient to access. Even as a kid in the early 2000s I thought there was something magical about hitting a website and finding out that it’s not really a website at all but some sort of interactive art or game.
Sometimes I’m only doing design work, sometimes I’m only coding, but most of the time I feel more like a front-end designer, a term coined by Brad Frost in this fantastic article ➜
I still tackle each task as it comes and try to do everything the ‘correct’ way, constantly learning and building on my knowledge as I go. And it’s somewhat comforting to know that I’m not alone, and in the end it (sort of) all just boils down to HTML, CSS, and JavaScript.
It makes me happy to hear someone else say that CSS is their favorite as it’s always been my favorite as well and apparently that’s not a common thing.
You’re in good company around here. :)
one of the best post i ever read about front-end. Thanks
Absolutely fantastic piece Chris. As a designer with next to no development skill, it gave me a whole new appreciation for the front end.
Geez, I’m trying to learn front-end Web by myself and this article is making me feel nauseated. How’s a freelance developer suppose to keep up with all this and find work? It’s getting ridiculous.
Great article and sums up my current feelings. In a word; fatigued. I’m a full stack developer and one of my front end projects is a single page web application built with AngularJs. A few years in and having become quite proficient, my boss suggests we should be using Angular2.0 instead. Suddenly I’m expected to be able to write in Typescript, wrap my head around components and effectively learn an entirely new framework from scratch, just to produce exactly the same web app. (I said no). But from then on I have tried to keep up (read catch up) with all the new web technologies so I wouldn’t feel so hopelessly out of touch, but to be very honest there simply isn’t the time. And now on top of all the rest you have cloud based services that can provide a whole new way of creating web applications and all the rest. It’s almost impossible just to keep up with what is out there and what they do, to know if there is a better way to solve the problem at hand.
At this point as a front end developer, full stack developer? I don’t even know how to describe what we do anymore. All I can say is, we basically do it all.
Great article Chris. I couldn’t agree more. For myself who started out with and loving HTML and CSS, front-end development has gotten seemingly complex. Add on thinking about CMS approaches with client projects and setting up access for them to make edits themselves (then training them), and it’s a lot to keep up with. The responsibilities have grown greatly. I’m not quite sure the respect for the needed knowledge in these roles by employers have grown with it as titles seem to stuff in “do everything” for mediocre salaries from what I’ve observed in my geo area. I do question at times if all these changes are really necessary for basic website projects, but there isn’t a lack of options which I suppose is a good thing too. I still love this work, but there’s no doubt that it’s often overwhelming to keep up with especially with so little time to study.
Wonderful read! It’s so nice to know I’m not alone in feeling behind or lacking in certain areas. I like to think I know enough to get any job done thrown at me, but I definitely feel I should be brushing up on newer technologies.
Also, that but about the PHP include()’s gave me a chuckle and a few flashbacks to early PHP programming for me, so thanks for that, Chris!
Great reading!
This is the type of mental therapy I needed. Thank you, Chris, for teasing out the gotchas of our profession into this much needed and priceless write-up.
Thanks for this Chris, it’s reassuring to hear form someone like yourself. I’ve worked this role for nearly 10 years and have been on the job hunt recently. The laundy-list of expectations and different tech that get asked of FED job descriptions is a bit overwhelming at times even as a practitioner.
I feel like it’s gotten confused as it expanded and incorporated more traditional programmer ideals. When it’s come to interviews I can talk passionately about design, users, browsers and all the things you mention above, but now on the day it’s all about Leetcode and Dijkstra. So that’s now on the list.
</sigh>WOW, just WOW. Can I nominate this article as my top 1 article of 2020? Love it, so much to think about. Thank you for putting in words what is hard to express!
FED career is very similar with role of a supporting actor in a movie. A supporting actor is the most critical part of a movie. His/Her acting skills and passion for playing a character is or may exceed than lead hero. They wear many hats like uplifting the script, encouraging coactors, leave a long-lasting impression on audience. In terms of finances, character actors struggle a lot. Their success is mostly based on luck or good commercial script. In their free times, they do theatres, stge acting just to polish or sharpen their craft. On the other hand, A lead hero is already established in audiences mind through status symbol, box office hits etc. Similar to them, A backend developer has already gone through competitive education and experiences to design and build database systems. A frontend developers success is based on your job, how successfully you perform on the job and solve business requirements for your organization. Other things that contribute to your success is your hunger for the craft, sometimes luck and keeping sanity on your journey to become a FED. Cramming a JS framework will take you nowhere. Many people will play a part in your success in this field besides you.
Such a beautifully written article
Interesting article… I definitely felt like an imposter by the end.
I was first introduced to web development nearly 15 years ago, but somehow I’ve managed to avoid learning anything other than HTML, CSS, and WordPress. I’ve often felt like I should learn Javascript and PHP, but there were always distractions and I got away with using fancy WordPress themes and plugins for complex functionality. I finally decided to stop pumping out wordpress sites and start working for a single company. It is simultaneously relieving and anxiety provoking to just have one customer. I feel like I need to understand everything related to our website and streamline all of it. I don’t know what to learn next.
Beyond components and state management, we also have the semantics side – which is cited – but it could be also combined with a lot of SEO techniques: from optimizing the markup to create a fancy structure to using microdata. I believe it may be inside the “performance” topic, because a good part of SEO optimizations come from making the website blazing fast for the user; so the responsability checklist keeps growing every time we think about it.
Nice read by the way Chris! Thank you for this awesome text.
Excellent post! Ironically, it took me 6 weeks to get around to reading it because it’s been buried behind 100 other tabs in my browser — I’m starting a greenfield personal project and decided to use React even though I’ve been doing exclusively Vue development for the past 2 years, so I’ve been getting up to speed with React and Redux and CSS-in-JS and etc. etc.
The reason I’m using React (even though I absolutely hate it compared to Vue!) is it feels like I should know it and that I’m missing out on something by not knowing it.
This article may have just saved that project — I guess I’ll stick with React, but on top of that I had just started reading Go tutorials thinking maybe I’d build the back end of this using it, rather than sticking to something I already know like Sanity, WordPress or Keystone, and if I had kept going on that I probably would have been permanently lost in the weeds.
I’ve been grappling with similar ideas for a while now. The responsibilities of frontend developers has continued to increase year on year while designers are expected to draw pretty pictures in Figma. As a UX designer, I’m desperate to use my skills in semantic HTML, CSS, animations and accessibility but no, I have to log endless defects to bash it into shape and sit on a backlog of enhancements that no one had time for.
I’d be so happy to own these areas that directly affect the user experience. I’d argue they are the experience! The tools designers have to build interfaces lack all kinds of nuance that HTML, CSS and some basic Javascript give you.
Your idea that JavaScript has superseded HTML and CSS doesn’t sit well with me but I have no doubt it’s true. I feel we are drowning in complexity because of it. I’d like to see designers rise to this challenge and take some weight off the shoulders of developers.