In today's web development community, it seems there's a new JavaScript framework every week. React, Vue, Angular, Svelte, Solid.js, Qwik... the list is endless, and "JavaScript fatigue" (fatigue from the sheer number of tools) is a well-documented phenomenon among developers. However, at JCode we strongly bet on Vanilla JS for our interactive templates. In this article, we'll explain why and when it makes sense to use each alternative.
1. What really is "Vanilla JS"?
The term "Vanilla JavaScript" or "Vanilla JS" refers to plain JavaScript language, without any additional libraries or frameworks. It is an inside joke in the developer community that arose in response to the proliferation of libraries: if you search for "Vanilla JS" on the internet, you'll find a satirical website describing it as "the most lightweight JS framework in the world."
In practical terms, using Vanilla JS means working directly with the APIs the browser natively exposes: document.querySelector() to select elements, addEventListener() to listen for events, fetch() to make network requests, and animation APIs like requestAnimationFrame(). All of this without needing to download or install any dependencies.
2. Frameworks: what are they actually for?
Modern frameworks like React, Vue, and Angular didn't arise on a whim. They were born to solve specific problems that appear when building large-scale web applications with dozens of developers working in parallel. The main problems they solve are:
- Complex state management: When the interface depends on lots of data that changes frequently and interdependently (like an Amazon shopping cart with thousands of products).
- Server-Side Rendering (SSR): To improve SEO and perceived speed in applications with heavy dynamic content.
- Large-scale componentization: Breaking the application into reusable pieces that dozens of developers can work on independently without stepping on each other's toes.
- Tooling ecosystem: Automated testing, hot-reloading during development, automatic bundle optimization, etc.
These are real problems... in applications like Facebook, Airbnb, or YouTube. If you are building an interactive birthday letter, a portfolio landing page, or a digital romantic surprise, none of these problems exist.
3. Over-engineering: the enemy of accessibility
Using a framework for trivial tasks adds unnecessary burden to the project. React, for instance, has a base size of approximately 130KB minified (the production version). Vue is somewhat lighter at ~80KB. This might seem small, but consider that a basic digital gift template might only have 15-20KB of its own code. Adding a framework means multiplying the weight of your project by 5 or 10 times.
This has direct consequences on the user experience:
- Longer load time: Especially on slow 3G mobile connections or in rural areas with limited connectivity.
- Higher data consumption: If someone opens your gift using mobile data, a heavier file consumes more of their data plan.
- Higher maintenance complexity: Frameworks are constantly updating. A project created in React 16 might break in React 18 due to API changes.
- Higher barrier to entry: If you want to share the source code for the user to edit, they will need to install Node.js, npm, run terminal commands... something impossible for the majority.
"The right tool for the right job isn't always the newest or the most popular one. Sometimes, the right tool is the simplest one."
4. Native DOM Performance in 2025
One of the historical arguments in favor of frameworks like React was that their "Virtual DOM" was more efficient than directly manipulating the real DOM. In the 2010s, this was true: browsers of that era were slow at manipulating the DOM, and React's Virtual DOM was a clever solution.
In 2025, this argument is almost completely obsolete. Modern browsers (Chrome V8, Firefox SpiderMonkey, Safari JavaScriptCore) have invested heavily in optimizing real DOM manipulation. For small- or medium-scale projects, Vanilla JS performance is indistinguishable from or even superior to Virtual DOM frameworks, since it eliminates the intermediate abstraction layer.
The Svelte team itself, the framework created by Rich Harris (former New York Times), came to the same conclusion and designed their framework to compile to plain JavaScript without a Virtual DOM. The industry trend points toward "less abstraction layer, more native code."
5. The JCode approach: simplicity as a standard
Our products, like interactive letters, creative portfolios, and 3D web components, are designed under three principles that we find non-negotiable:
- Easy to edit without advanced knowledge: If you download one of our free codes, you can open it in Windows Notepad, change text with Ctrl+F, and save it. If we used React, you'd have to install Node.js, run
npm install, compile withnpm run build, etc. That's a barrier that excludes most of our users. - Guaranteed universal compatibility: An HTML + CSS + JS file works on any server, any free hosting service (Netlify, GitHub Pages, Tiiny.host, Vercel), in any year. A project compiled with Webpack or Vite may have incompatibilities with future dependency updates.
- Instant mobile loading: 87% of JCode traffic comes from mobile devices. Every extra kilobyte in the bundle translates to lost milliseconds of loading. Loading speed is directly proportional to the likelihood that the gift receiver will forward it to someone else.
6. When SHOULD you use a framework?
This is an honest guide, not an anti-framework manifesto. Frameworks have their place and are the right tool in many contexts:
- When you have a team of 5+ developers working on the same codebase.
- When the application has a complex state that updates in real-time (analytics dashboards, chat apps, collaborative editors).
- When you need Server-Side Rendering (SSR) for advanced SEO.
- When the application has more than 50 distinct UI components that are reused in multiple contexts.
If any of these points describe your project, then yes, use React, Vue, or whichever framework best suits your team. If not, seriously consider whether you actually need the added complexity.
Conclusion
The most important skill of a good developer is not knowing the newest framework, but knowing how to pick the right tool for every job. At JCode, we have chosen Vanilla JS because it perfectly solves our problems, empowers our users to customize the code themselves, and ensures every template works for years without additional maintenance. That is smart engineering, not a technical limitation.