In the ever-evolving world of web development, a heated debate has resurfaced around the merits of using plain JavaScript versus popular frameworks like React, Vue, or Svelte. The discussion centers on a pattern called Writing JavaScript Views the Hard Way, which advocates for direct DOM manipulation using vanilla JavaScript instead of relying on abstraction layers provided by frameworks.
 |
|---|
| GitHub repository for "Writing JavaScript Views the Hard Way," highlighting a key project in the debate of plain JavaScript versus frameworks |
The Appeal of Going Framework-Free
Many developers in the community express enthusiasm for ditching frameworks in favor of plain JavaScript approaches. They cite significant performance benefits, easier debugging, and a more direct connection to the web platform. One developer shared their recent experience building an application in plain TypeScript with Vite, noting that they more and more question front end 'best' practices after seeing the benefits of the direct approach. The appeal extends beyond just technical advantages to include educational benefits, as working directly with the DOM forces developers to understand the underlying web technologies more deeply.
I can't conclude it scales, whatever it means, but I can conclude that there are huge benefits performance-wise, it's fun, teaches you a lot, debugging is simple, understanding the architecture is trivial, you don't need a PhD into insert this rendering/memoization/etc technique.
The DOM as a Source of Truth
An interesting pattern that emerged in the discussion is using the DOM itself as the source of truth for application state, rather than maintaining separate state variables. Some developers advocate for directly reading and writing to DOM elements through getters and setters instead of keeping separate JavaScript variables that need to be synchronized with the DOM. This approach eliminates the need to maintain state in two places but raises concerns about potential vulnerabilities to browser extensions that might modify the DOM unexpectedly, or challenges with handling redundant state across multiple UI components.
Maintainability Concerns
While the Hard Way approach promises simplicity, many developers expressed skepticism about its maintainability in team environments and larger applications. The pattern relies heavily on conventions rather than enforced structures, which could lead to inconsistencies as different team members contribute to the codebase. As one commenter pointed out, The design pattern is based on convention only. This means that a developer is free to stray from the convention whenever they want. This contrasts with frameworks that enforce certain patterns through their APIs and tooling.
State Management: The Real Challenge
A recurring theme in the comments is that the true difficulty in frontend development isn't creating DOM elements but managing state and keeping the UI in sync with that state. Reactive frameworks exist precisely to solve this problem. As applications grow more complex, manually tracking which parts of the UI need to update when state changes becomes increasingly difficult. One developer noted that the basic problem is when some piece of state changes, all the UI that depends on that state needs to be updated, and maintaining these update functions manually becomes unwieldy as applications scale.
Security Considerations
Several developers raised concerns about potential security vulnerabilities in hand-written templating approaches. Using template literals to generate HTML strings can lead to cross-site scripting (XSS) vulnerabilities if user input isn't properly escaped. While server-side sanitization can help, many argue that modern frameworks provide better protection by handling this automatically. The discussion highlighted how easily developers can introduce security issues when manually generating HTML, especially those who haven't experienced the pre-framework era of web development.
In conclusion, while the Hard Way approach offers compelling benefits for certain use cases—particularly in terms of performance, control, and learning opportunities—the community remains divided on whether it's suitable for production applications at scale. The debate ultimately reflects the tension between simplicity and structure, between direct control and abstracted convenience, that has characterized web development for years. As browsers continue to evolve and offer more powerful native APIs, this conversation will likely continue to evolve as well.
Reference: Writing JavaScript Views the Hard Way