In the modern web development landscape, JavaScript frameworks like Vue, and Angular dominate discussions about reactive interfaces.
However, it's entirely possible to create reactive HTML without relying on these heavy frameworks.
In this article, we will talk about how you can do this using this project.
Well, let's start! π
π What is the problem of using frameworks?
While JavaScript frameworks like Vue and Angular offer powerful tools, they come with significant drawbacks. One major issue is boilerplate code β developers often write repetitive setup code before implementing actual features. Frameworks also impose their own architecture, which can be overly complex for simple projects. Additionally, frequent updates may require costly migrations, making maintenance difficult over time.
Another concern is performance overhead, as frameworks bundle large runtime libraries that may not be needed. They also create vendor lock-in, making it harder to switch technologies later. Many projects end up using only a fraction of a frameworkβs features, yet still pay the cost in bundle size and complexity. For smaller applications, a lightweight alternative like HMPL.js can often achieve reactivity without unnecessary bloat.
β Solution
You can just put your code to the server and load the finished HTML from the server. This will not only reduce the size of the source gang, but will also make it possible to redesign the components on different web applications.
But, the problem is that of course, we can use Next.js or Nuxt.js to achieve this, but we will reproach at the moment again, because they also use the client components and the number of serverly minimally, they are just the initial wrappers for metathegs in most cases, therefore, this approach can be used a little differently.
π Using the HMPL.js module
We may not connect a bunch of packages to our project to create a beautiful interface. It will be enough for the usual HTML page and a couple of tags script
.
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Example</title> </head> <body> <main> <template hmpl> <div> {{#request src="/api/header.html"}} {{#indicator trigger="error"}} <p class="indicator">Header loading error</p> {{/indicator}} {{/request}} </div> </template> <div class="content"></div> <template hmpl> <div> {{#request src="/api/footer.html"}} {{#indicator trigger="error"}} <p class="indicator">Footer loading error</p> {{/indicator}} {{/request}} </div> </template> </main> <script src="https://unpkg.com/json5/dist/index.min.js"></script> <script src="https://unpkg.com/dompurify/dist/purify.min.js"></script> <script src="https://unpkg.com/hmpl-js/dist/hmpl.min.js"></script> <script src="https://unpkg.com/hmpl-dom/dist/hmpl-dom.min.js"></script> </body> </html>
Here we get our components from the server on the client and we donβt care how much will come from there. The original gang will be only a couple of kilobytes, and the interface will be the same as if we wrote it on Vue, literally one to one. Therefore, you can use this method if you have in this consumption
ποΈ Conclusion
JavaScript frameworks provide powerful solutions but often introduce unnecessary complexity, boilerplate code, and performance overhead for simpler applications. Lightweight alternatives like HMPL.js demonstrate that reactivity can be achieved without heavy dependencies, offering a more efficient approach for many use cases. By carefully evaluating project needs, developers can choose the right balance between functionality and simplicity, avoiding over-engineering while still delivering dynamic user experiences.
Thank you very much for reading this article β€οΈ!
What other popular replacements do you know? It will be interesting to know about them in the comments!
P.S. Also, don't forget to help me and star HMPL!
Top comments (6)
In theory, this is possible, but you need to look in practice
Agree
Looks promising but risky for production! π‘ Better strategy: Start with Preact as drop-in React replacement - same code, 90% smaller bundle. Then optimize from there!
This is still running JavaScript. In my opinion I would prefer to use Alpine.js.
Alpine.js is a fairly generic approach, not really server-oriented. Syntax-wise, it's very similar to jsx, but a bit weird.
Without a framework, create a normal application possible