3 ms·

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

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.

falcolas 12y ago
I think you overestimate the resources required to render a page. The act of filling a cached template on the server with variables doesn't take much longer than the act of serializing the same data into JSON.
- SigmundA 12y ago
  Of course I think you underestimate the resources and bandwidth required to render and send html. After all what is the purpose of http compression? Decreasing network resources and lower load time by increasing CPU load on server and client. Doing javascript rendering on the client is basically a form of application specific compression that can actually require less server CPU rather than more while increasing client CPU as a trade off. I agree JSON isn't always a big win compared to HTML, but it is lighter and typically contains only data rather than layout metadata, making it even lighter, along with doing partial update etc. Going back to the old 2-tier client server days the database protocols such as SQL server TDS where binary extremely compact and efficient to parse requiring as little overhead as possible on the server to render and as little network overhead as possible. You are starting to see a resurgence of these ideas with bson, msgpack, protobuff etc. If you pair client side rendering with say msgpack you get even bigger wins in network overhead and server CPU time for parse and serialize.
  - vinceguidry 12y ago
    You guys are arguing on a forum about something that's easy to go out and test. Make some test servers, run some benchmarks. Find out for yourself. Then make a post about it using what you learned and submit it to HN. I hope it doesn't crash under the load.
    - SigmundA 12y ago
      This is an odd response, your posts where arguing for a certain approach while not running test and benchmarks to post results for. As I said there are a continuum of web sites from static text to dynamic and graphical. Benchmarks could be made at any point in the continuum to validate a specific approach. My "argument" is simply that it is a good thing we can choose the approach rather than being limited to a server side model only. In many instances it can be more efficient allowing less server resources for a given load and lead to a better and richer user experience.
  - falcolas 12y ago
    Most of these messaging protocols will still benefit from compression, since the payload will typically be text of some sort. The benefit of compression is that if you send a value once, sending it again in the same document is nearly free. This makes rendered HTML very inexpensive to send over the wire once compressed - there aren't that many HTML tags. Plus, compression is quite inexpensive when compared to the overhead incurred by SSL. > but it is lighter and typically contains only data rather than layout metadata That layout metadata is still being sent to the client, only in the case of client side rendering it's sent in the form of JMX, or the initial HTML page, or... The only difference lies in the ability of the client to cache the layout (which works as well in a hybrid model). > If you pair client side rendering with say msgpack you get even bigger wins in network overhead and server CPU time for parse and serialize. This comparison (done by someone else) makes me think that this requires a bit more research before blindly following this advice. http://pastebin.com/3gyWHeh9 http://pastebin.com/3gyWHeh9
    - SigmundA 12y ago
      Can you give some context to your benchmarks because it looks like it's comparing messagepack to json in javascript which is one of the few places it would be slower than json. Since the json parser is implemented native vs message pack being implemented in js. Every benchmark I have seen in other languages where json and messagepack parser are on equal footing shows messagepack being faster and lighter. For instance on Ruby where Oj is tops in JSON, Messagepack is still faster: http://relistan.com/messagepack-vs-json-in-ruby/ http://relistan.com/messagepack-vs-json-in-ruby/ Again on the server messagepack should be faster and use less CPU and require less bandwidth than json, the client will require more CPU but you have many more client CPUs than server CPUs. Compression layered over text isn't free in any context, the closest it comes is pre-compressed static content, which would be great for the layout HTML,JMX and js files. Binary serializers like messagepack give you some space saving while also saving server CPU cycles rather than trading one for the other.

falcolas 12y ago

I think you overestimate the resources required to render a page. The act of filling a cached template on the server with variables doesn't take much longer than the act of serializing the same data into JSON.

SigmundA 12y ago
Of course I think you underestimate the resources and bandwidth required to render and send html. After all what is the purpose of http compression? Decreasing network resources and lower load time by increasing CPU load on server and client. Doing javascript rendering on the client is basically a form of application specific compression that can actually require less server CPU rather than more while increasing client CPU as a trade off. I agree JSON isn't always a big win compared to HTML, but it is lighter and typically contains only data rather than layout metadata, making it even lighter, along with doing partial update etc. Going back to the old 2-tier client server days the database protocols such as SQL server TDS where binary extremely compact and efficient to parse requiring as little overhead as possible on the server to render and as little network overhead as possible. You are starting to see a resurgence of these ideas with bson, msgpack, protobuff etc. If you pair client side rendering with say msgpack you get even bigger wins in network overhead and server CPU time for parse and serialize.
- vinceguidry 12y ago
  You guys are arguing on a forum about something that's easy to go out and test. Make some test servers, run some benchmarks. Find out for yourself. Then make a post about it using what you learned and submit it to HN. I hope it doesn't crash under the load.
  - SigmundA 12y ago
    This is an odd response, your posts where arguing for a certain approach while not running test and benchmarks to post results for. As I said there are a continuum of web sites from static text to dynamic and graphical. Benchmarks could be made at any point in the continuum to validate a specific approach. My "argument" is simply that it is a good thing we can choose the approach rather than being limited to a server side model only. In many instances it can be more efficient allowing less server resources for a given load and lead to a better and richer user experience.
- falcolas 12y ago
  Most of these messaging protocols will still benefit from compression, since the payload will typically be text of some sort. The benefit of compression is that if you send a value once, sending it again in the same document is nearly free. This makes rendered HTML very inexpensive to send over the wire once compressed - there aren't that many HTML tags. Plus, compression is quite inexpensive when compared to the overhead incurred by SSL. > but it is lighter and typically contains only data rather than layout metadata That layout metadata is still being sent to the client, only in the case of client side rendering it's sent in the form of JMX, or the initial HTML page, or... The only difference lies in the ability of the client to cache the layout (which works as well in a hybrid model). > If you pair client side rendering with say msgpack you get even bigger wins in network overhead and server CPU time for parse and serialize. This comparison (done by someone else) makes me think that this requires a bit more research before blindly following this advice. http://pastebin.com/3gyWHeh9 http://pastebin.com/3gyWHeh9
  - SigmundA 12y ago
    Can you give some context to your benchmarks because it looks like it's comparing messagepack to json in javascript which is one of the few places it would be slower than json. Since the json parser is implemented native vs message pack being implemented in js. Every benchmark I have seen in other languages where json and messagepack parser are on equal footing shows messagepack being faster and lighter. For instance on Ruby where Oj is tops in JSON, Messagepack is still faster: http://relistan.com/messagepack-vs-json-in-ruby/ http://relistan.com/messagepack-vs-json-in-ruby/ Again on the server messagepack should be faster and use less CPU and require less bandwidth than json, the client will require more CPU but you have many more client CPUs than server CPUs. Compression layered over text isn't free in any context, the closest it comes is pre-compressed static content, which would be great for the layout HTML,JMX and js files. Binary serializers like messagepack give you some space saving while also saving server CPU cycles rather than trading one for the other.