3 ms·

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 s

by 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.

by 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.