Hacker News Reader

Comment by matt_oriordan | Hacker News Reader

Looks like you shouldn't depend on a server or TCP/IP either to render a page given the website is down ;)

http://www.downforeveryoneorjustme.com/http://blog.donnywals...

Please don't use inline CSS in your page. In order to read the cached version [1] I had to manually remove the sidebar because it overlayed the main content with inline 'position: fixed'.

[1] http://webcache.googleusercontent.com/search?q=cache:9UMu5i7...

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.

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?

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.

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.

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/ [2] http://assemble.io/

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.

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.

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?

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

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?

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.

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.

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.

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.

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.

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.

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

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/

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.

The question boils down to how much dynamism does your site really need? If it's a web application, then by all means use Javascript all you need to.

A blog, corporate landing page, forum... none of these are really that dynamic. Or where they are dynamic, they could be first served as static, letting Javascript take over once it's all been loaded.

At the very least, the initial data required by JS should be loaded with the rest of the page, letting JS start rendering the page immediately, instead of after another network round trip.

Reply on news.ycombinator.com