My Four Most Disliked Web Technologies

I’ve been thinking about writing this article for quite a long time now, but I never actually followed through with it. After all, who am I — as a developer — to critize anything? I’ve never written anything particularly special or important, and all of the tech this article is about has been far more influential than anything I’ve ever done, and it was developed by people who are far more talented than I am.

It’s very easy to criticize. The software development community itself often gets criticzed for being overly critical and toxic. It is negative in places where it doesn’t need to be, and constructive criticism gets lost in all of this. My point in this article is not to rant or be negative. In fact, what I want to do is perhaps provide a bit of relief for people who might agree with me. Maybe you don’t like one of the technologies I’ve listed below for the reasons I’ve described, but everyone around you thinks of it as a necessity.

That being said, I don’t think anything is truly above criticism. All software was created to solve a problem, and software projects in similar families are better suited for particular tasks even though they are often considered pure alternatives. Make your own considerations when selecting a tool or technology and be aware that just because something has its problems or downsides doesn’t mean that it’s not beneficial.

I’ll reiterate that I’ve had these thoughts for years now, so they may be a little outdated.

Bootstrap CSS

Twitter’s Bootstrap has been considered essential for web development for quite some time now. It’s often assumed that a project using HTML/CSS will include bootstrap, and it’s built in by default for many boilerplates and web/mobile development libraries. Bootstrap is so popular and ingrained that it’s often considerered a first class technology for the purposes of hiring, as in

Required: at least 2 years experience with Bootstrap

However, as a professional web developer for over 8 years now, I have a confession to make… I’ve never really used Bootstrap.

I can’t claim to have a very strong understanding of Bootstrap. I’ve worked with it on quite a few projects, but I can’t say that it’s ever really clicked for me. I think it is convenient to have some default styles — particularly if you don’t care too much about a bespoke look, but you just want a webpage or project that looks presentable. However, I’ve usually found myself working around Bootstrap more often than I’ve worked with it.

Bootstrap does have the grid system that people praise, but I don’t understand why this is so awesome. Creating a responsive design with or without a grid is not that difficult to do — much less-so now with CSS flex and grid. Yes, Bootstrap existed before these, but having styles like .col-4 { width: 25% } built in for me ... did I really need that? Is that not something I could have come up with myself?

This may just be purely on me, but I’ve never been able to just use Bootstrap and have everything work the way I wanted it to. I feel like the effort I’ve gone through in cleaning up CSS even using Bootstrap has been about the same as if I had decided not to use it. This is particularly true when trying to work with existing CSS/markup written by other people, but I’m quite sure someone would say that about something that I’ve done too.

I’m also not a fan of some of Bootstrap’s selector names as I think they tie presentation to semantics in a way that the W3C does not recommend. In general I think they do a pretty good job, but class lists like "col-md-8 col-sm-6 col-xs-12" just come out looking ugly to me, and they've honestly never managed to save me that much time. I'm also not sure why I need .btn as well as .btn-default, and this may add more specificity to a rule than I wanted for my CSS. Bootstrap also adds styles to some elements such as <kbd>, and that makes it hard to opt out of those styles. I want to be able to easily override styles from a CSS framework. Finally, Bootstrap is very opinionated when it comes to layout. You may need something like:

<div class=form-group>
<label id=input>Input</label>
<input class=form-control id=input>

I may not want the additional non-semantic div, and I may want to wrap the <input> with <label> and skip the id attribute, but these are not options if I want to work purely with Bootstrap styles.

Bootstrap is not all bad

I actually think that Bootstrap is quite good in principle and in practice. Particularly if you are working with a set layout or boilerplate that’s well crafted to fit with Bootstrap’s styling and philosophy, the page is going to look good. It will look “Bootstrappy,” unless you take some extra effort to do your own styling, but it’s great for getting some simple things out the door if you can understand it.

What I am trying to say is that I don’t think that Bootstrap is really what people think it is. You can’t just drop it in and expect all your CSS problems to instantly be solved. It takes some additional time and effort to use it effectively, and frankly sometimes you are better off without it. At least you may be better off crafting your own solution for some specific pieces rather than trying to force it into Bootstrap’s mold. There are also simpler and interesting CSS frameworks out there like Bulma and Skeleton that may work much better than Bootstrap for some projects.

CSS Preprocessors

Continuing on the thread of CSS, my second most disliked web technology is CSS Preprocessors. This applies to all CSS preprocessors … SASS, LESS, SCSS, and any other ones that might be out there. CSS Preprocessors have become similar to Bootstrap in that they’re often assumed to be a requirement for a web development project. When interviewing, you’ll often be asked whether you have experience working with CSS preprocessors. It’s often LESS vs. SASS too, which I find particularly interesting since I think they do the same thing for the most part — they just have some different syntax.

My guess is that the genesis for most CSS preprocessors was that it seemed like a good side project to work on: making CSS more like other programming languages that people are used to. After all, CSS doesn’t even have variables/aliases or anything that looks like classical inheritance. It can also require quite a lot of boilerplate / repetition. In fact I even attempted to write a CSS preprocessor at one point maybe around the time SASS was starting to take off, but before it really became popular.

People also seem to hate on CSS pretty regularly, but a lot of this has more to do with style rules not working the way they want rather than the syntax or capabilities of CSS as a language.

At this point in my web development career, I would personally choose to avoid using most of the features of a CSS preprocessor. Some things such as the ability to declare constants make refactoring or changing important rules — particularly colors — a lot easier. This is still antithetical to CSS since you may have $darkgreen: #006400, but suddenly you want this to be blue. Sure you can change it to $darkgreen: #000064, but now you have "green" representing somethin that's blue. Still, $darkgreen is a lot easier to remember than #006400, so at least you have the option. I also think that $bordersize: 2px is going to be more often harmful than good.

I can enumerate my issues with CSS Preprocessors pretty clearly:

  • Leaky abstractions — You will still have to deal with all the pain points in CSS one way or the other. Again, most complaints about CSS are just how styles/rules work when rendering and not with the language.
  • Nesting is evil. It often creates more specificity where none was needed. In your homepage.scss, you may have the entire stylesheet wrapped in .homepage { /* nested styles here */}, but there are plenty of perfectly good classes and rules that could be used on other pages. Now you need to add a homepage class to elements if you want them and that means you need more specificity in cases where you may want to override them. I also think that nesting reduces clarity and obfuscates the intended CSS unnecessarily. However, I do appreciate &:hover and the like.
  • This may be a silly complaint since you want your stylesheets to be syntactically accurate anyway. You may also be able to turn this off at some point, but at least in my experience SASS and LESS are all-or-nothing. Any minor syntax issue will prevent your stylesheet or even your code from being emitted properly. This makes debugging annoying.
  • Mixins may be cute, but the way they obfuscate the CSS is not worth it to me.
  • import seems unnecessary to me as it implies dependency. CSS doesn't work that way. This just makes things more confusing, and the _stylesheet-name syntax annoys me. I should be able to name the files whatever I want, and it should be trivial to include them in a specific order.
  • Vendor prefixes are almost entirely unnecessary now. This was a key draw for CSS preprocessors at one point, but I think that it no longer is.

I think that CSS preprocessors have become less and less useful as time has gone on. We have much better build tools available to us now, and browsers play a lot nicer with some of the more advanced CSS capabilities. The only things that CSS preprocessors do actually detract from how you are supposed to be writing CSS.

CSS in JavaScript tools are also becoming more popular now. This is especially relevant for component-based web app development.

Why does it matter if all Preprocessors do is add to CSS?

CSS Preprocessors have caused me pain in the past in spite of their attempt to offer more help. This is mainly for two reasons:

  1. An additional compilation step always adds friction. Being able to include raw CSS is just what I’m used to, and it always works as expected.
  2. Working with another developer’s SASS/LESS/etc. has always been harder for me to understand than working with their CSS. CSS is very extensible and clear. It’s easy to override even if this may create additional unused rules. One deeply-nested SASS rule that I need to update can wind up being a day’s worth of work.


I’ve never liked Bower for one reason or another. I’m a huge fan of npm and yarn at this point for both frontend and back end web development, but I've never understood the draw of Bower. You can include external libraries from all kinds of CDNs or download them directly and include them. I guess Bower did this for you, but having to figure out which Bower package to use always seemed to take as long to me as figuring out a CDN or download link.

I can see bower being beneficial as a build step (alliteration not intended), but it’s completely unnecessary now that npm/yarn can essentially do the same thing, and we have CDNs like and to help us out.

My issues with bower are as follows:

  • bower.json is weird. Being able to use package.json would have been nice. Why do I also need an additional .bowerrc?
  • bower_components is a weird name. I never really liked node_modules, I guess, but I'm used to it now.
  • Even installing a component with Bower is not enough. You have to know what file you’re looking for, e.g. (fake example) bower_components/knockoutjs/dist/knockout1-4-2.min.js. Browserify/webpack/etc. with npm make this unnecessary. If you want to include from a CDN, you essentially have to look this up anyway.
  • Bower may have solved this problem a long time ago, but at least early on there were issues with package name overloading, e.g. knockout and knockoutjs were different packages with different versions and different distributions.
  • When you get right down to it, essentially all Bower does is download a file that you think you probably need. You still have to make sure it’s in the right spot on your file system and make sure that it’s properly sourced in your HTML.

The web development community seems to have moved away from Bower for these reasons. Especially now that it’s much easier to use the npm registry as a more universal package manager for both frontend and back end development, Bower has become unnecessary. Still even early on I didn’t see it as offering much of a benefit over a CDN link.

pug (formerly jade)

Pug is essentially HTML rewritten. All of my criticisms that relate to CSS Preprocessors carry over here. To me it seems like another project that someone thought was a good idea in passing because they didn’t quite like working with HTML. There are leaky abstractions and there is a lot of friction working with a template system that transpiles into something that looks completely different.

I think template engines are great — Mustache, Hogan, even lodash templates and others all work fine… But these look just like HTML. They have a very simple interpolation syntax.

Pug unnecessarily rewrote HTML and — in my opinion, of course — did nothing but remove clarity. I’m not sure where the hatred of < came from. Having <input attr vs. input(attr doesn't actually save you any space at all. You could possibly make an argument for which one looks better, but I don't think it matters much because they will theoretically end up looking like the first one after build anyway.

My main issue with pug is that it’s caused me a lot of unnecessary stress when I’ve been exposed to it. I think that HTML is very easy to work with. It’s very easy to tell when elements, attribute declerations, and attributes begin and end in HTML. Text is also trivial in HTML — anything outside of element declarations will work the way I expect them to including whitespace. None of this applies to pug. It has its own rules, and in cases where you might want to do something as simple as add an additional newline in the markup that wouldn’t even be rendered … well you might wind up with a syntax error that will prevent the whole thing from rendering.

I just don’t think that pug adds anything at all. It’s just a different way of writing HTML that will transpile to HTML you could have written in the first place. At least, you hope it will. This may not be an issue anymore — I haven’t worked with pug in a long time — but at one time the emitted HTML was automatically uglified so you couldn’t even debug from it.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.