4 ms·

> but the more is offloaded to the client, the less scaling demand is placed on the server -- as you get more users, the additional resource needs are met by th

> but the more is offloaded to the client, the less scaling demand is placed on the server -- as you get more users, the additional resource needs are met by their clients rather than by your server. I'm sorry, but this is the kind of thinking that is perpetuating this awful paradigm. As you get more users your data set grows. Are your clients going to be responsible for the memory necessary for the larger indexes? What about your cache, should we just introduce HTTP into the caching mechanism and hope that one of your clients has the data you wanted to deliver to someone else? Are your clients going to be responsible for ensuring you don't max out your server with the amount of processes your httpd can handle? Are your clients going to be responsible for load-balancing your requests between servers because your pipes are simply not big enough to be handled by a single web-server? When was the last time you saw a person lugging around 16+ cores with 64GB of memory, SSD architecture, and fibre networking tied into multiple switches? > the more is offloaded to the client, the less scaling demand is placed on the server -- as you get more users, the additional resource needs are met by their clients rather than by your server. Clients are not replacements for servers at all. Why do people keep thinking that they're somehow being clever "offloading" work to the client? Do they know how much work has been put into networking stacks to ensure this type of offloading never happens? How is it that you scale your clients? Do you ship them more memory? Pay more for their Internet connection? Send them a new phone? Decades of networking work, by extremely talented individuals, to make sure the client has to do very little lifting at the layers closer to the metal by people much, much smarter than us. Ignorantly nullified by a developer's misguided desires.

orthecreedence 12y ago
I'd like to reply because I use this paradigm quite often (shipping work to the client). What I used to do was this: write an API, write a web layer that talks to the API and serves up HTML, and write a bunch of javascript that runs in the browser give the app a bit more juice. What ended up happening as more and more browsers started to not completely suck is I moved 99% of the web tier that sits inbetween the API and the browser into javascript. When clients hit the app, they download the entire app: javascript, HTML templates (not fully rendered views), etc. The javascript ties everything together and uses pushState to replicate what happens when a user is browsing a normal HTML page. Any data that is needed is grabbed directly from the API in the background. This offers significant advantages: not only are you farming off the entire generation of your app's views to the user's browser (taking work that you would have to do yourself and distribute it), you are reducing the complexity of the app. There are now two pieces to maintain: an API and a set of javascript...no web layer in between. This makes things a lot snappier for users. Pages switch instantly because everything they need to run the app is already there and ready to go. So, no, I'm not shipping 800GB of data to each of my users and expecting them to crunch SQL queries, but I do like to send any work that I would have to do to their browsers, assuming they are capable.
chavesn 12y ago
> What about your cache, should we just introduce HTTP into the caching mechanism and hope that one of your clients has the data you wanted to deliver to someone else? HTTP caching is a standard built explicitly for this. And it's gotten better at precisely these jobs over the years (substitute for server memory and indexes). So if that "someone" is the user who has the cache, yes. > Are your clients going to be responsible for ensuring you don't max out your server with the amount of processes your httpd can handle? HTTP 307 Temporary Redirect. 420 Enhance Your Calm. Keep-alive. Etc. There are many standards in place to let the client participate in not overloading the server. The server must always be willing to deal with a new actor, but that doesn't mean that there aren't systems in place to help clients be nice to servers that are overloaded without breaking other parts of the spec (caching). > Decades of networking work, by extremely talented individuals, to make sure the client has to do very little lifting at the layers closer to the metal by people much, much smarter than us. I don't see any evidence that all that networking work is to make sure that clients don't need to do work. Instead, I see many clever systems on both client and server being created to push the boundaries of resource usage past previous limits. On the server, it sounds like you are familiar with these techniques. Load-balancing, edge-caching, distributed applications, etc. On the client, it must come about through standards and behavior specifications. If you're imagining a world where servers are placing requirements on clients before they are ready to handle them, I agree, that would be awful. Servers should always have ultimate responsibility for being a good host to any potential connection. However, once a client behavior standard has been well agreed upon for a significant amount of time, then servers should absolutely take advantage of the behavior. Should programmers of web application skip any of the behaviors above (HTTP caching and REST), or shun JSON APIs or pushState or any of those things? No way! They should take full advantage, as long as they know what they are doing. And yes, you do have to still be a responsible citizen (for your own good as much as anyone's). For example, if you use pushState, you still must keep in mind how search engines may observe your pages[1]. Using cache expirations aggressively but correctly still takes some careful planning. And so on. But the principle of "offloading" as you put brings the possibility of optimization by factor of N, where N is your audience size, instead of some constant K as many other server-side optimization are limited. This is not "nullifying" anyone's networking work. Clients, under carefully grown and tested behavior standards, _should_ be able to do some lifting. If you want to talk about user experience, that's a whole other issue. And yes, there is significant evidence (responding to your earlier comment) that things have gotten better -- just a couple years ago, web fonts were almost unusable because of the flicker that happened on load. I am sure some clients still see it, but for my own personal use, the flicker is virtually 100% gone. If the client can't display the page in a reasonable replacement time for the server, then it's a no-go. But if it can, it's a huge win and IMHO doesn't subtract anything from the (admittedly genius) networking stacks underneath. Finally, if the technology in these networking layers could so easily be nullified by so-called "ignorant" individuals, wouldn't it be not-so-brilliant to begin with? [1]: http://stackoverflow.com/a/6194427/143295 http://stackoverflow.com/a/6194427/143295
stefan_kendall3 12y ago
I battle this daily. IE9 can barely render its own chrome, let alone content on a webpage. A couple months back, a certain project I was working on was taking over 45 seconds to render. 45. seconds.
- egil 12y ago
  Have you looked into the (re)rendering on the client? We had a similar issue with an extjs application rendering dead slow on ie9. By suspending the rendering while the app was loading/transitioning (using batchLayouts in the ext case), IE loading time improved significantly.
aaronem 12y ago
I can only assume that, while you do actually have some appreciation of concepts like separation of concerns and network-based computing, you're ignoring them completely for the purpose of advancing an argument which, to those of us with extensive professional experience in such matters, is every bit as ignorant as it's suffused with utterly unwarranted condescension. Either that, or you're assuming that, because this thread revolves around a toy project which pushes literally all the work off to the client, any project of any sort which does likewise must also do exactly likewise. Granted that I'm not sure how such an assumption could possibly survive even a moment's consideration, but it seems a plausible origin for your misapprehension here, and so I feel constrained to mention it all the same. Either way, my experience has been that clients vastly prefer to see their CPU activity bump a little above idle every now and again, in exchange for a responsive and reliable user experience, rather than find themselves in a situation where, thanks to a developer who assumes today's web browsers must be on the same level of capability as the IBM-3270-with-pretty-pictures style of fifteen years ago, the server's so wound around the axle, trying to do work its clients could do faster and better, that it's unable to respond to HTTP requests at all. "But," you might sneer, "that's a problem on the backend! Do it right the first time and you don't have this problem!" Welcome to real life, where legacy code exists, and where a rewrite from scratch often isn't an option -- especially when the budget for it would have to come from a contract client who's already on a shoestring, and whose operations are funded by registrations completed through their website. In one example from a past professional engagement, the proposition I might've made would've reduced to approximately this: "I know you're facing bankruptcy because your athletes have grown frustrated with poor response and taken their registration fees to better-managed events," I might say, "but how about paying us fifteen grand to build you a completely new website from the ground up? It'll work great!" Perhaps you can conceive of a world in which such a suggestion would go over well. If so, I applaud the floridity and scope of your imagination, which must be truly unparalleled. Here in reality, we must cope as best we can with the situations in which we find ourselves. Oftentimes, that means finding some way in which the client can do part of the work -- specifically, as in the case I describe, that part which is intimately bound up with the particular user's unique experience, and whose result therefore doesn't generalize no matter where it's handled. Lest we lose track of the topic, the "static site generator" under discussion is, I grant, a very poor example of my thesis, because the work it pushes off to the client could very well be done on the server, or indeed could be done once as a compilation step and the result served statically to all comers -- it's a cute toy, but nothing I'd ever expect to see anywhere near production. But, as I said before, to attempt to generalize, from this toy project, to every case in which some work is offloaded to the client, redoles most strongly of arrogance, ignorance, and foolishness. I mean, I can appreciate that, when your major professional concern at the moment is apparently a website dedicated to giving stoners an idea of which strain of cannabis provides the best high, you probably don't have to worry much about scaling and offloading, and that's fantastic! But some of us find ourselves forced by circumstance to operate in a less utterly trivial sphere.

orthecreedence 12y ago

I'd like to reply because I use this paradigm quite often (shipping work to the client). What I used to do was this: write an API, write a web layer that talks to the API and serves up HTML, and write a bunch of javascript that runs in the browser give the app a bit more juice. What ended up happening as more and more browsers started to not completely suck is I moved 99% of the web tier that sits inbetween the API and the browser into javascript. When clients hit the app, they download the entire app: javascript, HTML templates (not fully rendered views), etc. The javascript ties everything together and uses pushState to replicate what happens when a user is browsing a normal HTML page. Any data that is needed is grabbed directly from the API in the background. This offers significant advantages: not only are you farming off the entire generation of your app's views to the user's browser (taking work that you would have to do yourself and distribute it), you are reducing the complexity of the app. There are now two pieces to maintain: an API and a set of javascript...no web layer in between. This makes things a lot snappier for users. Pages switch instantly because everything they need to run the app is already there and ready to go. So, no, I'm not shipping 800GB of data to each of my users and expecting them to crunch SQL queries, but I do like to send any work that I would have to do to their browsers, assuming they are capable.

chavesn 12y ago

> What about your cache, should we just introduce HTTP into the caching mechanism and hope that one of your clients has the data you wanted to deliver to someone else? HTTP caching is a standard built explicitly for this. And it's gotten better at precisely these jobs over the years (substitute for server memory and indexes). So if that "someone" is the user who has the cache, yes. > Are your clients going to be responsible for ensuring you don't max out your server with the amount of processes your httpd can handle? HTTP 307 Temporary Redirect. 420 Enhance Your Calm. Keep-alive. Etc. There are many standards in place to let the client participate in not overloading the server. The server must always be willing to deal with a new actor, but that doesn't mean that there aren't systems in place to help clients be nice to servers that are overloaded without breaking other parts of the spec (caching). > Decades of networking work, by extremely talented individuals, to make sure the client has to do very little lifting at the layers closer to the metal by people much, much smarter than us. I don't see any evidence that all that networking work is to make sure that clients don't need to do work. Instead, I see many clever systems on both client and server being created to push the boundaries of resource usage past previous limits. On the server, it sounds like you are familiar with these techniques. Load-balancing, edge-caching, distributed applications, etc. On the client, it must come about through standards and behavior specifications. If you're imagining a world where servers are placing requirements on clients before they are ready to handle them, I agree, that would be awful. Servers should always have ultimate responsibility for being a good host to any potential connection. However, once a client behavior standard has been well agreed upon for a significant amount of time, then servers should absolutely take advantage of the behavior. Should programmers of web application skip any of the behaviors above (HTTP caching and REST), or shun JSON APIs or pushState or any of those things? No way! They should take full advantage, as long as they know what they are doing. And yes, you do have to still be a responsible citizen (for your own good as much as anyone's). For example, if you use pushState, you still must keep in mind how search engines may observe your pages[1]. Using cache expirations aggressively but correctly still takes some careful planning. And so on. But the principle of "offloading" as you put brings the possibility of optimization by factor of N, where N is your audience size, instead of some constant K as many other server-side optimization are limited. This is not "nullifying" anyone's networking work. Clients, under carefully grown and tested behavior standards, _should_ be able to do some lifting. If you want to talk about user experience, that's a whole other issue. And yes, there is significant evidence (responding to your earlier comment) that things have gotten better -- just a couple years ago, web fonts were almost unusable because of the flicker that happened on load. I am sure some clients still see it, but for my own personal use, the flicker is virtually 100% gone. If the client can't display the page in a reasonable replacement time for the server, then it's a no-go. But if it can, it's a huge win and IMHO doesn't subtract anything from the (admittedly genius) networking stacks underneath. Finally, if the technology in these networking layers could so easily be nullified by so-called "ignorant" individuals, wouldn't it be not-so-brilliant to begin with? [1]: http://stackoverflow.com/a/6194427/143295 http://stackoverflow.com/a/6194427/143295

stefan_kendall3 12y ago

I battle this daily. IE9 can barely render its own chrome, let alone content on a webpage. A couple months back, a certain project I was working on was taking over 45 seconds to render. 45. seconds.

egil 12y ago
Have you looked into the (re)rendering on the client? We had a similar issue with an extjs application rendering dead slow on ie9. By suspending the rendering while the app was loading/transitioning (using batchLayouts in the ext case), IE loading time improved significantly.

aaronem 12y ago

I can only assume that, while you do actually have some appreciation of concepts like separation of concerns and network-based computing, you're ignoring them completely for the purpose of advancing an argument which, to those of us with extensive professional experience in such matters, is every bit as ignorant as it's suffused with utterly unwarranted condescension. Either that, or you're assuming that, because this thread revolves around a toy project which pushes literally all the work off to the client, any project of any sort which does likewise must also do exactly likewise. Granted that I'm not sure how such an assumption could possibly survive even a moment's consideration, but it seems a plausible origin for your misapprehension here, and so I feel constrained to mention it all the same. Either way, my experience has been that clients vastly prefer to see their CPU activity bump a little above idle every now and again, in exchange for a responsive and reliable user experience, rather than find themselves in a situation where, thanks to a developer who assumes today's web browsers must be on the same level of capability as the IBM-3270-with-pretty-pictures style of fifteen years ago, the server's so wound around the axle, trying to do work its clients could do faster and better, that it's unable to respond to HTTP requests at all. "But," you might sneer, "that's a problem on the backend! Do it right the first time and you don't have this problem!" Welcome to real life, where legacy code exists, and where a rewrite from scratch often isn't an option -- especially when the budget for it would have to come from a contract client who's already on a shoestring, and whose operations are funded by registrations completed through their website. In one example from a past professional engagement, the proposition I might've made would've reduced to approximately this: "I know you're facing bankruptcy because your athletes have grown frustrated with poor response and taken their registration fees to better-managed events," I might say, "but how about paying us fifteen grand to build you a completely new website from the ground up? It'll work great!" Perhaps you can conceive of a world in which such a suggestion would go over well. If so, I applaud the floridity and scope of your imagination, which must be truly unparalleled. Here in reality, we must cope as best we can with the situations in which we find ourselves. Oftentimes, that means finding some way in which the client can do part of the work -- specifically, as in the case I describe, that part which is intimately bound up with the particular user's unique experience, and whose result therefore doesn't generalize no matter where it's handled. Lest we lose track of the topic, the "static site generator" under discussion is, I grant, a very poor example of my thesis, because the work it pushes off to the client could very well be done on the server, or indeed could be done once as a compilation step and the result served statically to all comers -- it's a cute toy, but nothing I'd ever expect to see anywhere near production. But, as I said before, to attempt to generalize, from this toy project, to every case in which some work is offloaded to the client, redoles most strongly of arrogance, ignorance, and foolishness. I mean, I can appreciate that, when your major professional concern at the moment is apparently a website dedicated to giving stoners an idea of which strain of cannabis provides the best high, you probably don't have to worry much about scaling and offloading, and that's fantastic! But some of us find ourselves forced by circumstance to operate in a less utterly trivial sphere.