Comment by echoangle
1 year ago
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.