Why Vanilla JavaScript
Advocates of “vanilla” JavaScript argue that modern browsers, Web Components, and light custom helpers are enough for many apps, and that large frameworks like React or Angular often introduce unnecessary complexity, build tooling, and performance overhead—especially for small teams or simple UIs. Others counter that frameworks earn their keep on moderately complex or long‑lived projects by enforcing shared structure, predictable patterns, and easier onboarding, even if they add abstraction and churn. Several contributors note how TypeScript, JSDoc, and LLMs shift the trade‑offs again, making it easier to work directly with the platform while still getting type safety and code generation support.
Scope of Vanilla JS vs Frameworks
- Many agree vanilla JS is viable and pleasant for small or personal projects: fewer dependencies, no build step, full control over the browser “as the framework.”
- Several argue modern JS (ES5+ features) and Web APIs are now good enough that heavy frameworks are often unnecessary for basic CRUD and “sprinkled interactivity.”
- Others counter that for any “moderately complex UI,” vanilla approaches tend to accrete into a bespoke, under-documented framework with ad‑hoc design decisions.
Teamwork, Structure, and Scaling
- Strong theme: frameworks provide shared conventions, predictability, and guardrails for teams, especially as codebases and headcounts grow.
- Using a popular framework simplifies hiring and onboarding; new developers and LLMs already know the patterns.
- Critics note that frameworks themselves fragment (React variants, state managers, styling systems), so choosing one doesn’t fully eliminate disagreement or complexity.
Web Components and “Thin” Abstractions
- Some advocate Web Components and modular vanilla JS as a scalable middle ground: componentized UIs, dynamic imports, and shared component pools without heavy tooling.
- Others see the article’s custom abstractions (including EHTML) as de‑facto micro‑frameworks, adding yet another bespoke layer to learn.
Type Systems and Tooling
- Multiple comments promote TypeScript or JSDoc/@ts-check for static checking, with disagreement over whether a build step is acceptable or necessary.
- There’s skepticism about “zero build” setups for complex apps due to missing minification/code‑splitting and long‑term fragility of custom tooling.
Performance, UX, and Architecture Choices
- Debate over SPA vs multi‑page apps: some insist MPAs are fast with proper caching; others say SPAs can feel snappier and more dynamic.
- Several criticize React for adding latency and complexity to UIs that only need a few DOM updates; others see React as a powerful “electric screwdriver” for larger SPAs.
LLMs and the Future of Frameworks
- Some expect LLMs to reduce the need for large frameworks by making it easier to work directly with platform APIs or small helpers.
- Others note frameworks act as guardrails for non‑deterministic LLM‑generated code and that LLMs already work well with mainstream stacks like React/TypeScript.