6 ms·

“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the clie

“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.

deleted 4y ago
[deleted]
dylan604 4y ago
I'm of two minds. I want agree with you of well formed DOM for the browser to render. That's great. Now, do we have to go all the way back to flat files where the whole page has to refresh to update one silly field or selection update? No, we don't have to go full cave man for that. We can still use the front end to make changes after the initial load. we don't need an app to be running in each user's browser for a large majority of places where this is happening.
- forgotmypw17 4y ago
  Yes, the best of both worlds. Fast-loading, complete, cacheable, archivable pages. And DOM changes for updating them without reloading the entire page.
wg0 4y ago
Basically, by those standards, ngnix is the most popular server side renderer ATM. It can beautifully render HTML and pretty much any file format. It can even render video files and with Ngnix plus, you get bit more server side rendering for vidoe files too. Apache used to be a good server side renderer too but those were the old days.
revskill 4y ago
I guess you're a backend dev watching all frontend framework shines with a jealous eyes. Keep watching :) Those heavyweight framework exist for a reason, they're not born out of thin air. It's about your use case, you don't need it for other's use case.
- altdataseller 4y ago
  Trust me. Nobody is jealous of that stuff :)
  - revskill 4y ago
    Trust me, everything exits for a reason, to solve (maybe specific problem). It's nonsensical to want it to die for "no reason".
    - altdataseller 4y ago
      Not arguing they aren't useful. Just that no backend dev is ever jealous of what's happening with front end frameworks.
      - habibur 4y ago
        Another interesting question : are frontend developers jealous of what the backend developers are doing, or are they not?
        stcroixx 4y ago
        I sure was when I had to do front end work. Finally got out of anything front-end for good and it's probably been the single most pleasant change in my career ever. I didn't start out doing front end work though, so I could see while I was doing it how ridiculous it was compared to almost any other domain in software dev and only getting worse. A good portion of front end devs I meet have not done anything else so they don't have a point of reference.
        splistud 4y ago
        [dead]
    - namaria 4y ago
      Just not always a good reason. You're not breaking ground here by having stumbled upon the concept of causality.
cristianpascu 4y ago
“A plain .html file” - This made me chuckle. :)
cyral 4y ago
> Well done, modern devs! A plain .html file does that And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it.
- marcosdumay 4y ago
  There is nothing wrong with parseInt(document.getQuerySelector(".item > .item__quantity"), except for it not being parseInt(document.getElementById("uniqueAutogeneratedId")). Developers just shouldn't write that kind of fragile code by hand. But there's nothing wrong at all with the code being there.
  - bmikaili 4y ago
    That is literally fragile code. You contradict yourself. I really want to see any of the people that hate on modern frameworks build any complex web app in a reasonable amount of time with the same level of stability as using i.e. SvelteKit
    - marcosdumay 4y ago
      As a rule, every code that people actually run is fragile. A small change could break anything, and there are almost no safety checks. Things only work because it's not people that create it.
    - revskill 4y ago
      Two way binding is the future ?
- unity1001 4y ago
  > And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place And that's what most of the web needs - few use cases require having to manipulate every bit of the dom to send constant updates to the end-user. Social networks, financial sites, banks, betting sites etc. The rest do not need these heavy frameworks and the extensive dom manipulating capability. The last thing you want in an ecommerce checkout process is to distract the user by manipulating the dom to give him 'updates'. So nobody does anything like updating the user with info like 'latest prices', 'your friend just bought this' etc right in the middle of the checkout process. Same goes for blogs, most of publishing.
umvi 4y ago
> Well done, modern devs! A plain .html file does that. Yes but a plain html file is static, so that's not going to work unless your site is purely static (i.e. a blog).
- rightbyte 4y ago
  You can do both post and get. That is all you need really to make anything work unless your are doing spyware and like graphical applications such as maps and what not. Static pages are easier on Mother Earth too.
  - umvi 4y ago
    Yeah but the point of "serverside rendering" is that you can just fill in the dynamic values serverside and serve plain html instead of needing a bunch of javascript and dom manipulation
shams93 4y ago
yeah people demand this overkill without understanding what they are demanding. Everyone seems to use react so we must also use react, then the site no longer works for mobile so then you also need react native. All when you can use vanilla js to do the small bits needed for a PWA from one simple codebase.
- nawgz 4y ago
  > then the site no longer works for mobile What a comical misunderstanding, only to use it to demand people stop using frameworks. You seem to have said it best > people demand ... without understanding what they are demanding
- anthk 4y ago
  Simple CSS files can solve that.
JayStavis 4y ago
Point certainly taken but I think that "rendering" is the overloaded term. Rendering basically means, to take data & logic and transform it into a view for another system (or person). Graphical rendering is probably the needed operative word for this point? A bit of annoying semantics but I think rendering just means to provide a structured view for some state.
voytec 4y ago
Server can render HTML code. Browser renders visual representation of HTML code.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
robertoandred 4y ago
How can a plain html file pull content from a database?

deleted 4y ago

[deleted]

dylan604 4y ago

I'm of two minds. I want agree with you of well formed DOM for the browser to render. That's great. Now, do we have to go all the way back to flat files where the whole page has to refresh to update one silly field or selection update? No, we don't have to go full cave man for that. We can still use the front end to make changes after the initial load. we don't need an app to be running in each user's browser for a large majority of places where this is happening.

forgotmypw17 4y ago
Yes, the best of both worlds. Fast-loading, complete, cacheable, archivable pages. And DOM changes for updating them without reloading the entire page.

wg0 4y ago

Basically, by those standards, ngnix is the most popular server side renderer ATM. It can beautifully render HTML and pretty much any file format. It can even render video files and with Ngnix plus, you get bit more server side rendering for vidoe files too. Apache used to be a good server side renderer too but those were the old days.

revskill 4y ago

I guess you're a backend dev watching all frontend framework shines with a jealous eyes. Keep watching :) Those heavyweight framework exist for a reason, they're not born out of thin air. It's about your use case, you don't need it for other's use case.

altdataseller 4y ago
Trust me. Nobody is jealous of that stuff :)
- revskill 4y ago
  Trust me, everything exits for a reason, to solve (maybe specific problem). It's nonsensical to want it to die for "no reason".
  - altdataseller 4y ago
    Not arguing they aren't useful. Just that no backend dev is ever jealous of what's happening with front end frameworks.
    - habibur 4y ago
      Another interesting question : are frontend developers jealous of what the backend developers are doing, or are they not?
      - stcroixx 4y ago
        I sure was when I had to do front end work. Finally got out of anything front-end for good and it's probably been the single most pleasant change in my career ever. I didn't start out doing front end work though, so I could see while I was doing it how ridiculous it was compared to almost any other domain in software dev and only getting worse. A good portion of front end devs I meet have not done anything else so they don't have a point of reference.
        splistud 4y ago
        [dead]
  - namaria 4y ago
    Just not always a good reason. You're not breaking ground here by having stumbled upon the concept of causality.

cristianpascu 4y ago

“A plain .html file” - This made me chuckle. :)

cyral 4y ago

> Well done, modern devs! A plain .html file does that And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it.

marcosdumay 4y ago
There is nothing wrong with parseInt(document.getQuerySelector(".item > .item__quantity"), except for it not being parseInt(document.getElementById("uniqueAutogeneratedId")). Developers just shouldn't write that kind of fragile code by hand. But there's nothing wrong at all with the code being there.
- bmikaili 4y ago
  That is literally fragile code. You contradict yourself. I really want to see any of the people that hate on modern frameworks build any complex web app in a reasonable amount of time with the same level of stability as using i.e. SvelteKit
  - marcosdumay 4y ago
    As a rule, every code that people actually run is fragile. A small change could break anything, and there are almost no safety checks. Things only work because it's not people that create it.
  - revskill 4y ago
    Two way binding is the future ?
unity1001 4y ago
> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place And that's what most of the web needs - few use cases require having to manipulate every bit of the dom to send constant updates to the end-user. Social networks, financial sites, banks, betting sites etc. The rest do not need these heavy frameworks and the extensive dom manipulating capability. The last thing you want in an ecommerce checkout process is to distract the user by manipulating the dom to give him 'updates'. So nobody does anything like updating the user with info like 'latest prices', 'your friend just bought this' etc right in the middle of the checkout process. Same goes for blogs, most of publishing.

umvi 4y ago

> Well done, modern devs! A plain .html file does that. Yes but a plain html file is static, so that's not going to work unless your site is purely static (i.e. a blog).

rightbyte 4y ago
You can do both post and get. That is all you need really to make anything work unless your are doing spyware and like graphical applications such as maps and what not. Static pages are easier on Mother Earth too.
- umvi 4y ago
  Yeah but the point of "serverside rendering" is that you can just fill in the dynamic values serverside and serve plain html instead of needing a bunch of javascript and dom manipulation

shams93 4y ago

yeah people demand this overkill without understanding what they are demanding. Everyone seems to use react so we must also use react, then the site no longer works for mobile so then you also need react native. All when you can use vanilla js to do the small bits needed for a PWA from one simple codebase.

nawgz 4y ago
> then the site no longer works for mobile What a comical misunderstanding, only to use it to demand people stop using frameworks. You seem to have said it best > people demand ... without understanding what they are demanding
anthk 4y ago
Simple CSS files can solve that.

JayStavis 4y ago

Point certainly taken but I think that "rendering" is the overloaded term. Rendering basically means, to take data & logic and transform it into a view for another system (or person). Graphical rendering is probably the needed operative word for this point? A bit of annoying semantics but I think rendering just means to provide a structured view for some state.

voytec 4y ago

Server can render HTML code. Browser renders visual representation of HTML code.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

robertoandred 4y ago

How can a plain html file pull content from a database?