Today, trends in website creation are changing. With the advent of Next.js, most developers have started using the concept of SSR (Server-Sider Rendering), which allows generating dynamic markup directly on the backend. But since this practice is architectural due to the fact that it is a framework, you will not be able to combine it normally, for example, if your site is already written in Vue.
The microfrontend concept helps in this regard, but again, for budget development this is too expensive a scheme, so in order to painlessly implement SSR (without robots), this template language was developed.
🐜 HMPL
HMPL is a template language that complements regular HTML with request objects. That is, you can describe directly in the markup what API path you want to get the component.
import hmpl from "hmpl-js";
// We create a constructor function
// that will generate instances to receive our elements.
const templateFn = hmpl.compile(
`<div>
<h1>
{
{
src: "http://localhost:8000/api/getTitle"
}
}
</h1>
</div>`
);
// Generate an instance and get an element from it
const content = templateFn().response;
// Mounting our element into the DOM
document.querySelector("#app").append(content);
🌷 Example App
Using this module, a gallery application was created that implements dynamic content delivery on the server.
The example itself is located in the GitHub repository here.
Also, it would be great if you supported the project with your star! Thanks ❤️!
📊 Size comparison
Let's compare the code of two applications with the same UI and look at their size:
As we can see, the HMPL clicker has a smaller file size than the same Vue clicker interface.
Also, there is a comparison with other popular UI creation tools and pure JS:
The results are based on a comparison of the sizes of applications presented in this repository.
⚙️ Installation
Node Package Manager: You can download it via npm using the command
npm i hmpl-jsContent Delivery Network: You can include a file with a dependency via CDN using the following code:
<script src="https://unpkg.com/json5/dist/index.js"></script>
<script src="https://unpkg.com/hmpl-js/dist/hmpl.min.js"></script>
- Locally: Or, there is a similar option with the second one, just download the file to your local machine.
💬 Feedback
You can write your thoughts about the module in the comments, it will be interesting to read! Or, there is a thematic discord channel for questions and suggestions, there I or someone else will try to answer!
✅ This project is Open Source
So you can take part in it too! This also means you can use it for commercial purposes:
Repo: https://github.com/hmpl-language/hmpl
Website: https://hmpl-lang.dev
Thank you for reading!
Top comments (19)
The size comparison is really misleading. You also need server side code for any of the features demonstrated here, where the Vue implementation is complete.
Does that mean that with the server code you may even get a bigger bundle size in the end ?
How? The code remains on the server, you transfer the framework via protocol. Another advantage is that this HTML can be transferred between sites.
No, wait, it doesn't. Yes, you essentially transfer the code from the client to the server, but this code remains on the server, and the clients load only the framework, into which HTML from the server goes brick by brick. Accordingly, this framework will be loaded during the first and subsequent loads, accordingly the site will load faster, but heavy elements will simply be with a loader.
But you still need to write the server side code, which means you are writing more code than in the Vue version. The client side code difference doesn't even matter as you will be downloading more from the server through the additional requests.
Well, yes, you still have to write code, but on the server - that's clear. No module will replace it). Regarding the value on the client - it matters. If the site is focused on SEO in search results, then the initial loading is of colossal importance. Literally, the sales funnel will simply sag for the banality that the site loads for 10 seconds, when with this approach the site will load almost instantly, because there will be nothing to load, but all components will be with loaders that come from the server. There are also pros and cons here. In fact, I am retelling the SSR advantages.
I guess the Vue version and the HTPL version code behaves differently?
The Vue code stores the temporary state on the client.
But HTPL seems stores on the server.
That introduce latency, and the effect isn't the same.
And you can use Composition API instead of Options API, for a shorter code.
This is the second time I have seen something about HMPL in my news feed so I guess I'll give it a test drive 😉
Thanks, let's do it! If you find a bug, write to us - we'll fix it! We did 100% test coverage, but we could have missed something.
The size comparison is not very impressive, you don't gain that much for the added complexity and dependency.
And what - honesty is the main thing. Yes, maybe it doesn't win much, well, why should I write now that it reduces by 100 times and lie? I write honestly, what is, is. Even if we take a modern web application with 100 modules with boilerplate code, well, there may be such a result, but everything is honest. I will not deceive.
Don't use Vue Options API, use Composition API, and the code will be shorter.
Good!
Good article! And how does this work?
Thanks! The components are taken from the server, so on the client we only have the request markup.
The diagram doesn't look very good, but it looks cool on the website, with animation.
probably better to source the minified version of json5
I am creating a more simple approach to make web apps.
i added support for loops ,if-else inside of plain old HTML*
check the article on dev.to
dev.to artical link
Pretty sure ht.js is smaller...
If you are going to rely on json5, then probably better to just bundle it with this framework?