Coffee Store
Proving that fundamentals matter more than frameworks
Coffee Store is a single-page e-commerce template built with vanilla HTML, CSS, and JavaScript. In an industry obsessed with the latest frameworks, this project was a deliberate return to fundamentals—proving that you can build a polished, functional product page without a single npm install. It's a reminder that understanding the platform matters more than abstracting it away.
The Challenge
The frontend ecosystem has a framework addiction. Junior developers often jump straight to React or Vue without understanding what the browser gives you for free. I wanted to challenge myself: could I build something that looks and feels modern using only the technologies that work everywhere, forever?
The secondary challenge was scope discipline. Without a framework's structure, it's easy for vanilla projects to become spaghetti. I needed to prove that clean architecture isn't framework-dependent—it's a mindset.
The product scenario was straightforward: a coffee shop's online presence. Hero section for brand impact, product menu for browsing, reviews for social proof, and contact for conversion. Simple requirements, but the execution had to feel premium.
The Strategy
My approach was constraint-driven development. No build tools, no bundlers, no preprocessors. Just files the browser understands natively. This forced every decision to be intentional—no hiding complexity behind compilation steps.
For CSS, I leaned heavily on custom properties (CSS variables) for theming consistency. A single color palette defined at :root meant changes propagated everywhere. No Sass needed—the browser handles this now.
JavaScript was minimal and purposeful. Add-to-cart interactions, smooth scroll navigation, and a simple review carousel. No state management library—just DOM manipulation with clear separation between data and presentation. The entire script is under 100 lines.
I prioritized progressive enhancement. The page works without JavaScript—you can browse the menu, read about the brand, see reviews. JavaScript enhances the experience but isn't required for core functionality.
Execution
Semantic HTML Structure
The HTML follows a clear document outline. Each section has a purpose: header with navigation, main with distinct article regions, footer with contact details. Screen readers can navigate by landmarks, and search engines understand the content hierarchy.
I used modern semantic elements throughout: <article> for product cards, <figure> for images with captions, <address> for contact information. These aren't styling choices—they're meaning choices that happen to style well.
The navigation uses anchor links for single-page scrolling. No JavaScript router needed. The browser's native behavior handles scroll position, back button, and URL fragments. Why fight the platform?
CSS Architecture
The stylesheet follows a component-mental-model despite being flat CSS. Each section's styles are grouped and commented. Class naming is BEM-inspired: .menu__item, .review__card, .hero__title. Specificity stays low and predictable.
Custom properties define the design system: --color-primary (that coffee brown), --color-surface for backgrounds, --spacing-section for consistent rhythm. Changing the theme means updating a handful of root values.
Responsiveness uses CSS Grid and Flexbox with no media query overload. The menu grid is auto-fit with minmax()—it adapts from 1 to 3 columns without a single breakpoint. Modern CSS is powerful enough that most layouts 'just work'.
I used clamp() for fluid typography: font-size: clamp(1rem, 2vw + 0.5rem, 1.5rem). Text scales smoothly between viewport sizes. No JavaScript resize listeners, no FOUT from font-size switching.
Minimal JavaScript
The JavaScript is enhancement, not requirement. Cart functionality uses a simple array for state and localStorage for persistence. DOM updates are surgical—update the cart count badge, show a toast notification. No virtual DOM diffing needed for this scope.
Smooth scrolling is CSS-native (scroll-behavior: smooth on html) with JavaScript fallback for older browsers. Feature detection, not browser detection. The polyfill is 5 lines.
The review carousel uses CSS scroll-snap with JavaScript arrows for navigation. Users can also swipe or drag natively. The carousel works perfectly with JavaScript disabled—the arrows are just convenience.
No build step means debugging is transparent. View source shows exactly what runs. console.log works without source maps. Deployment is copying files. There's clarity in simplicity.
Performance by Default
Without a framework's runtime, the JavaScript payload is under 5KB. First paint is essentially instant—there's no hydration delay, no spinner while React boots. The browser streams HTML and paints as it parses.
Images use native lazy loading (loading='lazy'). The browser handles intersection observation, priority hints, and network scheduling. Why reinvent what the platform provides?
Font loading uses font-display: swap with system font fallbacks. No layout shift, no FOIT. The webfont loads asynchronously and swaps in when ready. Users see content immediately with good typography.
Lighthouse scores are near-perfect without optimization work. When you don't add complexity, you don't need to optimize it away. The performance budget is met by default.
The Impact
The site loads in under 1 second on 3G throttling. No framework can match raw HTML/CSS delivery speed. For a coffee shop's online presence, this matters—customers on slow café WiFi still get a fast experience.
The codebase is approachable to any frontend developer regardless of framework preference. A React developer, Vue developer, or someone who learned HTML last week can all read and modify the code. No framework-specific patterns to learn.
Maintenance is essentially zero. There are no dependencies to update, no security vulnerabilities in node_modules, no breaking changes in major version bumps. The site will work the same in 5 years as it does today.
The project became a teaching tool. I use it to explain to junior developers what frameworks abstract away—and why understanding those abstractions matters even when you use React or Next.js daily.
Learnings
This project reinforced that frameworks are tools, not requirements. React solves real problems—component reuse, state management at scale, team collaboration. But for a single-page template, those problems don't exist. Choosing vanilla wasn't nostalgia; it was right-sizing the solution.
CSS has evolved dramatically. Custom properties, Grid, Flexbox, clamp(), scroll-snap—these features eliminate 80% of why we used to need preprocessors and JavaScript layout libraries. Modern CSS is genuinely powerful.
The discipline of no dependencies forced better decisions. Every line of JavaScript had to justify its existence. In framework projects, it's easy to npm install a solution. Here, I had to weigh complexity cost for every feature. That muscle is valuable everywhere.
I won't use vanilla HTML/CSS/JS for complex applications—but I'll always understand what the platform gives me before I abstract it. This project was a reminder that the best code is often the code you don't write.