Cooldecode · Lesson 03 · Main track

Plain HTML/CSS/JS vs frameworks: when the extra complexity pays off

After understanding what runs on the frontend and what runs on the backend, the next question is: do you really need a framework to build the visual layer, or does plain HTML/CSS/JS (the famous "vanilla") get the job done? The right answer is "it depends on the size of the problem" — and it's worth understanding why.

01What "vanilla" and "framework" mean

Vanilla JS (or plain HTML/CSS/JS) means building the interface using only what the browser already understands natively, with no libraries to structure components or manage state. A frontend framework (React, Vue, Svelte, Angular) adds a layer on top: reusable components, a declarative way to describe "what the screen should look like given this state", and tools to automatically update the screen when data changes.

Vanilla

You manipulate the DOM directly: document.querySelector, addEventListener, innerHTML. Total control, zero abstraction hiding what's happening.

Framework

You describe the interface as a function of state (UI = f(state)) and the framework decides how to efficiently update the DOM behind the scenes.

02Why frameworks exist

Nobody invented React or Vue on a whim. They solve a real problem that shows up as an interface grows: manually keeping the DOM in sync with the application's state turns into a nightmare of subtle bugs.

State synchronization: in a to-do list with filters, sorting, and inline editing, manipulating the DOM by hand for every change generates a lot of repetitive, error-prone code.
Componentization: frameworks encourage breaking the UI into reusable pieces (a card, a modal, a form) with their own rules — this scales better across teams and large projects.
Ecosystem: routing, global state management, testing tools, and a huge volume of ready-made libraries other people have already built.
Team standardization: when several people work on the same code, a framework enforces conventions that reduce style variation between developers.

03Why vanilla still makes sense

The idea that "every project needs React" is a common myth, especially among people who are learning. Vanilla JS is still the right choice in several scenarios:

Mostly static sites: a landing page, a blog, a portfolio — little to no interactivity doesn't justify loading an entire framework.
Critical performance: without a framework's abstraction layer, the JavaScript sent to the browser is smaller and startup is faster.
Isolated widgets: a small component embedded in another system (e.g., a chat widget embedded across several different sites) often doesn't need the infrastructure of a full framework.
Learning the fundamentals: understanding DOM manipulation, events, and a page's lifecycle helps you understand what the framework is doing underneath — writing "vanilla" code before learning React isn't wasted time, it's an investment.

04Direct comparison

Criterion	Vanilla JS	Framework
Initial learning curve	Lower	Higher (JSX, hooks, build tools)
Weight sent to the browser	Only what you write	+ framework library (tens of KB)
Maintenance on complex screens	Degrades fast with scale	Scales better with componentization
Team development speed	Depends on your own conventions	Conventions come built-in
Ecosystem of ready-made libraries	You build what's missing	Much broader
Ideal for	Simple sites, widgets, learning	Applications with heavy state and interaction

05Practical example: the same task in both worlds

A button that, when clicked, increments an on-screen counter.

// Vanilla JS
let counter = 0;
const button = document.querySelector('#btn');
const display = document.querySelector('#counter');

button.addEventListener('click', () => {
  counter++;
  display.textContent = counter;
});

// React
function Counter() {
  const [counter, setCounter] = useState(0);

  return (
    <div>
      <span>{counter}</span>
      <button onClick={() => setCounter(counter + 1)}>+1</button>
    </div>
  );
}

For this isolated example, vanilla is arguably simpler. The difference shows up when that counter needs to be reflected in three places on screen at once, synchronized with data coming from an API, inside a screen with dozens of other interactive components — that's when the framework's declarative approach starts to pay for its extra cost.

06How to decide in practice

Rule of thumb

Ask: "will this interface grow in state and interaction over time, or is it essentially static?". Small, static, or short-lived projects favor vanilla. Projects that will gain screens, complex forms, real-time data, and multiple people touching the code favor a framework — the learning cost pays for itself quickly as complexity grows.

To remember

A framework isn't "better" than vanilla in absolute terms — it's a trade-off: more structure and productivity on complex projects, in exchange for more weight and one more layer of abstraction to learn. Neither one replaces understanding plain HTML, CSS, and JavaScript, which remain the foundation of everything that comes after, including how the framework itself works under the hood.

Newsletter

Learn what AI is creating for you. Don't get lost.

Get notified when a new deep dive or lesson goes up. No spam, just new posts.

Cooldecode · Lição 03 · Trilha principal

HTML/CSS/JS puro vs frameworks: quando a complexidade extra compensa

Depois de entender o que roda no frontend e o que roda no backend, a próxima pergunta é: preciso mesmo de um framework para construir a parte visual, ou HTML/CSS/JS puro (o famoso "vanilla") resolve? A resposta certa é "depende do tamanho do problema" — e vale entender por quê.

01O que é "vanilla" e o que é "framework"

Vanilla JS (ou HTML/CSS/JS puro) significa escrever a interface usando só o que o navegador já entende nativamente, sem bibliotecas para estruturar componentes ou gerenciar estado. Um framework de frontend (React, Vue, Svelte, Angular) adiciona uma camada por cima: componentes reutilizáveis, um jeito declarativo de descrever "como a tela deve ficar dado este estado", e ferramentas para atualizar a tela automaticamente quando os dados mudam.

Vanilla

Você manipula o DOM diretamente: document.querySelector, addEventListener, innerHTML. Total controle, zero abstração escondendo o que está acontecendo.

Framework

Você descreve a interface como função do estado (UI = f(estado)) e o framework decide como atualizar o DOM de forma eficiente por trás das cortinas.

02Por que frameworks existem

Ninguém inventou React ou Vue por capricho. Eles resolvem um problema real que aparece conforme uma interface cresce: manter o DOM sincronizado manualmente com o estado da aplicação vira um pesadelo de bugs sutis.

Sincronização de estado: numa lista de tarefas com filtros, ordenação e edição inline, manipular o DOM à mão para cada mudança gera muito código repetido e propenso a erro.
Componentização: frameworks incentivam quebrar a UI em pedaços reutilizáveis (um card, um modal, um formulário) com suas próprias regras — isso escala melhor em equipes e projetos grandes.
Ecossistema: roteamento, gerenciamento de estado global, ferramentas de teste e um enorme volume de bibliotecas prontas já resolvidas por outras pessoas.
Padronização em equipe: quando várias pessoas mexem no mesmo código, um framework impõe convenções que reduzem a variação de estilo entre desenvolvedores.

03Por que vanilla ainda faz sentido

A ideia de que "todo projeto precisa de React" é um mito comum, especialmente entre quem está aprendendo. Vanilla JS continua sendo a escolha certa em vários cenários:

Sites majoritariamente estáticos: uma landing page, um blog, um portfólio — pouca ou nenhuma interatividade não justifica carregar um framework inteiro.
Performance crítica: sem a camada de abstração de um framework, o JavaScript enviado ao navegador é menor e a inicialização é mais rápida.
Widgets isolados: um componente pequeno embutido em outro sistema (ex.: um widget de chat incorporado em vários sites diferentes) muitas vezes não precisa da infraestrutura de um framework completo.
Aprendizado dos fundamentos: entender manipulação de DOM, eventos e o ciclo de vida de uma página ajuda a entender o que o framework está fazendo por baixo — programar "vanilla" antes de aprender React não é perda de tempo, é investimento.

04Comparação direta

Critério	Vanilla JS	Framework
Curva de aprendizado inicial	Menor	Maior (JSX, hooks, build tools)
Peso enviado ao navegador	Só o que você escreve	+ biblioteca do framework (dezenas de KB)
Manutenção em telas complexas	Piora rápido com a escala	Escala melhor com componentização
Velocidade de desenvolvimento em equipe	Depende de convenções próprias	Convenções já vêm prontas
Ecossistema de bibliotecas prontas	Você monta o que falta	Muito mais amplo
Ideal para	Sites simples, widgets, aprendizado	Aplicações com muito estado e interação

05Exemplo prático: a mesma tarefa nos dois mundos

Um botão que, ao ser clicado, incrementa um contador na tela.

// Vanilla JS
let contador = 0;
const botao = document.querySelector('#btn');
const display = document.querySelector('#contador');

botao.addEventListener('click', () => {
  contador++;
  display.textContent = contador;
});

// React
function Contador() {
  const [contador, setContador] = useState(0);

  return (
    <div>
      <span>{contador}</span>
      <button onClick={() => setContador(contador + 1)}>+1</button>
    </div>
  );
}

Para esse exemplo isolado, o vanilla é até mais simples. A diferença aparece quando esse contador precisa refletir em três lugares da tela ao mesmo tempo, sincronizado com dados vindos de uma API, dentro de uma tela com dezenas de outros componentes interativos — aí a abordagem declarativa do framework começa a compensar o custo extra.

06Como decidir na prática

Regra prática

Pergunte: "essa interface vai crescer em estado e interação ao longo do tempo, ou é essencialmente estática?". Projetos pequenos, estáticos ou de vida curta favorecem vanilla. Projetos que vão ganhar telas, formulários complexos, dados em tempo real e múltiplas pessoas mexendo no código favorecem um framework — o custo de aprendizado se paga rápido conforme a complexidade cresce.

Para fixar

Framework não é "melhor" que vanilla em absoluto — é uma troca: mais estrutura e produtividade em projetos complexos, em troca de mais peso e uma camada de abstração a mais para aprender. Nenhum dos dois substitui entender HTML, CSS e JavaScript puros, que continuam sendo a base de tudo o que vem depois, inclusive de como o próprio framework funciona por dentro.

Newsletter

Saiba o que a IA está criando pra você. Não fique por fora.

Seja avisado quando eu postar uma imersão ou lição nova. Sem spam, só posts novos.