Limitations and Drawbacks of Vanilla JS

While vanilla JavaScript can do almost everything, building large applications without any frameworks or libraries can introduce some challenges:

• Lack of Structure (Routing/State Management): Out of the box, JavaScript (and the DOM API) doesn’t provide a structure for single-page application routing or complex state management. If you’re building an SPA with vanilla JS, you have to manually use the History API or location hash for routing, and implement patterns to manage state across components or views. In a framework like React or Angular, these concerns are handled by well-defined patterns or libraries (React Router, Vuex/Redux, etc.). With vanilla JS, it’s on you to design how the app transitions between views and how to store and update global state.
• Boilerplate and Verbosity: Direct DOM manipulation, event handling, and updating the UI can involve a lot of repetitive code. For example, updating a list might require manually creating elements, setting their attributes, and appending them. Frameworks often abstract this with templates or JSX that declaratively describe UI. In vanilla, without careful abstraction, you might end up writing similar loops and checks in many places. This can be mitigated by creating your own utility functions or adopting patterns (like simple templating functions), but it requires effort.
• Reusability of Components: Before Web Components or frameworks, reusing a piece of UI + logic meant either copy-pasting code or writing your own patterns (like a function that takes some data and re-renders a section of HTML). There is no native component model (aside from Web Components which have their own learning curve and quirks). This means teams might reinvent the wheel for common components (modals, dropdowns, etc.) or use jQuery plugins (historically) which could lead to inconsistent usage. Frameworks encourage a component-based architecture where pieces of UI are encapsulated and easily reused.
• Maintainability and Scalability: As a project grows, vanilla JS without a clear architecture can become hard to maintain. Different developers might use different patterns, global variables might proliferate, and debugging becomes tough if there isn’t a structured approach. Frameworks enforce a certain structure (for example, Angular’s MVC or React’s functional UI with state and props) which, when adhered to, makes large apps more predictable. That said, one can absolutely write maintainable large applications in vanilla JS, but it requires discipline and possibly inventing a mini-framework of your own (which is what many did before modern frameworks – they created their own patterns).
• Templating and DOM Updates: Updating the DOM in response to state changes is manual in vanilla JS. You have to decide when to call element.textContent = ... or create/remove elements. With frameworks, you typically just change the state and the framework handles updating the DOM efficiently (via diffing algorithms or reactive binding). In vanilla, you might end up re-rendering whole sections unnecessarily or forget to update something leading to UI inconsistency. It’s up to you to optimize DOM updates (e.g., not rebuilding a list from scratch if only one item changed).
• Learning Curve and “Wheel Reinvention”: Paradoxically, while vanilla JS is the base language (which you should learn anyway), building complex apps with it means you need to have knowledge of many web APIs and how to piece them together. A beginner might find it easier to start with a library that provides structure. Also, common tasks (like form validation, modal dialogs, etc.) either you implement yourself or include lightweight libraries. By using a framework, you often get many things out-of-the-box (or from its ecosystem) rather than finding or writing each piece yourself.
• Consistency and Teamwork: In a team, if using just vanilla JS, you need to agree on conventions (like how modules communicate, how to organize files, etc.), otherwise each developer might do things differently. Frameworks often come with a CLI or project conventions that every team member can follow, and a lot of decisions (folder structure, how UI is updated, how styles are applied, etc.) are standardized.
• No automatic UI binding: With vanilla JS, there’s no automatic two-way binding or state -> UI sync unless you implement it. For example, in a framework, you might bind an input field to a state variable and it updates automatically. In vanilla, you’d add an event listener to update state on input, and another to update UI when state changes – and it’s easy to forget one direction or the other. You have to be careful to keep the data model and UI in sync.

That being said, many of these “limitations” are exactly why frameworks were created. If you don’t need those high-level features, vanilla JS might suit you just fine and be more lightweight. Let’s consider when vanilla JS is a good fit versus when it might not be