4 ms·

Fortunately the web is starting (very slowly) to return to sanity, pushing back towards the simpler server-rendered pattern with Javascript being relegated to s

Fortunately the web is starting (very slowly) to return to sanity, pushing back towards the simpler server-rendered pattern with Javascript being relegated to specific use cases.

Aeolun 2y ago
I really like the client rendered UI part. It’s a lot more efficient than sending the whole page again every time.
- gonzo41 2y ago
  But you can cache the whole server side page and the cost is once. Whereas if you have the client side do the render then every client wears the cost.
  - iknowstuff 2y ago
    You usually can't because of users who are signed in needing slightly different pages etc.
    - bdcravens 2y ago
      While not as fast as a purely client cached page, the server can selectively cache content, even when some bits of the page are dynamic.
  - asynchronous 2y ago
    We can also cache some of the dynamic JavaScript, depending on the scenario but your point stands.
  - bdcravens 2y ago
    Which becomes a far more important issue when dealing with bandwidth or CPU constrained devices, or artificially imposed constraints due to data usage costs.
  - Aeolun 2y ago
    That’s your generation that happens once. The browser still needs to render it. Sure, rendering it on the client may cost the client a bit more, but the client generally has the computational power to spare.
- bdcravens 2y ago
  Which is precisely what is meant by specific use cases. We don't have to throw out the first 25 years of the web and reimplement all of our business logic in a minified JS blob. Even when client side code is necessary, the trend of pushing rendered HTML rather than JSON that must be parsed and rendered keeps us as close to browser primitives as possible.
  - Aeolun 2y ago
    Why would you implement the business logic there? You can still keep (most of) that in the backend. The client just does orchestration.
    - bdcravens 2y ago
      Once you move beyond basic CRUD business requirements work their way into the UI. For instance, making fields read-only based on access level. Adding additional form fields, etc. Conditionally hiding and showing entire portions of the UI. All of which requires you to either pass around UI-directives in your data or implement business logic in your client code. Better to just ship HTML, and if we're worried about full page loads, just use one of the many over-the-wire options to only change small bits of a page. This is before we get into having to implement application primitives like authentication on the client, and all of the state management that goes with. The absolute amount of scaffolding and plumbing we've built up just to save a few ms is always worth questioning. Doesn't mean the answer is no, just that we need to ask the question and not assume the default is carved in stone.

Fortunately the web is starting (very slowly) to return to sanity, pushing back towards the simpler server-rendered pattern with Javascript being relegated to specific use cases.

Aeolun 2y ago

I really like the client rendered UI part. It’s a lot more efficient than sending the whole page again every time.

gonzo41 2y ago
But you can cache the whole server side page and the cost is once. Whereas if you have the client side do the render then every client wears the cost.
- iknowstuff 2y ago
  You usually can't because of users who are signed in needing slightly different pages etc.
  - bdcravens 2y ago
    While not as fast as a purely client cached page, the server can selectively cache content, even when some bits of the page are dynamic.
- asynchronous 2y ago
  We can also cache some of the dynamic JavaScript, depending on the scenario but your point stands.
- bdcravens 2y ago
  Which becomes a far more important issue when dealing with bandwidth or CPU constrained devices, or artificially imposed constraints due to data usage costs.
- Aeolun 2y ago
  That’s your generation that happens once. The browser still needs to render it. Sure, rendering it on the client may cost the client a bit more, but the client generally has the computational power to spare.
bdcravens 2y ago
Which is precisely what is meant by specific use cases. We don't have to throw out the first 25 years of the web and reimplement all of our business logic in a minified JS blob. Even when client side code is necessary, the trend of pushing rendered HTML rather than JSON that must be parsed and rendered keeps us as close to browser primitives as possible.
- Aeolun 2y ago
  Why would you implement the business logic there? You can still keep (most of) that in the backend. The client just does orchestration.
  - bdcravens 2y ago
    Once you move beyond basic CRUD business requirements work their way into the UI. For instance, making fields read-only based on access level. Adding additional form fields, etc. Conditionally hiding and showing entire portions of the UI. All of which requires you to either pass around UI-directives in your data or implement business logic in your client code. Better to just ship HTML, and if we're worried about full page loads, just use one of the many over-the-wire options to only change small bits of a page. This is before we get into having to implement application primitives like authentication on the client, and all of the state management that goes with. The absolute amount of scaffolding and plumbing we've built up just to save a few ms is always worth questioning. Doesn't mean the answer is no, just that we need to ask the question and not assume the default is carved in stone.