Maybe I’m misunderstanding this but I find it crazy that people now act like generating HTML server side is a genius new idea that is going to replace JS Frameworks. Isn’t that kind of the default and the SPA Frameworks were the new idea? Imagine telling a PHP dev that you’re now rendering your HTML server side! I’m happy to be corrected if I’m wrong here but it’s very weird from my view.
I don't disagree with your point, but you don't seem to be actually reacting to anything really present in the submission.
Afaict nowhere is it being presented as a new or genius idea, or is it suggesting it will replace SPA frameworks. These all seem to be things you've projected on to the submission.
I was mainly responding to this paragraph in the submission:
> The HMPL template language extends the capabilities of regular HTML by adding query objects to the markup to reduce the code on the client. When writing SPA, a large amount of javascript code is generated, which is loaded when the user visits the site, so the loading speed can be quite slow. All this can be avoided by generating the markup on the server and then loading it on the client:
< some code >
Let's say that the same code on popular frameworks such as Vue and others takes up much more code, which, in fact, can be moved to the server.
Maybe I’m misinterpreting but this seems to say that this approach is an improvement over SPAs. My point is that this is basically what everyone else has done all the time before SPAs were even a thing.
Thank you very much for your feedback! This idea has been discussed and used in web development for quite some time now. I am certainly not inventing anything new, but I think the idea of combining the template language approach and server requests to get a UI looks interesting.
Thank you very much for your feedback! This is a template language oriented primarily to work via JavaScript. It does not functionally interact with the real DOM in any way. You create separate objects with nodes. Also, the syntax is based on passing objects "to HTML", while HTMX works via attributes. I have long wanted to make a full-fledged article on this topic, but I never got around to it. I am already tired of just writing the same thing over and over again.
Thank you very much for your feedback! No, it's just great to work through javascript. Moving away from javascript is not intended. It's the opposite: a connection with the server, passing the RequestInit object, and other similar things!
Isn’t this what rpc/pbs/code-gen theoretically does? Markup/down sent? Then you don’t have to worry about the client or server language but settle on a subset of features somewhere.
My flow is that focusing on the data structure and methods allows the UI to be completely abstract. Not in a magic way but in a “maybe we should use cross compile this into C++ and use OpenGL if the UI becomes too complex. This is how you get AutoCad or film editing software running essentially as a Proton/video game runs.
When your app gets beyond a certain level of complexity (window composition, etc) yeah there’s ways to make it happen.
Regarding the standards that should be applied to template languages - all this will be adjusted as it develops. This module comes as a new idea that I would like to implement into a really good product. Even when working on Cample, I thought about something similar.
I’m currently learning frontend (vanilla JS and bootstrap) and client-side render the UI for some of my ideas.
From my understanding, modern frameworks(React) use both. Why would you limit yourself to just server-side? Isn’t there a trade off between server-side and client-side rendering?
My rule of thumb is to render HTML where the state lives.
When state lives on the server, usually in a database, leave your templating engine there and ship HTML.
When state only lives in the client, think temporary UI state or animations, that rendering needs to happen in the client.
At least for the kinda of sites and apps I build, that almost always means most of the rendering is done on the server and client rendering is so small in scope that I don't need more than plain old JS or a web component.
Thank you very much for your feedback! In short, it's about theories like SPA, SSR and others. There are different approaches to creating web applications with their pros and cons. This template language is simply an implementation of one of these ideas. You can make websites using PHP (working with WP and other similar things), and through frameworks that use SSR as a basis and others.
Thank you very much for creating a video about the template language review! I have just started making it and it is not yet included in any databases.
To save someone a click, this is an off the cuff review of it, followed by a suggestion to add it to a directory site run by the author that has an unusual interface that repurposes the back button (if you follow one or more internal links, the back button loops).
> if you follow one or more internal links, the back button loops
This should not happen.
Any chance you could record a Loom (or other screencast tool), showing me what you mean?
That way I can add a fix to our open source, public domain database of languages (https://github.com/breck7/pldb), which I thought could really help the OP, who is building a new language.
Maybe I’m misunderstanding this but I find it crazy that people now act like generating HTML server side is a genius new idea that is going to replace JS Frameworks. Isn’t that kind of the default and the SPA Frameworks were the new idea? Imagine telling a PHP dev that you’re now rendering your HTML server side! I’m happy to be corrected if I’m wrong here but it’s very weird from my view.
I don't disagree with your point, but you don't seem to be actually reacting to anything really present in the submission.
Afaict nowhere is it being presented as a new or genius idea, or is it suggesting it will replace SPA frameworks. These all seem to be things you've projected on to the submission.
I was mainly responding to this paragraph in the submission:
> The HMPL template language extends the capabilities of regular HTML by adding query objects to the markup to reduce the code on the client. When writing SPA, a large amount of javascript code is generated, which is loaded when the user visits the site, so the loading speed can be quite slow. All this can be avoided by generating the markup on the server and then loading it on the client:
< some code >
Let's say that the same code on popular frameworks such as Vue and others takes up much more code, which, in fact, can be moved to the server.
Maybe I’m misinterpreting but this seems to say that this approach is an improvement over SPAs. My point is that this is basically what everyone else has done all the time before SPAs were even a thing.
Thank you very much for your feedback! This idea has been discussed and used in web development for quite some time now. I am certainly not inventing anything new, but I think the idea of combining the template language approach and server requests to get a UI looks interesting.
Everything is a cycle.. for example I am using graphql at work and being heavily reminded of the WSDL and WCF of old
The horse-shoe theory of web development:
In the end, it bends back to HTML5, CSS, JS with Jquery, and PHP + MySQL :D
True and tested, get running in under 1 minute and you already have a working prototype at the end of the day.
I prefer the skateboarding half-pipe theory. We keep going back and forth, and people do some crazy tricks at each end.
Hopefully not back to punched cards for input
The benefit of rendering JS/React on both the client and the server is shared languages, code, and logic in both environments. That's the "new idea".
Hello! Thank you very much for your comment! I described in more detail the example of use here - https://dev.to/antonmak1/how-to-reduce-javascript-file-size-...
You are correct. It's just that, Javascript wants to re-do backend and Rust wants to rewrite everything these days.
Rust is rapidly making strides on the front-end, through WebAssembly and Tauri.
can someone smarter than me please point out what the differences are between HMPL and HTMX?
https://hmpl-lang.github.io/blog/blog/2024/08/10/differences...
thank you for expanding, although I am still not entirely sure I understand why I would use one or the other.
I might just be dense :D
Its a few kb smaller, though I wouldnt trust it to stay that way.
Thank you very much for your feedback! This is a template language oriented primarily to work via JavaScript. It does not functionally interact with the real DOM in any way. You create separate objects with nodes. Also, the syntax is based on passing objects "to HTML", while HTMX works via attributes. I have long wanted to make a full-fledged article on this topic, but I never got around to it. I am already tired of just writing the same thing over and over again.
It's entirely my fault that I haven't written an article on this topic yet.
Ah sweet finally I don't have to use JavaScript to make websites
*looks inside, it's JavaScript*
Thank you very much for your feedback! No, it's just great to work through javascript. Moving away from javascript is not intended. It's the opposite: a connection with the server, passing the RequestInit object, and other similar things!
Isn’t this what rpc/pbs/code-gen theoretically does? Markup/down sent? Then you don’t have to worry about the client or server language but settle on a subset of features somewhere.
My flow is that focusing on the data structure and methods allows the UI to be completely abstract. Not in a magic way but in a “maybe we should use cross compile this into C++ and use OpenGL if the UI becomes too complex. This is how you get AutoCad or film editing software running essentially as a Proton/video game runs.
When your app gets beyond a certain level of complexity (window composition, etc) yeah there’s ways to make it happen.
Regarding the standards that should be applied to template languages - all this will be adjusted as it develops. This module comes as a new idea that I would like to implement into a really good product. Even when working on Cample, I thought about something similar.
I’m currently learning frontend (vanilla JS and bootstrap) and client-side render the UI for some of my ideas.
From my understanding, modern frameworks(React) use both. Why would you limit yourself to just server-side? Isn’t there a trade off between server-side and client-side rendering?
My rule of thumb is to render HTML where the state lives.
When state lives on the server, usually in a database, leave your templating engine there and ship HTML.
When state only lives in the client, think temporary UI state or animations, that rendering needs to happen in the client.
At least for the kinda of sites and apps I build, that almost always means most of the rendering is done on the server and client rendering is so small in scope that I don't need more than plain old JS or a web component.
Thank you very much for your feedback! In short, it's about theories like SPA, SSR and others. There are different approaches to creating web applications with their pros and cons. This template language is simply an implementation of one of these ideas. You can make websites using PHP (working with WP and other similar things), and through frameworks that use SSR as a basis and others.
Previous discussion: https://news.ycombinator.com/item?id=41043410
Thank you very much to everyone for your feedback on the template language!
Big thanks to thunderbong for making this thread. I just noticed it, sorry.
So it's sort like Jinja?
I haven't used Python that often, so I can't say for sure.
Thank you very much for your feedback!
[flagged]
Thank you very much for creating a video about the template language review! I have just started making it and it is not yet included in any databases.
To save someone a click, this is an off the cuff review of it, followed by a suggestion to add it to a directory site run by the author that has an unusual interface that repurposes the back button (if you follow one or more internal links, the back button loops).
> if you follow one or more internal links, the back button loops
This should not happen.
Any chance you could record a Loom (or other screencast tool), showing me what you mean?
That way I can add a fix to our open source, public domain database of languages (https://github.com/breck7/pldb), which I thought could really help the OP, who is building a new language.
2 replies →