Do I have to build everything from scratch?

The web is collaborative, even when you work alone.

Knowing HTML and CSS is like knowing cooking techniques. You can make something original, diagnose problems, and understand what a recipe does. But kitchens still use reliable equipment, repeatable procedures and familiar tools. Web libraries package repeated decisions about layout, color, spacing, accessibility and interaction so you can reuse them.

Some packages offer only focused utilities; some supply an entire set of visual components; some implement a company's design language. Others help with underlying behavior but leave appearance to you. None eliminates the need to understand what your page does for a real person.

One idea, three approaches.

These are illustrated patterns, not live copies of the named frameworks. The links use the site's own styles and remain functional without downloading third-party CSS.

<a href="guide.html" class="my-link">Learn</a>
/* Your project styles .my-link itself. */

<a href="guide.html"
   class="btn btn-primary">Learn</a>
<!-- Requires a compatible Bootstrap CSS build -->

<a href="guide.html"
   class="rounded bg-teal-800 px-4 py-2 text-white">Learn</a>
<!-- Requires compiled Tailwind CSS -->

In every case, the browser still receives HTML and CSS. The difference is how authors produce, reuse and maintain those rules. The styles shown here are intentionally local: the site should not break when a third-party UI package changes.

A map of the library landscape.

Start with the browser.

A three-page portfolio might need only HTML, CSS and perhaps a small JavaScript enhancement. Native controls such as <details>, <dialog> and form validation already handle much of what older libraries implemented by hand.

Bootstrap: a ready-made toolkit.

Bootstrap provides a mobile-first grid, utilities, components and optional JavaScript plugins. It is practical for directly linked static HTML pages. Modern Bootstrap dropped the mandatory jQuery dependency of earlier versions. It provides conventions, not a guarantee that your final content, colors and interaction flows are accessible.

Visit the Bootstrap-origin exhibit ↗ · Try actual Bootstrap 5 on a separate page ↗

Tailwind: compose your own visual language.

Tailwind gives you utilities for spacing, typography, color, borders and layout rather than one required default-looking button. It generally compiles classes into an output CSS file during development or deployment. Tailwind's Play CDN is for development, not production. Static HTML can still use the compiled output: you don't need a browser-side React app to use Tailwind.

Where does jQuery fit?

jQuery solved significant cross-browser DOM and event-handling problems and remains relevant for maintaining older websites and plugins. It has a supported 4.x line, but many common tasks now have straightforward native JavaScript equivalents such as querySelector(), addEventListener() and fetch(). New sites do not automatically need it; older sites should plan for upgrade compatibility instead of assuming it will never change.

A library and a design system aren't the same thing.

A design system is an organization's language and practice: tokens, accessibility standards, interaction rules, documentation, content guidance and governance. A component library is a code implementation that may express parts of that language. Sometimes the same organization publishes several implementations.

Smaller libraries and community components

Alpine.js and htmx can be useful for particular HTML-first interaction styles, while curated visual libraries such as 21st.dev offer design inspiration and component code. Treat these as situational options with changing APIs, packages and maintenance expectations—not permanent defaults. Review license terms, runtime dependencies, source quality, focus handling, reduced-motion behavior and rendering costs before using a snippet.

Reusing components helps—but doesn't certify the result.

A tested component might manage keyboard navigation, focus restoration, and state announcements that would be tedious and error-prone to implement independently. That is a compelling reason to use good libraries. Your actual page still owns the content, labels, contrast, error recovery, sensible visual/source order and end-to-end testing.

A CSS toolkit usually has a different JavaScript cost from a rich React component library. A generated Tailwind CSS file has a different runtime model from the development-only browser CDN. Performance depends on how the library is built and used, not simply how famous it is.

Choose by the actual project.

Break it

Imagine adding three different libraries to build one navigation bar. How many competing naming conventions, styling resets and dependencies are you now maintaining?

Build it

Sketch one landing page as plain HTML/CSS, one with Bootstrap-style components and one with Tailwind-style utilities. Decide which approach is easiest to understand, deploy, adapt and maintain. Then move to how a static page becomes an app.

Read maintained docs first.

• Bootstrap accessibility
• Tailwind's build workflow
• MUI overview
• Fluent 2
• IBM Carbon
• Radix Primitives
• jQuery support policy
• WAI-ARIA practices