Skip to content(if available)orjump to list(if available)

Thank You Bootstrap 1

Thank You Bootstrap 1

55 comments

·February 10, 2025

danpalmer

Something that I've often wished, as a primarily backend focused engineer, often without frontend support, is for designers or perhaps design engineers, to pretty much build Bootstrap themes. That would let me code to the Bootstrap docs (which are pretty good), while allowing us to brand or customise whatever we're working on. I've seen even contract designers push back on this idea, suggesting that doing such a thing is beneath them, and I've heard frontend engineers push back on using Bootstrap as the framework.

This has always struck me as odd. From my, admittedly naive, point of view, Bootstrap seems to be a reasonable framework for customisation. I've done this myself in personal projects. It just doesn't seem like others see it as a design system framework in that way. Few teams have capacity to develop their own design systems, but a Bootstrap theme seems to be most of the benefits with not a lot of effort. That said, I've never been particularly enthused with third party Bootstrap themes, they seem to have too much custom work and lock-in.

What am I missing? I've not used Tailwind, but it seems like perhaps the goal of Tailwind is to do something similar?

thiht

> I've not used Tailwind, but it seems like perhaps the goal of Tailwind is to do something similar?

I'd say that's the opposite of the goal of Tailwind.

Tailwind is not like Bootstrap, Tailwind is to build your own design system component library. Tailwind makes it easy to build unique designs at the cost of having to make the design yourself. Bootstrap makes it easy to build a website with a premade design, at the cost of having the same design as your neighbour.

As someone who used Bootstrap / Semantic UI a lot in the past, I've finally concluded I won't be using them anymore: they ALWAYS end up being too rigid for what I want to do. It also invariably ends up breaking things in minor updates. Tailwind is freeing in comparison.

Etheryte

I've seen both sides of this idea many times, and from my personal experience, this idea looks good on paper, but usually implodes in practice. Bootstrap gives you a baseline quickly, but what pretty much universally happens is that at one point a feature requires you to venture outside of its constraints and that's when the trouble starts. Overrides and extensions, then something changes in the underlying theme or you update Bootstrap for some adjacent reason, that means more changes to the custom logic and eventually it's a big ball of yarn. Since you're working within the confines of Bootstrap and what it does and doesn't let you customize, you're never in a position where you can refactor all of it to make complete sense. In my opinion, if you're already working with a designer, it's way easier to build what they delivered from scratch, rather than try to bend Bootstrap over backwards to fit over it.

memhole

You’ve described it exactly. Bootstrap is great for concept. It’s easy to understand. Once you need greater customization look for something else.

BillSaysThis

I, having decades of frontend development experience, asked this of my VP once. He said no designers would work for us if we did this.

danpalmer

Can you give any more insight as to why? Designers always seem to want to build design libraries, I don't understand why they wouldn't want to use a common API as the basis for that so that there's a contract of sorts with developers.

sleiben

I would assume their thought is, that it limits their creative spirit and in general is too technical. But they start (as 2 people teams) on figma a complete own design lib with a lot of variables and custom components which look the same like any other lib.

emayljames

Things like Tailwind take the core concepts of bootstrap and build and improve on it on a grand scale. It is like comparing jQuery (bootstrap), to React (tailwind).

caspper69

Having spent a decade in the late 90s / early aughts doing PHP web development (including Bootstrap), I can't for the life of me figure out why modern frameworks need hooks and a shadow DOM and a component model.

I dabbled for a bit about a decade ago, and the first and last JS framework I worked with was Angular2 (which was in beta); this was right about the time Typescript was getting started (in fact, I distinctly recall that a substantial number of popular JS libraries didn't even have TS bindings at that time).

I think I didn't really want to look stupid by asking in public on HN, but given recent events, I think that ship has sailed :)

Other than analytics, what in the world do we need all of this JS for? I used jQuery (sparingly I might add), and it did its job.

Most web forms don't even have that many components.

I honestly don't mean to insult anyone, and I know I must just be naive about something.

Because otherwise, HTML/CSS aren't that complicated. Messy? Sure. Large? Yup. Duplicative in areas? 100%.

So what am I missing? What exactly does React do so well that the added complexity and resulting slowdowns become an acceptable tradeoff?

krab

You split your app into components and separate it from the backend using an API. This allows you to build a bigger development team. The result will be less efficient but more featureful, more polished, will have someone on call and a better bus factor.

It's a trade-off.

arkh

> The result will be less efficient but more featureful, more polished

Not sure about polished. Just see the Atlassian wasteland: lot of features, I'm sure huge and numerous teams. Ages to load a page or anything. Multiple API documentations depending on what you need. The integration between tools is mostly random. "Simple" feature asked for a decade ago never got implemented.

caspper69

I don't mean to be obtuse, so let me make sure I have this right (and please afford me some leeway on my gentle ribbing, I assure you it's all in good fun and nothing personal):

A framework will allow me to separate the app from its backend?

The web, by its very nature, runs on a client/server architecture, so it has long been possible to separate the front from the backend via an API (we can argue the level of difficulty involved, but I would say the friction was substantially reduced with the introduction of XMLHttpRequest).

So aside from separation via API, according to your list, that leaves us with (1) a bigger development team; (2) a less efficient result; (3) a potentially more polished result (I added possibly, because I'm dubious about the claim that a JS framework makes the result more polished- does it make the browser render the HTML components in a higher resolution or higher color bit-depth?); (4) someone on call (like an employee or group of employees who have to be on call at all times? or am I misunderstanding?); and (5) a better "bus factor" which is a term that I am actually unfamiliar with (is this jargon, or is it an actual technical term/concept?).

Which of these are technical in nature, or rather I should say, which of these factors has anything to do with software (in the abstract) or actual code or markup (in the concrete)?

Now for my more serious follow up: just level with me; is this all bs? Do people use these frameworks because they don't know any other way to do it? Is it a code / organizational issue? Did people take the "separate all code from all HTML/CSS" advice too far and adopt it as dogma? Do people find the event model in JS to be too complex or unreliable? Is it an issue of people getting hooked on frameworks while JS was in flux so they needed the polyfills? Is it that people fell in love with TS, which naturally led to framework-itis?

I feel kind of like I went to the future, and everybody rides exercise bikes everywhere they go to stay in shape, but since exercise bikes don't go anywhere, they have to be put in the bed of a pickup truck first, you know, to actually go places, but then there was a gas shortage, so it was decided to save gas we'd all carpool by putting 5 pickup trucks on a single semi-truck flatbed. Because that's just how things evolved.

So now you're explaining to me why I see people riding exercise bikes on top of pickup trucks that are themselves being pulled 5 at a time on the back of a semi truck, and you're looking at me like I'm out of touch because I can't figure out why you guys can't just walk the 250 feet to the store across the street.

Zanfa

In my experience, a lot of developers have a very limited grasp of what the browser can do for you without React. If all you know is React, everything looks like a single-page application.

emayljames

I have a very good grasp on jQuery and a good grasp on SPA frameworks, and as soon as you cross that barrier into a complex application, jQuery is completely unsuitable in maintaining a clean state.

dartos

The real reason is because it’s faster (or was in 2014) to diff 2 versions of an optimized in-memory tree than it is to use the dom API to diff live html (where any change might trigger the browser’s layout and rendering pipeline)

That’s why react opted for a virtual dom. Many frameworks followed suit.

We’re a decade on at this point and JavaScript runtimes are much faster

Tade0

My career started in the transition period between jQuery everywhere and frameworks everywhere. Much of my work throughout the years was picking up after others who left/were fired.

Main difference that I noticed between that time and the present day is that you hardly ever see unfixable monstrosities made by a lone-wolf one-man-army developer any more - at least in the Angular space, where as long as you're familiar with the convention, you'll manage. Much of that is thanks to TypeScript and the possibility to communicate to future maintainers what was your intention without writing paragraphs upon paragraphs of documentation.

Of course the tradeoff is that it's all pretty heavy right now, but that's what frameworks like Svelte or SolidJS and generally the concept of Signals try to address.

My take is that the moment we get Signals into the JS standard, this will all neatly fold like rows in Tetris.

arkh

> So what am I missing?

Money and resume driven development.

Just being a webmaster integrating a simple design could be done by "anyone" so not paying so well anymore. So came the idea: now we're not doing websites, we're doing webapps. Suddenly fresh-out-of-school engineers can try to implement GUI concepts they vastly misunderstood, but in javascript and limited by the DOM. So that's years of work to maybe get a tenth of the performances of desktop apps: javascript interpreters to optimize, browsers, frameworks and then the apps themselves.

Add the rise of smartphone apps and you even get the excuse of "we made an API for the apps, so why not use it for the frontend".

gedy

> What am I missing?

You're not missing anything, companies like mine have done just this.

We supported a messy situation of 7 webapps using different technologies looking 7 different ways. Once we got them to use Bootstrap, was a cinch to consolidate to a single company brand.

The "big reskin" UX was gearing up for was as simple as a new theme, and was done without any drama. They were almost disappointed it was so easy, ha.

I like Tailwind, but it's a rotten fit for reskinning (not just changing font or colors). I'd much rather have a single .card class, vs "p-3 border-1 shadow-sm rounded-2" or whatever. Not all of us have have the luxury of a single modern app all using the same React components.

rzzzt

The secret: use SCSS or LESS to pack the combined effect of "p-3 border-1 shadow-sm rounded-2" into a single class.

gedy

I agree, but that approach seems to be uncommon or at least discouraged by the Tailwind creator.

I'd actually recommend Tailwind shops use the DaisyUI plugin which gives component classes similar to Bootstrap.

spyke112

Sooooo mixins? You can do that with Bootstrap as well.

leoqa

Most companies will have a team building a component library which is equivalent.

danpalmer

Functionally no companies have a team building component libraries.

Tech companies with >100 employees might be more likely to, but that leaves most companies without that team, where they may still benefit from using Bootstrap as the basis for it.

nullpoint420

Even those that do use ReactStrap and pretend they made their own design system /shrug

zoomTo125

Every bootstrap site looks the same no matter how you customize it. Designers quite often focus on the details. They're the type of person who gets offended if the icon is off by 1 pixel. It is fine for most of us with no artistry brain, but may be boring to see the same bootstrap theme for them. Anecdotally, it is like clothing choice in different gender. Majority of men are fine wearing the same tee everyday, but most women prefer to wear different styles of clothes on each day.

Cthulhu_

> Every bootstrap site looks the same no matter how you customize it.

How would you recognize a bootstrap site if this is false though? Sounds like confirmation bias, that is, "all sites that I can recognize as using Bootstrap use Bootstrap"

Humphrey

I clicked this totally expecting this to be somebody still using Bootstrap Version 1.0 haha

ChrisArchitect

Yeah

Title of submission probably should be simply Thank You Bootstrap.

And next part when it's published add the Part 2 etc.

faizmokh

I was expecting the same too. Somewhat disappointed now.

buster

I can recommend halfmoon css for a visually pleasing nice drop in replacement.

maxloh

That doesn't seem as well-maintained as Bootstrap.

The last commit was half a year ago.

gjvc

Visually, bootstrap 2.23 was peak, before the flat bullshit took hold.

dmix

bootstrap 5.3 optionally supports gradients natively and uses shadows on their homepage https://getbootstrap.com/

gedy

To be fair, a lot of people miss that Bootstrap is themeable, and what you are complaining about is just the default theme. E.g. check out https://bootswatch.com for examples, many aren't flatsville.

I've had confused conversations with UX, etc over the years when they say "We can't use Bootstrap - our colors are totally different!", etc.

harlanji

I'm hearing I need to downgrade the Bootstrap in my suite? (A young addition).

Which is great because Bootstrap 2-3, whenever I used it, was pleasant.

I wasn't aware of the development timeline, thanks for the lead. Not flat is appealing.

I picked ExtJS 2.0.2 for a specific reason, seemingly rando old trusty version as base.

evbogue

Agreed.

You don't need a css framework to do a flat UI, just remove all of the borders from every element.