Hacker News Reader

Comment by aliakhtar | Hacker News Reader

> Server rendered pages are not optional

> Consider the additional roundtrips to get scripts, styles, and subsequent API requests

If you're using a framework like GWT, it compiles all of the relavant css files, javascript, and ui template files, into one .html file. Then there's only one or two http requests to download this html file, and the server only has to handle requests for fetching data, updating or adding stuff, etc. You can also gzip + cache this .html file, to make it even smaller.

It runs lightning fast, too.

View on HN

Another problem I had with that point is that there is no theoretical floor to the number of requests that can be made in parallel. If it takes 100 requests to get all your data, and the browser can handle 100 requests in parallel, you can get all your data with that same theoretical 50ms latency floor. This is a pedantic point, because as far as I know, all browsers currently limit parallel requests to a fairly low number, but it isn't true that more requests requires more wall-time latency in a theoretical sense.

Often on mobile phone browsers and such, the number of parallel requests is much lower. That's where something like GWT can help a lot, as it can cut your 100 requests down to just 2.

100 requests was purposefully hyperbolic. In reality, everything I've done recently has been 3 static requests (html, js, css), and however many requests for images and data are necessary. It's really just the requests for data (which I don't think GWT helps with?) that end up being "extra", because server-side rendering still usually requires separate requests for js, css, and images.

> 100 requests was purposefully hyperbolic.

Have you checked out your average content web site?

Very fair point, but I was sort of not considering images. Although it's probably still a fair point, but so much of the rest is third-party ad junk, which isn't really affected by the server-side vs. client-side rendering question.

Actually the ad stuff would largely go away if everything moved server side.

How so? You mean by having the server send the user's info to the ad provider? That doesn't seem to be a common setup, because of the advantages of cookies for tracking users across sites. Maybe I'm missing something though.

When it is done server side, any tracking cookie work has to be done ahead of time. So you have a single trip from the browser to get the ad, and maybe a second trip to confirm it was successfully shown. That's it.

Ah, but that won't work for the requests to third-party services that are for the purpose of telling those services "the user identified by the cookie in this request just visited this site" rather than actually showing ads, will it?

Absolutely it will (if that's what they want it to do). As I said, you've already done the cookie join, so you know what the magic userid is that the third party has in their system for that user.

FYI, most of your images are also compiled into that single .html file I mentioned. This includes both the images used in css files, and the ones in <img /> tags. That means only one http request for loading your css, js, and most of your images.

That's really intriguing. Not sure I've seen anybody else do it that way. Thanks for enlightening me!

No problem. Just to clarify, only the small / medium sized images are inlined in this way. The large images are done as their own http request, so the browser doesn't slow down with rendering them.

This isn't as awesome as it sounds. When inlining everything there is no control over the prioritization of resources. Large files like images can block the rendering of your layout giving the appearance of being slow even if the overall download time is less. HTTP2 has stream prioritization to solve this problem and is much more cache friendly.

If I recall, only very small images are inlined as data URLs, and other are either sprited or left alone. There's a lot of control over these optimizations.

> When inlining everything there is no control over the prioritization of resources.

You can use split points to divide up your code, only the resources in a given split point are loaded. Example: If the user is viewing your 'Sign up' page, then only the resources for the 'Sign up' page will be loaded.

> Large files like images can block the rendering of your layout

Only small to medium files are inlined. Large files are downloaded as usual.

This might sound good on paper, but have you actually tried using a large GWT application daily? I use Google Adwords every day, and it's one slowest and most frustrating web experiences ever. And if Google can't get a GWT application right, who's to say you can?

I've been developing GWT apps for over a year, and without any doubt, they are the fastest running apps I've built compared to everything I've built using regular javascript / AngularJS. My clients have also used terms like 'insanely fast', 'runs like native' (on mobile), etc referring to sites done in GWT.

I've used adwords a little bit, and it runs fine for me. The only slowness I can think of is when you request keyword / bid data and it fetches it from the server. That takes a while. But for that, it probably has to query a gigantic dataset on the server, and that's probably the reason for the slowness.

You can contrast that with Angry Birds' html5 version, which was also written with GWT.

But Google is not pushing GWT anymore since a long time, they don't want more adoption of the framework, instead, they want you to start using Dart, so beware of GWT's future.

https://news.ycombinator.com/item?id=8554339

Also, GWT has been open source since 2-3 years ago, and its development has been steadily going on. Even if Google was to abandon GWT, it would continue on being used & developed by others.

Google isn't pushing GWT sure, but it does have a dedicated GWT team and also just launched a brand-new product based on GWT. More to the point, based on the acceleration of the GWT community, it honestly doesn't matter how Google Proper cares about it. It's a stable and growing platform (e.g. http://gwtcreate.com)

Are you suggesting that we now need a sophisticated framework in order to concatenate files together?

It does a lot more than just concatenate them: http://www.gwtproject.org/learnmore-sdk.html

I didn't call it a sophisticated framework for nothing. Of course it does a lot more than that.

Point is, it is ridiculous suffering from client side rendering latency penalties due to an absurd number of round trips loading all these different components. Concatenation is NOT a hard concept folks. Even if you aren't using GWT there is no excuse for letting this drive the problem.

Reply on news.ycombinator.com