Crafting Large Frontends Without Frameworks: Leveraging Web Standards for Scalable Apps

The premise of constructing substantial front-end applications without reliance on extensive JavaScript frameworks, exemplified by projects like Obsidian, offers compelling advantages. This approach emphasizes leveraging the core capabilities of the web platform to achieve outcomes often attributed solely to frameworks.

Why Consider a Framework-Free Approach?

Opting out of a major framework can unlock several benefits:

• Enhanced Project Longevity and Stability: Frameworks often introduce rapid change cycles, leading to frequent breaking changes and costly migration efforts. By adhering to slower-moving web standards, projects can achieve greater stability, longevity, and reduced long-term maintenance overhead.
• Greater Performance Control: Working directly with the Document Object Model (DOM) and minimizing abstraction layers allows for precise performance optimizations, leading to faster execution and lower memory usage.
• Independence and Security: Reduced reliance on large third-party ecosystems mitigates supply chain risks and ensures the project's success is not overly tied to the trajectory of an external framework.
• Deeper Developer Understanding: Engaging directly with browser APIs and core JavaScript fosters a more profound understanding of how web applications function at a fundamental level.

Key Strategies for Building Robust Apps Without Frameworks

For those choosing a more native path, several effective strategies emerge:

• Embrace Web Platform APIs:

  • Direct DOM Manipulation: Utilize native JavaScript methods like document.querySelector, createElement, appendChild, and addEventListener for precise control over the user interface. This is often simpler than perceived, especially for focused interactions.
  • ES6 Modules: Structure applications using native ES6 modules for clean code organization, reusability, and dependency management.
  • Web Components: Leverage native Web Components (Custom Elements, Shadow DOM, HTML Templates) for encapsulated, reusable UI elements. Lightweight libraries like Lit can further enhance their development experience.
  • History API for Routing: Implement client-side routing using history.pushState and popstate events to manage navigation in Single Page Application (SPA)-like experiences without a dedicated routing framework.
  • MutationObserver and Proxies: For advanced reactivity, MutationObserver can watch for DOM changes, and JavaScript Proxies can be used to create reactive data models.

• Minimalist State Management: Instead of large state management libraries, implement simpler patterns like custom publish-subscribe systems, use CustomEvent for inter-component communication, or manage state directly within module closures. Small, focused libraries like Nanostores offer reactivity without heavy overhead.

• Backend-Driven UI with Vanilla JS Sprinkles: Many applications do not require a full SPA architecture. Server-side rendering augmented by technologies like HTMX or Phoenix LiveView can deliver highly interactive user experiences by pushing HTML diffs to the client over WebSockets, with vanilla JavaScript reserved for specific, localized micro-interactions.

• Strategic Use of Small, Focused Libraries: Rather than adopting a monolithic framework, selectively integrate small, purpose-built JavaScript libraries for specific needs, such as date manipulation, drag-and-drop functionality, or form validation.

• Modular Architecture and Typescript: For projects of significant size and complexity, a disciplined modular architecture (e.g., each feature as its own ES6 class or module) combined with TypeScript is crucial. TypeScript provides static type checking, which significantly aids maintainability, refactoring, and prevents common runtime errors.

• Sensible Build Process: While avoiding a framework, modern build tools like Vite, ESBuild, or Rollup remain highly valuable for bundling, minification, and enabling features like hot module replacement (HMR) during development.

Addressing Common Concerns

Concerns about "re-inventing the wheel" are common. However, the goal is to create "just enough" tailored abstractions specific to the application's needs, not to replicate a general-purpose framework. While popular frameworks simplify developer onboarding due to widespread familiarity, a well-structured and documented vanilla project can be equally maintainable, especially when the benefits of ownership and control are paramount. Security in vanilla applications can be ensured through diligent practices and the use of libraries like Dompurify for sanitizing user-generated content.

Illustrative Examples

Several prominent projects demonstrate the viability of this approach:

• Obsidian: A desktop application built with web technologies, notably without a major JavaScript UI framework.
• Filestash: An open-source project migrated from React to plain ES6, achieving significant performance improvements.
• CodeMirror: A complex, feature-rich code editor built without a frontend framework.
• Moos.app: A Figma-like animation tool developed with vanilla JavaScript, demonstrating complex UI and reactivity.
• LendCalculator: A browser-based financial tool built with vanilla JS and a modular architecture.

The Framework vs. Library Distinction

Many discussions highlight that terms like "framework" and "library" are often used interchangeably, leading to confusion. React, for instance, is often considered a library focused on reactive rendering, while a framework (e.g., Next.js) provides a more opinionated, comprehensive solution encompassing routing, state management, and build processes. Understanding this distinction is key to making informed architectural decisions.