Frontend Frameworks and Modern JavaScript

To put the discussion in context, let’s briefly overview the state of modern frontend frameworks (as of mid-2020s) and how they relate to vanilla JS:

• React: The most popular library for building UIs. It introduced a component-based approach and a declarative way to describe UI. React is essentially JavaScript plus a library – you still write JS (or TS) for all your logic, but React provides a structure for managing state and updating the DOM efficiently via a virtual DOM diff. A huge ecosystem exists around React (routing libraries, state management libraries like Redux or Zustand, UI component kits, etc.). React doesn’t hide that you’re writing JS – in fact, with hooks and functional components, it’s closer to writing “just JS” than some other frameworks. But it does impose the need to understand its reconciliation algorithm and component lifecycle. According to surveys, around 40% of JS devs use React in some capacitygist.github.com, making it a de facto skill. Knowing vanilla JS makes learning React easier (JSX is basically syntactic sugar for JS function calls).
• Vue.js: Another widely used framework, known for being approachable. Vue uses an HTML-based template syntax (or you can use JSX if you want) and a reactivity system under the hood. It’s somewhat like a blend of Angular ideas and Reactivity – you have components and directives in templates. Vue’s core is small and focused, with an ecosystem of official supporting libraries (vue-router, Vuex for state, etc.). It abstracts a lot of things (you don’t directly manipulate DOM; you declare what you want and Vue handles it). Still, it’s fundamentally JavaScript driving the show. You write methods in a component, manage data objects, etc., so JS knowledge is key. Vue 3 introduced the Composition API which is closer to raw JS functions composition for state, which again rewards those who know JS well. Vue is popular (15-20% of devs in some surveys use itgist.github.com) and particularly loved for its gentle learning curve.
• Angular: (Angular 2+; not to be confused with the old AngularJS) is a full-fledged framework by Google. It’s more heavyweight and prescriptive (using TypeScript, classes with decorators, dependency injection, etc.). Angular provides everything out of the box (router, forms, HTTP client, etc.). It’s less about manipulating JS directly and more about using Angular’s provided patterns. That said, you still need to write TypeScript (which is JS with types) and understand how things like context, closures (for capturing component variables), etc., work under the hood. Angular has a steeper learning curve because there’s a lot of framework-specific concept (RxJS observables, NgZone, etc.), but strong JS fundamentals help (especially with TypeScript and async programming).
• Svelte: A newer contender that compiles your code to vanilla JS at build time. Svelte’s claim is that there is no runtime overhead – you write components with a certain syntax, and a compiler produces efficient JS that updates the DOM directly. This is interesting because it blurs the line: you write in a framework, but the output is essentially optimized vanilla JS. Svelte is praised for performance and a straightforward model (write state, update it, and the compiler takes care of updating DOM). It shows how knowing JS is beneficial: a Svelte developer can actually inspect the compiled output to understand what’s happening (which will be plain JS assignments and DOM calls).
• Other frameworks: There are always new frameworks or niche ones (SolidJS, Qwik, etc.) which often try to optimize certain aspects (SolidJS uses fine-grained reactivity, Qwik focuses on resumability for instant startup). Regardless of their innovation, the code you write is still JavaScript/TypeScript, and the better you understand the core language, the better you can leverage these tools.
• Micro-frameworks and libraries: Not every app needs React or Angular. Sometimes something like Alpine.js (for sprinkling behavior using HTML attributes, kind of like a very lightweight Vue) or lit (library for building Web Components) is enough. These tend to stick closer to the DOM and JS, so you use them to avoid writing boilerplate but you’re still very much in control with JS. If you jump into these without understanding how DOM events or data binding work normally, you might misuse them.

Trends: There’s a bit of a pendulum swing in web dev. We went from no frameworks (just jQuery) to heavy SPA frameworks for everything, and now there’s talk of performance issues and the rise of “return to server-side rendering” for initial load (with frameworks adapting by offering SSR modes, static site generation, etc.). Also, Web Components have matured and might reduce the need for framework for some use cases (though their adoption is still not as high). Through all this, vanilla JS remains relevant – because even these frameworks are starting to incorporate more native ideas (like standardizing on web components, or compile-to-vanilla outputs).

Using frameworks effectively means using JavaScript effectively: A practical example – say a React app is sluggish because a component re-renders too often. A dev not solid on JS might sprinkle React.memo or think in terms of React-only solutions. A dev with core knowledge might identify that the offending re-render is caused by passing an anonymous function as prop (which changes on each render because it’s a new object each time – a JS quirk) and solve it by hoisting that function or using useCallback (which again is basically memoizing a function – a JS concept). Many performance patterns in frameworks boil down to understanding how JS handles references and equality, or how the call stack works, etc.

Finally, consider that frameworks come and go, but JavaScript is here to stay (at least for the foreseeable future). A developer investing time in deeply learning JavaScript – how prototypes work, how the event loop works, how to manipulate the DOM API, etc., – will find themselves able to pick up any framework, contribute to libraries, and debug issues at a fundamental level. In contrast, a developer who only learns “framework X” might do fine until they hit a wall the framework doesn’t cover, or when a new paradigm emerges.

In summary, even in a world dominated by frameworks, vanilla JavaScript knowledge is the foundation that makes a developer effective. It’s the common language that underpins everything on the web platform. As frameworks evolve (or if one day you’re writing a completely frameworkless app, or maybe using generated JS from some other language via WebAssembly or whatever), understanding the core will always be valuable.