I’ve been a front end developer for ten years. I’ve been thinking about front end development as a discipline a lot lately. As I grow in my career and continue to reflect on our place within technology, my thoughts tend to drift. They drift away from the day-to-day work of learning new frameworks, exploring new tools, or solving complex problems in novel ways.
Rather than thinking about the “what” of our work, I’ve been thinking about how and why we do it. Things like:
- How does “front end” fit into the industry?
- How will that change over time?
- Where do we want it to go?
- What kind of things do we want to be doing in five, or ten years?
- What are the best ways we can use the rapidly shifting sands of the technical landscape to our advantage?
- How do we negotiate a world that is sprinting towards immersive technological experiences like augmented reality, virtual reality and blurring the old lines between “back” and “front” ends?
There’s no right or wrong answers to these questions…from what I can tell, there’s often two opposing answers that both seem to make sense. Here’s my attempt to make sense of it…
The Internet Got Shrinkwrapped
The notion of doing the heavy-lifting of building the internet is largely gone for most people who create things on the internet. Everything is a product.
Like me, for example, writing this blog post. I’m not writing every <img /> tag or headline in semantic HTML like the old days. I have Medium to do it for me (yay!). As products take the “tech” out of the internet, things become easier to use and quicken methods of production. Some of that “productization” has bled into front end development.
+ P R O
The increasingly complexity is a net-gain for our discipline. The web has finally seemed to reach a point of reasonable standardization. Browsers no longer fight over the specs, and seem to embrace new things like CSS grid at a faster and more uniform pace. This makes trying new things easier, even if the amount of new things have exploded from a slow drip to a firehose.
The productization of the web frees us up to be innovators. Not fighting flame wars over the minutia of semantics gives us time back to explore and create new systems, frameworks and architecture that solve problems in innovative ways.
- C O N
As the internet becomes more productized, it becomes harder for the practitioners to keep up with an increasing pace of change, or for new developers to get started. The time needed to “get good” at building the internet has grown by orders of magnitude.
In it’s infancy, you could learn the basic languages of the internet in a couple of days. For a scientist at Stanford who wanted to share a paper with her colleagues, marking up a text document with HTML was all that was needed.
Flash forward to the early 21st century, after the dot com bust, and the level of complexity was still relatively low. At that time, the internet had finally “arrived” and had mass adoption, yet to build something that conformed to industry standards relied heavily on the same technology the industry had been using for a decade.
Now, one could argue that the internet’s purpose has shifted from sharing documents to a software-delivery platform, and the relative level of complexity has exploded alongside that shift. Software is complex, and now so is the internet.
Note: listen to this episode of Track Changes if you’re interested in more discussion around this.
More tortoise, less hare
Frank Chimero chronicles an interesting take on the cyclical nature of the tools and technologies we use in web development in “Everything Easy is Hard Again.” Although I’m a little weary of some of his points once you take them to their logical conclusion, I love his appeal for slowness, for intentionality, and for organization.
+ P R O
If we embrace the constantly changing nature of how we do the work of building the web, we are littered with an endless pipeline of solutions to any problem we may encounter:
- Need an elegant templating framework? VueJs has you covered.
- Need a way to minify your code for production? Webpack is your best friend.
- Looking to make CSS hassle-free? There’s Stylus, LESS and SASS — take your pick.
- to be continued…
It’s never been easier to plug-and-play tons of different solutions for any potential problem you face.
- C O N
Having all the answers at our fingertips isn’t necessarily always good. Constraints are often your best friend.
Let’s continue that list:
- Need a base64 encode an image? There’s a node module for that.
By adding things that clearly benefit us and only introducing a minimal level of complexity for other developers down the road, we might make more future-proof decisions, and the things we build may last a bit longer.
Talking about being more intentional with our code and our development process reminded me of a talk Austin Kleon gave this year. Austin is an artist and writer based out of Texas who explores broad contexts like “creativity” while bringing them down to earth.
As Austin says, when in doubt, tidy up.
Usually when people talk about tidying up, they tidy to de-clutter their life and simplify, but that’s not the reason I tidy up. I tidy to come into contact with something special, that I’ve forgotten about, that I can now use.
- Austin Kleon
What do I want to be when I grow up?
+ P R O
- C O N
Career paths for front end developers can be unclear, as the discipline matures, it collides into other areas of expertise (server-side technologies, progressive web apps, native, etc…). That blurs the lines between “front end” and everything else, begging the question, “How much do these labels matter?” and “What does it mean to be a senior front end developer?”
What is our value?
+ P R O
As the industry trends towards design, custom interfaces are increasingly valued on projects. While WYSIWYG platforms have commoditized marketing websites, and democratized the internet to some degree, web applications are still almost exclusively a “custom” experience.
- C O N
While the industry has started to see the value of design (and designers) more clearly, you could argue that front end development has not caught up. If designers have earned their “seat at the table,” the front end developers are probably at the kid’s table, or cleaning up after dessert (that metaphor got away from me a little bit).
While there’s been big strides in concepts that increase both the utility and efficiency of the web, like progressive web apps and CSS grid, those ideas are often relegated to a delivery phase. As a discipline, we haven’t yet truly found a way to get in early and drive things from a front-end perspective. How can we inform the success of a project and multiply the value software will bring to a client? Why should they care about front end development?
Knowledge vs understanding
+ P R O
If you think of the internet as a vast network of information, you could say that front end development is uniquely positioned to enable all that knowledge to be understood. By paying attention to the design, architecture and performance, we’re ultimately responsible for how each user experiences the web. That’s an exciting place to be!
- C O N
As a discipline, I think we could benefit from drinking our own Kool-Aid. If we focused our client-facing analytical and technical skills in on ourselves, I wonder what we’d discover. Yes, we have a lot of knowledge. We know the latest libraries, processors, and frameworks, but what is it that we do not understand? How can we innovate? By focusing so much on the technology, are we missing the forest for the trees?
Working in a discipline (and industry) that changes so frequently is both exciting and frustrating at times, as with every new opportunity, comes a cost. I hope as a community, front end developers can think openly about some of these issues, as we continue to grow our skills, tools and reach as a group of passionate technicians.
It’s up to us to determine where we want to go in the future, and I think figuring out where we are now is a good place to start.
In The Web Performance Handbook, you will learn the core concepts of web performance, the tools you need to build performant websites, and how to make good performance part of your team’s workflow.
Build better web apps, increase conversion times, and charge your clients more by using what you learn in The Web Performance Handbook.
This article is an extrapolation of something I wrote two years ago. I’ll include a link here: