←back to thread

262 points gherkinnn | 2 comments | | HN request time: 0.399s | source
Show context
LeanderK ◴[] No.42164427[source]
I am no frontend-guy, so I don't understand why in the age of node.js web-servers this ditchonomy exists between server-side and client side (SPA). Can't you initialise/pre-render most of your your stuff on the server, serialise it and push it through the client, which then acts as an SPA already initialised and then updates itself on its own. After all, both are JS? Why is the decision not more flexible where to run code, depending on latency, compute intensity etc. Maybe someone can enlighten me, as this is often left out, probably because it is obvious to someone working with these technologies.
replies(9): >>42164450 #>>42164469 #>>42164560 #>>42164821 #>>42165330 #>>42165406 #>>42165705 #>>42170789 #>>42175450 #
1. ec109685 ◴[] No.42165406[source]
On the server, applications are generally super close to their backend dependencies, so multiple round trips to data stores, caches and whatnot are no problem. On the client, this would be deadly.

So it’s not just easy to take code that runs on the server and run it on the client. Anytime the client needs to do more than one round trip, it would have been faster to render the data completely on the server, html included.

Additionally, with SPA’s there’s a lot of nuance around back/forward handling, page transitions, etc. that make a page based application awkward to turn into a purely client side one.

replies(1): >>42168316 #
2. jiggawatts ◴[] No.42168316[source]
> t would have been faster to render the data completely on the server, html included.

OData batch, GraphQL, and similar technologies exist to reinvent this wheel:

"What if instead of a hundred tiny calls we made one high-level request that returned a composite formatted response that includes everything the client needs to show the next state."

Also known has... server-side rendered HTML like we did since the 1990s.