←back to thread

260 points gherkinnn | 2 comments | | HN request time: 0.404s | 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. the__alchemist ◴[] No.42164450[source]
I'm answering your initial question directly, but there is more going on that may be more informative.

This is a distinction between computation that is performed on a server, using arbitrary tools, and computation run on a user's machine locally. The former is much more flexible, but comes at a cost of latency; all user input and output must be serialized, and transmitted a long distance. Front end code can result in much lower latency to the user due to ommitting this transmission.

It makes sense to apply a suitable mix of these two tools that varies based on an application's details. For example, an immediate UI response that can be performed using only information already present on the client makes sense to be handled exclusively there, as computation time is minimal compared to transmission and serializtion.

I believe that JS being able to be used on a server is not relevant to the core distinction.

replies(1): >>42183476 #
2. Terretta ◴[] No.42183476[source]
Though, as most apps are built, only the code run on the server can be trusted, and only the response processing performed on the server can be trusted.