Today, trends in website creation are changing. With the advent of Next.js, most developers have started using the concept of SSR (Server-Sider Ren...
For further actions, you may consider blocking this person and/or reporting abuse
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 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.
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
Good!