3 ms·

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

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.

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.