4 ms·

All of this can be achieved using nginx or apache. Crazy that rust stuff just gets upvoted. Also “server side rendering” as a term just needs to go away. Serv

All of this can be achieved using nginx or apache. Crazy that rust stuff just gets upvoted. Also “server side rendering” as a term just needs to go away. Serving HTML is the way it all started.

patmorgan23 3y ago
Server side rendering is different from serving static HTML or template generated HTML.
- madeofpalk 3y ago
  What's the difference between "Server side rendering" or "template generated HTML"? Stuff like React is just fancy HTML templates.
  - JimDabell 3y ago
    They are the same thing. Template-generated HTML has been called server-side rendering for decades. People immersed in development using front-end JavaScript frameworks have been sufficiently isolated from server-side rendering for long enough that it’s a foreign concept. A recent optimisation in front-end frameworks is to generate the initial HTML on the server instead of sending an empty shell that does nothing but load the JavaScript application. As you point out, this is just server-side rendering, which is a very old concept. However, if you have spent the majority of your time with front-end frameworks, “SSR” is a new concept that has recently been invented, not that old thing that people used to do before front-end JavaScript frameworks took over the world.
jjtheblunt 3y ago
I think you're missing the point that people don't necessarily want to deal with either nginx or apache, and might want to only have whatever application they're working on present an http(s) interface/api directly from itself. I've done that sort of thing explicitly in the past, with great results, which is why I think you overlooked such. I also think you're missing the idea that server side rendering implies a class of network traffic reductions, with resulting UX improvements. An example might would be that a subset of possible javascript, which might have been sent to a browser which was "Serving HTML", might be responsible for resulting network requests right back to the server serving the html. And this pointless network traffic which uses nothing on the browser except a javascript engine might be identified and run with no network overhead on the server, which is serving whatever in the first place. i.e., it's a network traffic 'optimization' since latency is a big deal in UX. You could read up on server side rendering ideas at https://bun.sh https://bun.sh or https://deno.com https://deno.com for just two examples.
SPBS 3y ago
I had to re-read OP's post multiple times just to understand that he was trying to serve static HTML pages alongside a Rust application at /api. It's not very clear, he only mentions the Rust server for the first time at the last section of the article. And yeah, he could have still used nginx.
throwawaytodey 3y ago
[dead]

All of this can be achieved using nginx or apache. Crazy that rust stuff just gets upvoted. Also “server side rendering” as a term just needs to go away. Serving HTML is the way it all started.

patmorgan23 3y ago

Server side rendering is different from serving static HTML or template generated HTML.

madeofpalk 3y ago
What's the difference between "Server side rendering" or "template generated HTML"? Stuff like React is just fancy HTML templates.
- JimDabell 3y ago
  They are the same thing. Template-generated HTML has been called server-side rendering for decades. People immersed in development using front-end JavaScript frameworks have been sufficiently isolated from server-side rendering for long enough that it’s a foreign concept. A recent optimisation in front-end frameworks is to generate the initial HTML on the server instead of sending an empty shell that does nothing but load the JavaScript application. As you point out, this is just server-side rendering, which is a very old concept. However, if you have spent the majority of your time with front-end frameworks, “SSR” is a new concept that has recently been invented, not that old thing that people used to do before front-end JavaScript frameworks took over the world.

jjtheblunt 3y ago

I think you're missing the point that people don't necessarily want to deal with either nginx or apache, and might want to only have whatever application they're working on present an http(s) interface/api directly from itself. I've done that sort of thing explicitly in the past, with great results, which is why I think you overlooked such. I also think you're missing the idea that server side rendering implies a class of network traffic reductions, with resulting UX improvements. An example might would be that a subset of possible javascript, which might have been sent to a browser which was "Serving HTML", might be responsible for resulting network requests right back to the server serving the html. And this pointless network traffic which uses nothing on the browser except a javascript engine might be identified and run with no network overhead on the server, which is serving whatever in the first place. i.e., it's a network traffic 'optimization' since latency is a big deal in UX. You could read up on server side rendering ideas at https://bun.sh https://bun.sh or https://deno.com https://deno.com for just two examples.

SPBS 3y ago

I had to re-read OP's post multiple times just to understand that he was trying to serve static HTML pages alongside a Rust application at /api. It's not very clear, he only mentions the Rust server for the first time at the last section of the article. And yeah, he could have still used nginx.

throwawaytodey 3y ago

[dead]