4 ms·

> Server rendered pages are not optional > Consider the additional roundtrips to get scripts, styles, and subsequent API requests If you're using a framework

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

derengel 12y ago
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.
- aliakhtar 12y ago
  https://news.ycombinator.com/item?id=8554339 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.
- paulirish 12y ago
  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 http://gwtcreate.com)
sanderjd 12y ago
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.
- aliakhtar 12y ago
  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.
  - sanderjd 12y ago
    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.
    - cbsmith 12y ago
      > 100 requests was purposefully hyperbolic. Have you checked out your average content web site?
      - sanderjd 12y ago
        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.
        cbsmith 12y ago
        Actually the ad stuff would largely go away if everything moved server side.
        sanderjd 12y ago
        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.
cbsmith 12y ago
Are you suggesting that we now need a sophisticated framework in order to concatenate files together?
- aliakhtar 12y ago
  It does a lot more than just concatenate them: http://www.gwtproject.org/learnmore-sdk.html http://www.gwtproject.org/learnmore-sdk.html
  - cbsmith 12y ago
    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.
    - deleted 12y ago
      [deleted]
nekitamo 12y ago
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?
- aliakhtar 12y ago
  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.
megaman821 12y ago
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.
- spankalee 12y ago
  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.
- aliakhtar 12y ago
  > 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.

derengel 12y ago

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.

aliakhtar 12y ago
https://news.ycombinator.com/item?id=8554339 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.
paulirish 12y ago
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 http://gwtcreate.com)

sanderjd 12y ago

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.

aliakhtar 12y ago
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.
- sanderjd 12y ago
  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.
  - cbsmith 12y ago
    > 100 requests was purposefully hyperbolic. Have you checked out your average content web site?
    - sanderjd 12y ago
      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.
      - cbsmith 12y ago
        Actually the ad stuff would largely go away if everything moved server side.
        sanderjd 12y ago
        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.

cbsmith 12y ago

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

aliakhtar 12y ago
It does a lot more than just concatenate them: http://www.gwtproject.org/learnmore-sdk.html http://www.gwtproject.org/learnmore-sdk.html
- cbsmith 12y ago
  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.
  - deleted 12y ago
    [deleted]

nekitamo 12y ago

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?

aliakhtar 12y ago
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.

megaman821 12y ago

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.

spankalee 12y ago
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.
aliakhtar 12y ago
> 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.