Select Page

Complexity

Complexity

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: