While I think it's generally advisable to stay away from snarky Twitter arguments, this touches on some interesting stuff that I think a lot of folks are feeling.

Thomas has a point: web development has only gotten more complicated

Listen to any Q&A session at a dev conference and you'll hear this. It's like THE prevailing talking point right now.

This complication isn't to be ignored. People are feeling it. Super smart and competent devs are understandably nervous about it. The implications of super complicated development setups and build processes probably haven't quite shaken out yet.

What does this mean for training new devs? Training old devs? What are the limits of this complication?

Colin has a point: this complication ain't for nothing

First, you don't have to use any newfangled complicated stuff to build a website if you don't want to. The web is a big place. What is necessary for the success of any given website is as diverse as the human beings who live on this planet.

The requirements of a website might be such that you can do a wonderful job with plain HTML and CSS. The web has also done a pretty great job of backwards compatibility. The websites of 1997 and 2007, if they are still around, probably work just as they did then or better, even if the hardware showing them has changed.

So what is the complication all about?

Websites in 2017, compared to 2007 and especially 1997, are being asked to do far more. Do it better. Do it faster. Work anywhere. Look good doing it.

I don't just wanna see the address of the airport, I want to book my flight, pick my seat, then change it three days later, manage my SkyMiles, print my itinerary, be alerted of any changes, and sync it all to my phone (to name 20% of what an airline website offers). And ship it in 3 months, please.

Developers, looking wide-eyed at that list of requirments, have stepped up to the plate saying "we're going to do this, but we're going to build and evolve the tools that are necessary to do it well." Yes, we're building developer convenience tools. You can think of them as complications if you want, and you aren't wrong, but that's not the whole story. These tools allow us to build what you need without making a mess that would be hard to recover from.

Share this:

Comments

But is that boilerplate necessarily lending itself to a better user experience?

What I see in the increasing complexity of tooling and build processes is not necessarily a focus on better user experience: much of it is on improving the experience of a certain kind of developer.

I’m not arguing that things shouldn’t be more complex than they were in 2007; I wasn’t even doing webdev then and so have no sense of any “good old days.” But the starting boilerplate in that tweet is emblematic of a certain kind of “do everything in JavaScript” mentality that really worries me, especially when it enables devs to ignore issues of accessibility and progressive enhancement.

“These tools allow us to build what you need without making a mess that would be hard to recover from.”

Until you understand every technologies you’re implementing, it’s very easy to make a mess that would be hard to recover from. That’s why developers like me are much more patient to add tools to their setup.

My concern is that we are pressing these time-saving tools onto development projects where they aren’t needed. Some of them are great general purpose tools that every project could benefit from. Some seem very complex and only are needed for certain kinds of projects. Whether it’s a build tool or a CMS, it’s just not necessary for every project.

Complicated jobs require complicated tools in order to keep everything together, as you’ve said. I think the real question is about discerning when to use more complicated tools to handle more complicated processes and when to use simpler tools. I’m of the mind that one should start as simply as possible and work up to complexity. Making the complex the starting point only leads to over-complicating a lot of the development. Many sites are awesome as boring old HTML/CSS/JS websites. There are build tools to help when that grows and becomes a little more complicated. If it gets too messy, bring the site into a CMS or into a larger framework for building sites. It is a progression, though.

A good example is so many people jumping onto React as a solution to everything. “Everything will be JS,” they say. “Why fight it?” Well, it’s just not the right solution to everything. Complex tools are the answer (often) to complex problems or processes. However, they’re not the solution to every problem.

I think training new devs in a large company is different than the work that many freelance or small agency developers do on a daily basis. We should teach the tools of complexity along with the discernment about when to use those tools. Can you use it? Great. Do you know when to use it? That’s the larger question, IMHO.

There are application developers who are making sites/apps for the airline client you mentioned in the article. But there are a lot of developers working in marketing or with small clients who really just need a well-designed HTML/CSS/JS site. Trying to keep up with the latest trends, though, those devs and newbies are taking on processes that are more complicated than they need. They don’t realize that what they do is a lot different than what is happening at Google or Apple or even CSS-Tricks. I think in an effort to keep up developers feel pressured to use all of these new build tools.

BTW, I built my company’s new website using the CSS-Tricks Projects IDE. I really appreciate what you guys have done and want to say that you have taken a lot of this complexities and tried to simplify the process of creating a website. I think it’s great what you’ve done and hope for more success with this project. Your IDE is an example of someone trying to simplify the process of development instead of making it more complicated. I think what you’ve done is built a system that allows the developer to scale the project as necessary during the process. We no longer have to start with overly complicated build systems and then create something overly complex which was dictated by the complexity of the build system.

As far as training new devs is concerned, is it possible for there to be a better delineation between normal development (HTML/CSS, Marketing, Landing Pages) and high-end development (Apps, Enterprise, long-term projects)? I think if a developer could see where he/she is on that spectrum it would help to alleviate some of the confusion about all of the different build tools out there. I work for a large company and we have 1-2 projects that would require those technologies listed in the original tweet. For many of the projects I work on in-house, a simple build with some pre-processing, autoprefixer, and autorefresh works just fine. Anything more complicated would just bog it all down and over-complicate things.

Thanks again for bringing this to everyone’s attention. It’s a good question to ask.

Accepted, but that’s not what the original tweet was – it was for boilerplate, whose audience is devs. My concern is that this is not user-centric, but over-excited dev-centric. Tech-led, not user-led. I accept that your airline example is valid, but surely there is an element of self-perpetuation and wholesale oneupmanship at work here, not to mention an intent to exclude, for all the usual reasons?

I’m sort of a person that gets swayed easily by tooling glam but deep down I know it’s really really really ( rea.. ok u get it) unnecessary unless on demand and posts like this help me drag my face out of that tooling tunnel, save time and try build great UI leading to better UX.

The screenshot shows a very opinionated setup that you will never need if you are making a simple website, so the predicament of the tweet doesn’t exist.

Sure if you are doing advanced application dev you will need a setup similar to this, but if we want to compare apples to apples, was developing apps against the Windows framework in 1997 any easier? I don’t think so.

As an old dev who was building Web Apps on 2007 and before, I can say that things have always been complicated.

We as an industry have always had complicated tools in order to deliver complex web based applications. The early days of building a static site with only HTML/CSS/JS inside of Dreamweaver died by 2002. And if anyone will say that .ASP/.NET tooling was less complicated then JS frameworks today, I will call you a lier.

With the evolution of Rails, this was the first time we as an industry started to really understand what it meant to build actual web based software. And UX was a huge driver in this as people started to demand desktop app like experiences in their web apps. Today, this is so commonplace that yes, building a simple HTML/CSS/JS static site with some jQuery is considered child’s play.

But also saying that things should never be this complicated is like saying that all cars should be like Ford Model T’s and I should be able to work on any aspect of my car with a screwdriver and a hammer.

That’s simply ridiculous.

Conclusion:
Tooling is hard. Tooling has always been hard. Building web apps is hard and expectations are high. Part of the problem is that the browser was never meant to be an application repository, so we have had to build the tools that makes this happen. DSLs, frameworks and opinions is all we have in this fledgling thing we call the internet.

Well said! Adds a good sense of perspective about the original purpose of the browser vs what we have tried to do with over the first decades of the Internet. As a new dev I appreciate hearing your thoughts!

I don’t think the issue is that all that’s available. The number of tools web developers have these days is absolutely wonderful. But to have that much built into your only boilerplate? It makes complexity the default, even for projects that should be simple.

The first step to any build should be to determine what the client needs. Frequently, especially with smaller clients, what they need is WordPress, a few pages, and a theme. Something like this would definitely be overkill.

There is nothing wrong with a boilerplate that assumes you’re building a webapp and not a website, but it’s probably best to have multiple boilerplates and choosing the most appropriate one at the start of whatever project you’re working on.

That’s only half the truth. This stuff isn’t driven by user experience, but by developer experience. That’s not a bad thing, though, because it allows for faster implementation of features that are good for the user experience, so it’s driven by UX by proxy.

I find that as boilerplate and tooling gets more complicated, our dev team gets more siloed. I focus on one thing, someone else focuses on the toolset, someone else focuses on UX, and the next thing I know we’ve got a huge project going that most of us couldn’t replicate if we had to…and working on the actual UI portion ends up like walking on logs on a river because the infrastructure is constantly changing. Frankly, half the complexity is there because most of the team came from a Java background…it “needs” a build process. I’m the only old-school webdev on the team, and we used to build stuff this complicated (not as large, maybe) all the time with no build process and no libraries other than what we wrote ourselves.

If you have a DevOps team that’s set up that boilerplate and it WORKS, or you’re a solo dev / small team dev who’s built that boilerplate and it WORKS, there’s nothing there than prevents you from developing in plain-vanilla HTML/JS/CSS, if that’s your jam. But the tools are there if you need them.

(Which is basically what CodePen Projects did. Pre-configured dev tools ready to deploy at the click of a button, but not in your way if you don’t need them. Not really seeing how that’s an onus on the dev.)

Complaining about the complexity of websites these days is like complaining about the complexity of cars compared to push bikes.

Yes cars are are vastly more complicated than bikes are but cars will also get you to your destination in a fraction of the time it would take you to get there by bike.

No one has to go out and build their own car just to use the tools either. There are frameworks like Yeogurt out there that have done the majority of the building for you. It may need a bit of tweaking but otherwise it’s basically as simple as buying a car from a car dealership except the car is free. You don’t need to know how to build a car, you just need to know how to drive one.

So yeah sure, all of this stuff is optional and it’s way more complex than building sites the old way. If you just embrace the complexity and use these new tools then you will be able to get your work done much faster than you would without them.

A main problem (in my opinion) that we have right now is that people don’t understand the tools they’re using and the long-term impact they have.

Legacy systems being created in a medium like the Web is damn-near inevitable, but what we’re seeing now is that the lifecycle for something that’s “legacy” is somewhere around 3 years — which is ridiculous and emblematic of the greater problem. It wasn’t that long ago that Backbone was, “the hotness,” (kids say that still, right?) and now, if you step into that codebase, it’s pretty much a legacy system.

The user goal of, “I want to book a flight,” isn’t solved by Angular, React, Ember, Backbone, Vue, Flight, Knockout or (whatever). It can be… and in situations where the stakes aren’t very high you should be trying out all the new things because you can throw them away or re-tool at any point, but in high-risk scenarios when people’s jobs and lives are attached to a product that will be, “legacy,” in 3 years we should be using more reliable technologies.

I don’t think we would be as quick to pull the trigger on a lot of these new systems if we took some time to mull over the potential long term implications from product & people management standpoints.

👋

CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. It is built on WordPress and powered up by Jetpack. It is made possible through sponsorships from products and services we like.