4 ms·

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 Framew

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.

synergy20 2y ago
You are correct. It's just that, Javascript wants to re-do backend and Rust wants to rewrite everything these days.
- benatkin 2y ago
  Rust is rapidly making strides on the front-end, through WebAssembly and Tauri.
slater 2y ago
The horse-shoe theory of web development: In the end, it bends back to HTML5, CSS, JS with Jquery, and PHP + MySQL :D
- sourcecodeplz 2y ago
  True and tested, get running in under 1 minute and you already have a working prototype at the end of the day.
- kopirgan 2y ago
  Hopefully not back to punched cards for input
- sam_bristow 2y ago
  I prefer the skateboarding half-pipe theory. We keep going back and forth, and people do some crazy tricks at each end.
robertoandred 2y ago
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".
Normal_gaussian 2y ago
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.
- echoangle 2y ago
  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.
- antonmak1 2y ago
  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.
deleted 2y ago
[deleted]
mattchamb 2y ago
Everything is a cycle.. for example I am using graphql at work and being heavily reminded of the WSDL and WCF of old
antonmak1 2y ago
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-on-client-4kb3 https://dev.to/antonmak1/how-to-reduce-javascript-file-size-...

synergy20 2y ago

You are correct. It's just that, Javascript wants to re-do backend and Rust wants to rewrite everything these days.

benatkin 2y ago
Rust is rapidly making strides on the front-end, through WebAssembly and Tauri.

slater 2y ago

The horse-shoe theory of web development: In the end, it bends back to HTML5, CSS, JS with Jquery, and PHP + MySQL :D

sourcecodeplz 2y ago
True and tested, get running in under 1 minute and you already have a working prototype at the end of the day.
kopirgan 2y ago
Hopefully not back to punched cards for input
sam_bristow 2y ago
I prefer the skateboarding half-pipe theory. We keep going back and forth, and people do some crazy tricks at each end.

robertoandred 2y ago

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".

Normal_gaussian 2y ago

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.

echoangle 2y ago
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.
antonmak1 2y ago
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.

deleted 2y ago

[deleted]

mattchamb 2y ago

Everything is a cycle.. for example I am using graphql at work and being heavily reminded of the WSDL and WCF of old

antonmak1 2y ago

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-on-client-4kb3 https://dev.to/antonmak1/how-to-reduce-javascript-file-size-...