Recently I stumbled upon a post in Reddit’s webdev subreddit. The user’s post was about how complexity is killing software developers. Several different opinions surfaced during the discussion. Some of them focused on age-based burnout. Being a longer-tenured web developer, some of these things resonated personally. However, some haven’t been an issue, as I’ve tried my best to reduce complexity over the years as I have worked.
Much of the conversation was about frameworks. Several aspects of web development have boxed-up frameworks available. Front-end frameworks, and backend frameworks, all exist to create some order from the chaos. But much like any toolbox, you get more than you may use. And you may have to learn how to use those tools. If you were to drop a plumber’s toolbox in front of someone, their reaction might be very different than to a carpenter’s toolbox.
Frameworks
I have long advocated against choosing a framework when starting a project. For the most part, the decision has helped to simplify the complex portions of web development. While several workers will pull in something like Bootstrap for their CSS as a first tool, I have never used it. That is unusual because Bootstrap is a great tool. But it’s not for me.
I’ve tried to keep things simple. But I’ve also tried to keep code light. Every framework typically includes a payload of code. Sometimes this can be very light, but other times it can be heavy and detrimental to a project. I’ve seen developers use Bootstrap and have its usage max out at 15% of the CSS included. Its ability to create responsive layout columns is critical for speedy development for some.
The Framework Learning Curve
That highlights the other pain point of any framework. Each has a learning curve. For example, to use Bootstrap, you have to learn how to use it. It’s not instantly intuitive. But it’s not impossible to understand, which is why it’s popular in the first place.
jQuery has long been a staple for me. I started using it years ago because it simplified my JavaScript logic across different browsers. Modern browsers have removed the need for its inclusion. Nevertheless, its longevity has created a comfort level. For example, I would have trouble declaring delegated events at the document level using vanilla JavaScript code. I’d have to look it up. With jQuery, I have the framework memorized.
Therein lies the problem. If asked to code something only using vanilla JS, I would have a learning curve to replace some of the event calls and dom traversal methods I’ve grown used to. If asked to use Bootstrap, I would have to absorb the nomenclature for its many names and ideas. Complexity increases as we add or subtract frameworks or libraries into the mix. Then you have frustrated web developers who only want to write code.
Necessary Frameworks
Some frameworks are necessary for development. For example, if you want to create a React Native app, you must install and use React Native, a tool with React. Also, Expo is yet another tool and library that makes creating React Native applications accessible. To create a native app using their system, I had to learn React and I have to learn React Native. While I eventually found both a pleasure to work with, the framework was the code, not something I could do without working that way.
A CMS can have a pretty rigid structure on the backend of code. While many classic development design patterns can be included, each has its own rules. A great example of this is WordPress Vs. AEM. Both run on apache, but one is PHP-based, and the other is Java-based. Each provides a drag-and-drop block system for creating content. But the underlying block system is unique for each. As a result, the deployment, development environment, learning curve, and global adoption are different.
Complexity in Projects
Another complaint was around the number of different minds mixed into a project. A project using four different approaches to database inclusion could be built with whatever framework was hot at the time. This is known as spaghetti code, a big mess that requires future developers to trace the noodles back to their source. These messes can seem like a one-off nightmare, but they can be pretty standard. Software code is people, pure and simple. You can sandbox developers into your rules if you lead a project, but you risk stifling each individual’s strengths.
Directing things can help. Advocating that others see your ideas as helpful can bring some stability to a project. But time is often a scarce resource. Web development can see things built and destroyed in months or a few years. Looking back over an 18-year career, I see that much of what I have built is now dismantled.
Limited lifespans are a reason why projects can be so unorganized. Most projects don’t last. The brochure website you are making for XYZ Inc will probably be redesigned in five years if they have the money. The tool you built to help manage their jobs may get replaced with a substantial off-the-shelf corporate piece of even more unorganized software. Not much seems to last in this bleeding-edge industry.
It’s my opinion that humans are not comfortable creating disposable products. When you set up to build something, you are inclined to want that result to last for years or even decades. It can be unpleasant to revisit an older project and see the paint peeling or the project ignored. However, a website is not a Mona Lisa.
Evolution
Things evolve. I once created a complete database-driven CMS system used on several websites. Even a 1,000-page plus university website. I was proud at launch, and I should have been. It was pretty good for its time. But today, new ideas have come forth.
In the past, we used things such as TinyMCE to create a pseudo-Microsoft Word editing environment inside a webpage. Users could format and align text and even media in creative ways. In addition, most offered a raw HTML view for more expert editing. If you spent any amount of time responding to client complaints that their pasted-from-Word content didn’t look right on their webpage, then you likely have used this in the past.
From All-inclusive Editor to Blocks
But, things have evolved. Using a TinyMCE editor directly is not the most modern approach. Content editors want to see what they are creating. TinyMce did that, but it didn’t allow that to expand beyond the editing pane. An experience like Gutenberg or AEM enables users to edit many facets of a particular block. They can drag them from place to place or change their size relative to other blocks.
So that is to say, things are more complex now, but better. My CMS was simple, but modern CMSs can visually deliver better experiences to content editing users. So you can be a front-end developer with Gutenberg building experience in your tool belt. However, you build these using React style componentry. So you have also to know how to program in a React style to use these.
Or, You Can Go Simple
You can deliver a high-end, AEM-driven website. It’s all possible. Spend the money. Add Angular, React. Make it as complex as you can get. The CMS editors will love you. They drag around their blocks or components, configure them as far as you’ve allowed, and building the website becomes easy.
Or, you can create HTML, CSS, and JavaScript. In 2021, this combination is still highly relevant. If you want fast page speed scores, go simple. The CMS has to write the page. It can cache it, but it still takes time. Typically there is overhead with these systems. Extra CSS or JavaScript that is loaded. Some have annoying whitespace in the HTML that continues to increase page speed and slow things down.
Or, use HTML. You’ve removed the complexity for yourself. However, the client will need to go through you to make updates. Also, you’ll have to resize and compress images manually if they give you photos. Simplicity is a great thing to sell, but it can cost you time.
Growing Old with Web Development
Another fantasy users had when commenting on the post was manual labor. Commenters mentioned the simplicity of digging ditches. Shovel to the ground, and move the dirt from point A to point B. And it’s true; I’ve said the same about laying bricks. You have 2,000 bricks to lay. Then, to finish, you lay the last brick. Once the project is complete, no project manager is asking you about fixing an obscure brick bug three weeks later. Or a form error that someone is bugging you about on a Saturday.
I was there, though. Before I landed my first web development job, I was working in the hot summer heat. I was outside on days when the high temperature was 18 degrees, assisting a welder and handling tools. Getting cut up bending, shearing, and sawing sheet metal. While programmers love to fantasize about doing manual labor, the reality is that any job can get old quickly. I certainly enjoy hobbies outside of my 9-5. Having them can help me disconnect from the longevity that is the day-to-day.
Surviving burnout is key to a long career. When I started, a 12-hour day wasn’t that uncommon. I typed away on the keyboard so fast that I developed an early case of carpal tunnel. But as I’ve gained knowledge, I’ve learned to work smarter, not faster. Experience over raw talent applies to any career, not just web development.
In Conclusion
Complexity is not an easy thing to solve. However, it is increasing in parts of web development. Seventeen years ago, a company would hire you as a web developer. Today, the position would be a full-stack web developer. Few individuals worked jobs such as front-end only, front-end animation, user experience, quality assurance, search engine optimization, dev ops, and front-end <insert framework here>. The web development ecosystem has grown from a few do-it-all types of people to some very talented and specialized individuals.
More Reading
- A more accomplished senior developer, Tania Rascia (We did both create our first websites on Geocities in 1998)