Frank Chimero published a new talk-turned-essay, Everything Easy is Hard Again.
May we all be as wonderfully self-reflective and eloquent as Frank one day. There is a lot there, so please read it. Part of the theme is that web design and development has seemingly repetitive cycles that can kick even quite experienced people back down the ladder:
I don’t feel much better at making [websites] after 20 years. My knowledge and skills develop a bit, then things change, and half of what I know becomes dead weight. This hardly happens with any of the other work I do.
And complexity is to blame.
Complexity is one of those in the water topics right now. Kevin Ball wrote “we are in the midst of a massive and rapid period shift in complexity from the backend to the front.” Roneesh just celebrated untangling all this front end complexity in his own mind and shared his thoughts.
I’ve read a good number of responses to Frank’s article as well. I particularly liked our own Robin Rendle’s from the newsletter:
I believe the reason for all this complexity and nuance in the work is because we no longer expect the web to be a series of simple, hyperlinked documents.
Our expectations, as users of the web, have now completely changed.
Websites are machines in and of themselves; they have state, notifications, alerts and warnings, components that appear under certain circumstances, location-aware features and complexity beyond anything we were building fifteen years ago. There are more devices and viewport widths rendering our websites with increasingly difficult performance requirements.
That feels right to me. It’s just what I was feeling when I wrote What is the Future of Front End Web Development?
What websites are being asked to do is rising. Developers are being asked to build very complicated things very quickly and have them work very well and very fast.
Though, Frank points out that even layout, fonts, and images have ballooned in complexity. The cause there I’d argue is the rightful focus (and really, demand for) performance. But reactions to complexity are usually those things plus a dozen or two other things.
Perhaps things didn’t get complicated for no reason, and instead got complicated to compete. The web can do more, so we ask it to do more.
It’s tempting to think that the complexity comes entirely from that moreness. Embracing more of the potential of the web, playing catchup with native apps, and building more powerful tools for people. But I’m sure the whole story is more (ahem) complicated. Someone once told me the reason they think developer tooling has evolved and gotten more complicated is that developers generally aren’t asked to innovate on the business and product side. They build what they are told to, so they use their smarts to innovate on their own tools.
It depends though. A few personal examples.
I’ve been running CSS-Tricks for over a decade. It’s a garden variety WordPress site, and while it’s certainly evolved, it’s not all that much more complicated today as it was in the first few years. I’ve gotten better at working on it, in part because it’s changed so little that I’m more comfortable doing that work. I know just what all the spinning gears do and just where to put the oil, most of the time.
On the other hand, through CodePen, I’ve experienced a long product development which started fairly simple and has come to extreme complexity. We sometimes question if we’ve overdone the complexity, but for the most part, each step in that direction has been a response to make something else, ironically enough, less complicated. One example of that was the adding of React’n’Redux’n’Friends, which was a step up in the complexity of the development workflow, build, and deploy processes but, believe it or not, was a step down in a complexity of the codebase. These tools help us build faster, debug easier, stay well tested, and provide a performant experience, to name some of the benefits. We didn’t add tooling just for kicks; we added tooling because we had growing problems to address.
Not everyone has the same problems. The web is a big place is a phrase I see thrown around sometimes, and I like it. Over a billion websites, they say. A big place indeed.
Check out Dan Cederholm’s favorite website:
It’s not responsive. It’s not optimized for iPhone. It looks blurry on a Retina display. It doesn’t use the latest HTML5/CSS3 framework. It doesn’t have a thoughtful vertical rhythm. The fonts are nothing special. It is neither skeuomorphic nor flat. It doesn’t have its own favicon. It doesn’t have a native app or Twitter or Instagram. It doesn’t use AJAX or SCRUM or node.js or Sinatra. It doesn’t have an API or an RSS feed or VC funding. It hasn’t been featured on a prominent tech blog or won an award.
It tells me the soups of the day.
I suspect it doesn’t need any more complexity, and literally nobody is advocating it does. That’s why that the web is a big place sentiment is so useful. We talk about complexity, but it’s all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don’t just break.
I’ll bet the bits in Frank’s essay about web layout will strike a chord to many readers of this site. Frank makes the connection between table layout and grid layout. It’s not a rare sentiment. For example:
Let's not fool ourselves. CSS grid = <table> and you know it / #100daysofcode
I’m sure Frank understands the benefits of the new grid layout (e.g. try re-arranging a
<table> at a media query breakpoint), but the sentiment was more about cycles than a deep technical dive.
I’d say a reasonable argument could be made that, with CSS in particular, things are easier these days. CSS of old had us biting our fingernails about cross-browser support, scattering vendor prefixes throughout our code, and (lol)
saying a prayer to the box model. Eric Meyer, despite publishing a heavy tome of CSS knowledge lately, says:
CSS has a great deal more capabilities than ever before, it’s true. In the sense of “how much there potentially is to know”, yes, CSS is more of a challenge.
But the core principles and mechanisms are no more complicated than they were a decade or even two decades ago. If anything, they’re easier to grasp now, because we don’t have to clutter our minds with float behaviors or inline layout just to try to lay out a page.
Swinging it back to developers innovating on their own tools for a moment, another consideration is the impact of site builders on our industry. I’ll always recommend a site builder app in the right circumstances. Does your photography business need a portfolio site? Your bakery a homepage? Your custom scarf site a blog and eCommerce site? Assuming this is a sub-$10,000 job, I’d rather see you use a specialized site builder product than hire out the job to anyone who is going to build something entirely custom. I don’t wanna go too far down that rabbit hole, but suffice it to say, because I’m not alone in that thinking, the market for low-end custom design and development work is rather gone.
There are more developers these days working on in-house teams or agencies with big-ticket clients. That is, more and more developers on large-scope, long-scale, highly-complex jobs. So that’s where their minds are at. Big complicated problems with big complicated solutions. That’s what gets talked about. That’s what gets blogged about. That’s what gets argued about. That’s the topic at a lot of conferences I’ve been to.
While you certainly can make a soup-of-the-day website with an
index.html file and FTP, blog posts about that are fewer and farther between and don’t get as many claps.
Shout out to Dave Rupert, my friend and ShopTalk Show co-host, who’s been pushing back against complexity in all its forms for as long as I’ve known him. I’m still trying to catch up.
While there certainly are use cases where modern tooling and frameworks are helpful, I do feel that most web applications are much more complex and bloated than they need to be.
While there are many an SPA that are slow and bloated, advertisement networks seem to be the absolute worst.
I agree on this and would like to add the following.
Its not so much that HTML or CSS is very hard its all the tooling/frameworks that make it hard. If you think about it that we have created a workflow that needs to compile our code to work for a language that needs no compiling (look at you SASS, LESS, HAML, etc).
Just have a look at what you need to install on your pc to start developing its kinda weird dont you think?
It worry’s me with all the hype trains going around that solves problems that don’t exist (css-modules from postcss for example).
As a young freelance website developer and recent college graduate, I feel that there is way too much new stuff to learn.
You don’t need to learn everything.
Simply focus on the skills you need to learn to complete your current project. Then move onto the next project :)
I still miss old days, old pngfix, hoverhtc. But we have to move on with new tech, no matter what.
I read and enjoyed Frank’s essay and this is another great piece, but an overriding feeling that has just started niggling away at me is about satisfaction. In this constant chase to keep up, and the inescapable feeling of work and tools becoming outdated almost instantly, I’m struggling to think of the last time I got some genuine satisfaction out of my web work. I can’t remember feeling happy with any of it, it can always be improved, updated, done better, and it’s never really done. Not sure if anyone else feels the same or if i’m an outlier, but this just dawned on me. When I do other work, like graphics, lettering or working on my house it feels great completing things, I can look back and admire it, but that same feeling just doesn’t seem to there with this stuff.
I’m a relatively new web developer who got my start making “low-end websites” with self-taught HTML, CSS and WordPress just as site builders were storming the horizon.
I was chatting with my Angular guru buddy the other day and he casually mentioned that jQuery was “old news.” My brain registered that as “is dead” and I think I felt that deflating angst veteran web professionals are starting to complain about. Then I googled “React tutorials.” I can hear readers chuckling that I’m already too far behind. But I’ve been busy settling into a new job, learning the way things work HERE, and it’s only been like six months!
My favorite takeaway from Kevin Ball’s piece: “…one can make a good living as an API developer using Ruby on Rails without spending half of your work life racing to keep up.” Hmm. I could get into that for a while.
Super valuable Chris, couldn’t agree more. While i don’t miss the days of spacer.gif, the expectation from business to keep up with ‘bleeding-edge’, and still have sustainable maintainability in the code is a tough tightrope to tread upon.
Some things have become easier. For building a basic website, you can do more with less tooling these days: once you get the hang of CSS grid, CSS variables and some basic DOM manipulation via JS, there is a lot that you can do these days without any frameworks, jQuery or even installing Sass.