4 ms·

yeah... i was not at all prepared for this many people to visit this article

by dwltz 12y ago

SigmundA 12y ago
The irony is that had you used javascript to render the page taking advantage of everyone's CPU you may have lightened the load on your server. History seems to repeat itself. First there where dumb terminals where the mainframe did all the work. Then the age of the PC with heavy clients. Then the age of dumb browsers where the server did all the work again. Now the age of heavy browsers running javacsript. The thing is, you have a capable programming language able to utilize distributed CPU resources in a safe manner, why would you not want to take advantage of it? Because a dumb spider can't crawl it? Simple fact is this is happening because it's obvious and it would be like fighting the rising tide to deny it, IMO.
- slifin 12y ago
  Would the performance difference between the server sending javascript with the logic for rendering vs the server just rendering be so significant as to have saved his website from a hacker news hug?
  - tinco 12y ago
    It depends on the exact style but yes. He could have the majority of his page statically served or cached, and then load the dynamic parts (the comments most likely) in with JavaScript. At least the article then would be readable even if the comments didn't load.
    - vinceguidry 12y ago
      No, that can still bork your server. Too many async requests will kill it just like too many page loads, only now you've got each client going back and forth to the server. The real way to do comments is the same way we've been doing it for years. Post to a form, load the new ones with a new page load. Better yet, push that functionality off to a system designed to handle it, i.e. HN.
  - drinchev 12y ago
    The best performance benefit will come if the whole page is pre-generated with something like jekyll [1] or assemble [2]. There is even a grunt module that uploads the generated site to S3, which is HN-traffic proof. Of course if you need some dynamic content I also prefer not depending on javascript, which will allow proper bots crawling. I would comment more if I can read the article, though. [1] http://jekyllrb.com/ http://jekyllrb.com/ [2] http://assemble.io/ http://assemble.io/
  - SigmundA 12y ago
    Maybe, maybe not, I can't tell how dynamic the site is since it's down. Something has to render the content, as with most programs everything is a CPU vs Memory vs IO/Network trade off. It's nice to now have the option to use the CPU of the client if desired. I started programming in the heavy client days, writing VB6 against Access databases or SQL server. This is how your typical business app was made and it completely consumed the mainframe/terminal model because you could scale on commodity hardware taking heavy advantage of the now relatively powerful distributed client resources. The server did as little as possible to get the data to the client for rendering/presentation also you could do offline partially connected things. Of course there where issues with this model, deployment was much harder and you had to trust the clients, plus databases generally didn't scale out at the time. Then browsers came about, and everyone realized you could write business apps in them, but the old guys laughed at us because it was the dumb terminal model all over again. All validation done on the server, no deployment issues, no need to trust the client, network connection always required. Then javascript started getting better, hey I can do validation in the client again, but maybe do on the server still if you don't trust the client, but the user gets instant feedback, best of both worlds. The choice about which layer your code executes in is important, it lets you make that CPU vs Memory vs IO trade off without leaving the client CPU on the table. I think this is one reason the mobile app model is so popular as well.
- madaxe_again 12y ago
  I've often thought the same bit re: history repeating itself - we've seen tech slosh back and forth, wave-like, as you describe - I wonder if perhaps the end game is that there's no distinction between client and server, and we end up with a totally homogenous compute environment.
  - SigmundA 12y ago
    Not sure if we will ever hit end game, there definitely seems to be some more sloshes left, just look at mobile apps, in many way closer to the old heavy client PC days than web apps. Why? Offline is not there on the web, everyone likes to think there is a great network connection everywhere, mobile networks have obviously brought that closer to reality, but nowhere near complete. Taking advantage of the client hardware completely as well for better user experience. Deployment has been pretty much solved by app stores, but still involves a big initial code download before the user can see your app vs a web site yet here we are complaining a javascript heavy site takes a little longer to initially load. I think it will tend toward a homogenous compute environment, you can almost get a feel for it with javascript, node and say postgresql with plv8. Now your code runs anywhere in the stack you please, it's nice even if js ins't the best, but what is?
- vinceguidry 12y ago
  > The irony is that had you used javascript to render the page taking advantage of everyone's CPU you may have lightened the load on your server. No, he just didn't take his philosophy far enough. The real way to do this is to make your pages static and serve them from a caching proxy. If you don't need dynamism then you shouldn't use it at all on production. Without seeing his server and his backend code it's hard to make specific recommendations, but a single server with an nginx front-end can handle a lot of load. I've seen Wordpress handle a full-on Slashdotting without even breaking a sweat.
  - SigmundA 12y ago
    Works fine if it's relatively static content, which this site probably is. I come from an busniess app development background so maybe I see everything through that lens, but when you need dynamism why would you not want to take advantage of your visitors CPU? Is the web just supposed to be a bunch of static documents?
    - vinceguidry 12y ago
      The real issue is the number of connections. Sure, if you are doing something like an animation, it would be stupid to do it server-side, unless you can use an animated gif or another way to make it static. But if you are loading a page, then having that page go back and forth to the server to retrieve more data, then that will kill your site as soon as it hits HN. Because each client is making a ton of connections and it just compounds. You've essentially DOSed yourself.
      - SigmundA 12y ago
        The point is shortening the connection time and CPU resources on the server by only serializing the data needed. This means less concurrent connections allowing more visitors. If you visited the site before, maybe the javscript rendering engine is already cached, all you need is the latest data not the layout. Again maybe this isn't the best choice for a static site, but there is a continuum of sites from static to completely dynamic web apps. It's nice now that the developer has the choice to involve the clients resources at the point in that continuum of their choosing rather than it being off limits.
- deleted 12y ago
  [deleted]
  - SigmundA 12y ago
    Never underestimate the CPU power of 1000's of mobile devices running a high level, yet highly optimized, Turing complete language. So you don't trust the client and still need to do validation on the server, fine at least you can avoid sending invalid requests to the server and give the user instant feedback. So you want to render a partial change to your page, have the server render a bunch of HTML from a database, or serialize the data minimally and have the client render the HTML. What about rendering visualizations of your data, chart, graphs etc, server rendering and sending jpegs, or client using canvas/svg? Nice to have that choice.

yeah... i was not at all prepared for this many people to visit this article

by dwltz 12y ago

yeah... i was not at all prepared for this many people to visit this article

The irony is that had you used javascript to render the page taking advantage of everyone's CPU you may have lightened the load on your server. History seems to repeat itself. First there where dumb terminals where the mainframe did all the work. Then the age of the PC with heavy clients. Then the age of dumb browsers where the server did all the work again. Now the age of heavy browsers running javacsript. The thing is, you have a capable programming language able to utilize distributed CPU resources in a safe manner, why would you not want to take advantage of it? Because a dumb spider can't crawl it? Simple fact is this is happening because it's obvious and it would be like fighting the rising tide to deny it, IMO.

slifin 12y ago
Would the performance difference between the server sending javascript with the logic for rendering vs the server just rendering be so significant as to have saved his website from a hacker news hug?
- tinco 12y ago
  It depends on the exact style but yes. He could have the majority of his page statically served or cached, and then load the dynamic parts (the comments most likely) in with JavaScript. At least the article then would be readable even if the comments didn't load.
  - vinceguidry 12y ago
    No, that can still bork your server. Too many async requests will kill it just like too many page loads, only now you've got each client going back and forth to the server. The real way to do comments is the same way we've been doing it for years. Post to a form, load the new ones with a new page load. Better yet, push that functionality off to a system designed to handle it, i.e. HN.
- drinchev 12y ago
  The best performance benefit will come if the whole page is pre-generated with something like jekyll [1] or assemble [2]. There is even a grunt module that uploads the generated site to S3, which is HN-traffic proof. Of course if you need some dynamic content I also prefer not depending on javascript, which will allow proper bots crawling. I would comment more if I can read the article, though. [1] http://jekyllrb.com/ http://jekyllrb.com/ [2] http://assemble.io/ http://assemble.io/
- SigmundA 12y ago
  Maybe, maybe not, I can't tell how dynamic the site is since it's down. Something has to render the content, as with most programs everything is a CPU vs Memory vs IO/Network trade off. It's nice to now have the option to use the CPU of the client if desired. I started programming in the heavy client days, writing VB6 against Access databases or SQL server. This is how your typical business app was made and it completely consumed the mainframe/terminal model because you could scale on commodity hardware taking heavy advantage of the now relatively powerful distributed client resources. The server did as little as possible to get the data to the client for rendering/presentation also you could do offline partially connected things. Of course there where issues with this model, deployment was much harder and you had to trust the clients, plus databases generally didn't scale out at the time. Then browsers came about, and everyone realized you could write business apps in them, but the old guys laughed at us because it was the dumb terminal model all over again. All validation done on the server, no deployment issues, no need to trust the client, network connection always required. Then javascript started getting better, hey I can do validation in the client again, but maybe do on the server still if you don't trust the client, but the user gets instant feedback, best of both worlds. The choice about which layer your code executes in is important, it lets you make that CPU vs Memory vs IO trade off without leaving the client CPU on the table. I think this is one reason the mobile app model is so popular as well.
madaxe_again 12y ago
I've often thought the same bit re: history repeating itself - we've seen tech slosh back and forth, wave-like, as you describe - I wonder if perhaps the end game is that there's no distinction between client and server, and we end up with a totally homogenous compute environment.
- SigmundA 12y ago
  Not sure if we will ever hit end game, there definitely seems to be some more sloshes left, just look at mobile apps, in many way closer to the old heavy client PC days than web apps. Why? Offline is not there on the web, everyone likes to think there is a great network connection everywhere, mobile networks have obviously brought that closer to reality, but nowhere near complete. Taking advantage of the client hardware completely as well for better user experience. Deployment has been pretty much solved by app stores, but still involves a big initial code download before the user can see your app vs a web site yet here we are complaining a javascript heavy site takes a little longer to initially load. I think it will tend toward a homogenous compute environment, you can almost get a feel for it with javascript, node and say postgresql with plv8. Now your code runs anywhere in the stack you please, it's nice even if js ins't the best, but what is?
vinceguidry 12y ago
> The irony is that had you used javascript to render the page taking advantage of everyone's CPU you may have lightened the load on your server. No, he just didn't take his philosophy far enough. The real way to do this is to make your pages static and serve them from a caching proxy. If you don't need dynamism then you shouldn't use it at all on production. Without seeing his server and his backend code it's hard to make specific recommendations, but a single server with an nginx front-end can handle a lot of load. I've seen Wordpress handle a full-on Slashdotting without even breaking a sweat.
- SigmundA 12y ago
  Works fine if it's relatively static content, which this site probably is. I come from an busniess app development background so maybe I see everything through that lens, but when you need dynamism why would you not want to take advantage of your visitors CPU? Is the web just supposed to be a bunch of static documents?
  - vinceguidry 12y ago
    The real issue is the number of connections. Sure, if you are doing something like an animation, it would be stupid to do it server-side, unless you can use an animated gif or another way to make it static. But if you are loading a page, then having that page go back and forth to the server to retrieve more data, then that will kill your site as soon as it hits HN. Because each client is making a ton of connections and it just compounds. You've essentially DOSed yourself.
    - SigmundA 12y ago
      The point is shortening the connection time and CPU resources on the server by only serializing the data needed. This means less concurrent connections allowing more visitors. If you visited the site before, maybe the javscript rendering engine is already cached, all you need is the latest data not the layout. Again maybe this isn't the best choice for a static site, but there is a continuum of sites from static to completely dynamic web apps. It's nice now that the developer has the choice to involve the clients resources at the point in that continuum of their choosing rather than it being off limits.
deleted 12y ago
[deleted]
- SigmundA 12y ago
  Never underestimate the CPU power of 1000's of mobile devices running a high level, yet highly optimized, Turing complete language. So you don't trust the client and still need to do validation on the server, fine at least you can avoid sending invalid requests to the server and give the user instant feedback. So you want to render a partial change to your page, have the server render a bunch of HTML from a database, or serialize the data minimally and have the client render the HTML. What about rendering visualizations of your data, chart, graphs etc, server rendering and sending jpegs, or client using canvas/svg? Nice to have that choice.