4 ms·

You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in man

You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in many implementations. I worked in a team that supported this type of architecture in a research platform serving thousands of concurrent users with a single server. It scales if you do it right. --EDIT-- I'm going to give you a great example. This very site. HN renders everything on the server (in a dialect of Lisp!) and it's a pretty small cluster that is supporting more users than most webapps dream of.

gedrap 10y ago
Totally. I see this argument about offloading the load to the client so often, that I am left thinking whether I am the only one here working on a project with less than a few thousands of requests every second :) It's good to have performance and scalability in mind but so often it just doesn't matter.
hhsnopek 10y ago
My justification is that not everyone will implement the scaling properly - we do have a lot of server-side apps that properly scale, but depending on the operation it seems the client-side is a better suited pattern
- binarymax 10y ago
  Straw man. Using a client side approach does not automagically grant you scalability.
  - tremon 10y ago
    Indeed. It does allow you to offload the scalability problems to your users though, and they won't easily tie the draining of their batteries to your site/app.
  - hhsnopek 10y ago
    You're correct, as it does not grant scalability. Tho if my application lives on the client-side, I can distribute the cached application which contains all the user needs. This provides less worry when my server crashes and will still allow my users to access and use my site. Tho will fail if my API's are not accessible. Which then comes down to identifying and breaking the bottleneck. CDN's can also help with my scaling as I can just distribute the bundled up version and live beyond internet access so long as I've built application to be progressive (https://developers.google.com/web/progressive-web-apps https://developers.google.com/web/progressive-web-apps) I can now just notify my application to update next time the user connects to the internet. Tho if my application where to only live with the server rendering my information, I wouldn't be able to periodically lose my "stable" connection and my application would be rendered useless. Tho this solution is adaptable to server-side applications, you'll need to use javascript to do so. And I believe that settles why we need javascript in your applications. If I can't access your sever-side application because it's flooded with requests and the cached version of your site relies on the server then I believe you've failed your users. The solution to scalability for both server-side and client-side applications are complex, but only one of them depends on a server being around while the other relies on a cached copy.
deleted 10y ago
[deleted]

gedrap 10y ago

Totally. I see this argument about offloading the load to the client so often, that I am left thinking whether I am the only one here working on a project with less than a few thousands of requests every second :) It's good to have performance and scalability in mind but so often it just doesn't matter.

hhsnopek 10y ago

My justification is that not everyone will implement the scaling properly - we do have a lot of server-side apps that properly scale, but depending on the operation it seems the client-side is a better suited pattern

binarymax 10y ago
Straw man. Using a client side approach does not automagically grant you scalability.
- tremon 10y ago
  Indeed. It does allow you to offload the scalability problems to your users though, and they won't easily tie the draining of their batteries to your site/app.
- hhsnopek 10y ago
  You're correct, as it does not grant scalability. Tho if my application lives on the client-side, I can distribute the cached application which contains all the user needs. This provides less worry when my server crashes and will still allow my users to access and use my site. Tho will fail if my API's are not accessible. Which then comes down to identifying and breaking the bottleneck. CDN's can also help with my scaling as I can just distribute the bundled up version and live beyond internet access so long as I've built application to be progressive (https://developers.google.com/web/progressive-web-apps https://developers.google.com/web/progressive-web-apps) I can now just notify my application to update next time the user connects to the internet. Tho if my application where to only live with the server rendering my information, I wouldn't be able to periodically lose my "stable" connection and my application would be rendered useless. Tho this solution is adaptable to server-side applications, you'll need to use javascript to do so. And I believe that settles why we need javascript in your applications. If I can't access your sever-side application because it's flooded with requests and the cached version of your site relies on the server then I believe you've failed your users. The solution to scalability for both server-side and client-side applications are complex, but only one of them depends on a server being around while the other relies on a cached copy.

deleted 10y ago

[deleted]