[deleted]
Server-side rendering is a better choice for many applications (2020)
281–286 of 286 posts
Re: Server-side rendering is a better choice for many applications (2020)
#282Earlier quoted context omitted.
This reply comes off as needlessly rude, but I'll give you the benefit of the doubt that it's just intent not coming across well via text. In the context of the comment to which you're replying[0] I'm not sure how else to take your comment. OK, you don't like HN's UX, that's either a comment on SSR and on topic for the thread, or completely unrelated. > HN as a site is a perfect example of how bad a SSR experience ca…
My point is that this site is not a good example to use for showing SSR in a good light. Logically, this doesn't mean the converse of the statement is implied (that if this site didn't use SSR, it would be good).
From a pure UX perspective, I agree. User experience is outside of any technology. Apple Magic Mouse is a technological marvel, but UX sucked.
Re: Server-side rendering is a better choice for many applications (2020)
#283Earlier quoted context omitted.
Why would the elements HAVE to be loaded for different roles? You're talking as if every single client-side app approaches authorization and authentication the same way and that's just not true. There's no attack surface here at all, the only issue with most client-side apps and interaction with server comes from CORS and devs copypasting solutions from SO to get rid of the warning, thus creating the attack surface.…
Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider.. that’s why you have JWTs and stuff like that. Architecturally when you have a session management system, where state is able to be maintained per user usually up by the same thread on the same physical server. that’s going to be more secure than a horizontally…
> Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider
No, the whole point of client-side rendering is to apply parasitic computing and offload the server by having the client perform work it can thus saving the bandwith and compute power.
Next benefit is application that's "snappy" and works well, which is what almost never happens sadly.
> that’s why you have JWTs and stuff like that.
No, you don't have JWT and "stuff like that" because of this. JWT is for offloading databases so you don't have to talk to a DB on every request since you can verify the token via signature check and thus implement distributed services that don't have to talk to central authority to authorize a request.
> where state is able to be maintained per user usually up by the same thread on the same physical server
And now you're trying to sound smart by adding servers and "threads". I've a feeling you're pulling my leg right now so I'll excuse myself since you started spouting absolute nonsense.
Re: Server-side rendering is a better choice for many applications (2020)
#284Earlier quoted context omitted.
A lot of it could be improved with some CSS changes (scaling etc) as a sprinking of javascript which could handle commenting without reloads. My opinion is that it's perfect for what it is, a discussion board and nothing more. It's not a social media site.
Not that this should be the answer, but there are a lot of HN browser plugins. Most have at least some level of theming and inline commenting. I'm currently a fan of Refined Hacker News (no affiliation) - https://github.com/plibither8/refined-hacker-news - but I'm sure there are others just as good out there.
Thank you for the suggestion, it looks great!
Re: Server-side rendering is a better choice for many applications (2020)
#285All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.
My thoughts exactly. Although I don't see it as a devaluation. It's just not that convinient. And yes I admit, after years of working with a clear component system it is hard to go back to templates. They are just not it...
I would really appreciate some advice, which template engine is good enough and how to organize with it something similar to how we write components in all these FE frameworks.
Re: Server-side rendering is a better choice for many applications (2020)
#286Earlier quoted context omitted.
Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider.. that’s why you have JWTs and stuff like that. Architecturally when you have a session management system, where state is able to be maintained per user usually up by the same thread on the same physical server. that’s going to be more secure than a horizontally…
> Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider No, the whole point of client-side rendering is to apply parasitic computing and offload the server by having the client perform work it can thus saving the bandwith and compute power. Next benefit is application that's "snappy" and works well, which is what al…
What are you talking about? It’s well-known that Apache has a philosophy that every connection should be serviced by its own thread, whereas NGINX is an event driven architecture which means you have a thread-pool: think of it this way it’s like having the same dedicated waiter at a restaurant versus having the first available waiter come service your table or refill your drink, even if that waiter is different each time.
Concerning JWT, I think we were talking past each other as I was referring to a session-less Authentication scheme, which is more or less what you describe.
Finally, there’s no reason why the server can’t render JavaScript as well other parts of the page. In effect, if the server wanted to, it could render of a reactive version or an angular version depending on a variable. Can the client do that?