Philosophy

Why Bascik

The guiding principle behind Bascik is simple: use what already exists. Do not invent new syntax, do not add a runtime, do not get in the way. HTML, CSS, and JavaScript are enough.

The Problem Bascik Solves

You've been here. You're building a straightforward site and you've copy-pasted the same navigation markup into every page for the third time. You Google "how to reuse HTML on multiple pages without a framework" or ask ChatGPT "HTML components without React." The answers are always the same: Web Components (verbose, requires JavaScript to render), server-side includes (awkward, server-dependent), or a full framework (React, Vue, Astro) that feels like enormous overkill for something this simple.

Building a website has never been simpler at the language level. HTML structures content, CSS styles it, JavaScript animates it. Every browser speaks all three fluently. Developers have spent thirty years learning them, and documentation is exhaustive.

The problem is organization, not language. Once a project grows past a handful of pages, copy-pasting the same navigation markup into every file becomes painful. Styles that were meant to be local start bleeding across the page. Script variables in one section collide with variables in another.

Frameworks like React and Vue solve this problem well, for interactive applications that genuinely need component state, client-side routing, and reactive data binding. Most websites are not that. A marketing site, a documentation portal, a portfolio, a blog, these are mostly static documents with a handful of interactive moments sprinkled in. Reaching for a full framework for these projects means paying the runtime cost, the build complexity, and the mental overhead of an entire abstraction layer when the underlying platform already has everything needed.

The Component Convention

In Bascik, creating a component is creating a file. Name a file my-nav.html and it becomes the <my-nav> tag, automatically, everywhere. There is no registration step, no import statement, no export, no class to define. The filename is the entire interface.

CSS inside that file scopes itself to that component. Write .card { padding: 20px; } and Bascik rewrites it to something like .bascik__my-card__card { padding: 20px; } at build time. You never manage a namespace. You never worry about a class name colliding with another component. You write CSS the way you always have, it just works.

JavaScript inside that file scopes itself too. Write document.getElementById('count') and Bascik rewrites it to target the scoped version of that element, so two instances of the same counter on one page stay completely isolated, not through Shadow DOM or any runtime trick, but because the selectors were rewritten before the browser ever saw them.

The Platform Caught Up

There is a historical pattern worth recognizing. A language or platform ships without a feature the community needs. Someone builds a library to fill the gap. The library becomes ubiquitous. Years later, the platform ships the feature natively, but the ecosystem keeps reaching for the library out of habit.

jQuery filled a gap when DOM APIs were inconsistent across browsers. Underscore and Lodash filled a gap when JavaScript lacked functional array utilities. Tailwind filled a gap when organizing CSS at scale was genuinely hard. All of those tools were the right answer for their moment.

That moment has passed. Browser DOM APIs are consistent and capable. JavaScript ships with Array.map, Array.filter, Object.assign, optional chaining, and everything Lodash offered for free. CSS ships with custom properties, cascade layers, container queries, :is(), :has(), and logical properties. The platform caught up.

The only gap that remains is component organization, a way to write a navigation bar once and reuse it across pages without a runtime. That is the gap Bascik fills, using a build step rather than adding to the runtime.

Why Not Web Components?

Web Components are a browser-native component model, and they are a legitimate answer to the organization problem. But they come with trade-offs that make them a poor fit for statically rendered sites.

Every Web Component requires JavaScript to be parsed, evaluated, and registered before the component renders. On a page with ten components, that is ten class definitions loading at runtime just to display static content. Search engines, accessibility tools, and users on slow connections all pay that cost.

Web Components also introduce a non-trivial API surface: custom element registries, shadow DOM, light DOM, lifecycle callbacks, slot distribution rules. For a developer writing a navigation bar, none of that is relevant. It is framework complexity without the framework ecosystem.

Bascik takes a different position: run the component resolution at build time, ship plain HTML. A <site-nav> tag in source becomes a <nav> element in the output. Zero JavaScript is added to your pages. Every script in the final HTML was written by you.

Bascik and AI

Bascik was built before large language models became capable coding tools. As they advanced, something interesting became clear: AI is a better fit for Bascik than it is for most frameworks.

Language models were trained on the entire history of the web. They know HTML, CSS, and JavaScript exceptionally well, not just the syntax, but the patterns, the semantics, the accessibility attributes, the browser quirks. They can write assembly if asked. Writing a navigation component in HTML is trivial.

Frameworks introduce a layer the model has to reason through in addition to the underlying platform. To build a navigation component in React, the model must know React's component model, JSX syntax, hooks, prop types, and the conventions of the specific project setup, and then it must also know HTML, CSS, and the browser APIs that sit underneath. Every abstraction is another surface where the model can make a mistake, produce outdated patterns, or hallucinate an API that does not exist.

With Bascik, the model writes HTML, CSS, and JavaScript, three languages it knows precisely, with exhaustive documentation and decades of examples. Scoping and component resolution happen at build time without the model needing to understand any custom runtime. The component format is close enough to plain HTML that the model rarely needs to consult any Bascik-specific documentation at all.

Bascik and Other Libraries

Bascik is not exclusionary. It solves one problem, component organization at build time, and deliberately does nothing else. Everything else you might want on top of your HTML is still available to you.

Because Bascik's output is plain HTML, any library that works with HTML works with Bascik. Petite Vue can mount reactive islands on the page. Alpine.js can handle dropdowns and toggles. HTMX can fetch partial HTML from a server. Any chart library, animation library, or analytics script drops straight in with a <script> tag, because that is all it takes to load a library into a plain HTML page.

This is the opposite of a full-stack framework, which tends to control the entire rendering pipeline and make integrating outside tools awkward. Bascik controls nothing at runtime. It hands you finished HTML and steps aside. What you do with that HTML, whether you add Alpine.js, nothing at all, or a WebGL canvas, is entirely up to you.

The Core Principle

Every decision in Bascik follows from one rule: use what already exists. Do not invent a template language. Do not add a reactive data system. Do not require a runtime. Do not get between the developer and the browser.

Bascik is a find-and-replace at build time. Custom component tags are resolved to their source HTML. CSS class names are scoped so they cannot collide. Script variables are isolated so they cannot leak. The output is a directory of plain HTML files that any server can host, any browser can render, and any tool can inspect without knowing Bascik exists.

If the web platform ever ships a native, zero-runtime, build-time component model that does exactly this, Bascik becomes unnecessary. Until then, it stays out of the way and lets you write the web the way it was designed to be written.