3 ms·

GWT is quite close, it allows both client & server to be written in Java which is then compiled to Javascript. A lot of the criticism of SPAs here doesn't reall

GWT is quite close, it allows both client & server to be written in Java which is then compiled to Javascript. A lot of the criticism of SPAs here doesn't really apply to it, as all your css / javascript files, and even most of the images, are compiled into one html file, and only that file is loaded at page load. That reduces the number of http requests, and with gzipping and caching, your page loads up quite quickly. All of the other things, including history management / back button, are built into GWT.

neolefty 12y ago
By principle 1, "Server rendered pages are not optional", I think GWT is missing a big piece: it doesn't let you choose between server-side & client-side rendering -- instead it's designed to make client-side rendering easy. Yes, GWT can be quick, but it still has to make those extra round trips to get data from the server. If it had an option to render the initial page wholesale on the server, it could get that first impression up faster. In order to add that to GWT, you'd have to emulate the first few rounds of communication on the server --- incorporate a server-side DOM model & fake communication layer, either using the cross-compiled JS or Java. Maybe leverage the debugging tools?
- aliakhtar 12y ago
  Actually, with GWT you don't have to load your whole app on page load. You can divide your code, and only load the code needed to display a loading / splash page, on initial load. This way, there's only about ~100KB of code loaded initially, which brings up a splash screen very quickly, and then the next batch of code is fetched and displayed. Also all of these files are cached once loaded, so they don't have to be loaded again until they are changed.
  - xtrumanx 12y ago
    A splash/loading page is a workaround to avoid the user seeing a blank/unusable page while your app loads. The goal of server-side rendering is to show the user everything he supposed to see when a typical single-page-app loads, shows the a splash page, fetches the initial data and renders it on the page. From your description, GWT does not offer that.
    - aliakhtar 12y ago
      Fair enough, but if you render the page on server, you will likely have to do some processing (e.g database/api calls) in order to get the data to display to them. The screen will be blank while all of this is going on. If you go the splash / loading page route, users will immediately see the loading screen come up. Plus, with the 'render on server' route, if users visit any other page, they will have to wait for a full page reload, whereas with an SAP, they will just see a loading icon for a second or three before the new page will come up. Its a lot more responsive overall, and the pros outweigh the cons in my experience.
      - neolefty 12y ago
        The article is advocating for a framework that does both -- it renders the initial impression on the server (yes, including a few DB reads), snapshots it as an SPA, sends it to the browser, and then lets the user continue the interaction that began on the server. It adds significant server complexity for what some would call a minimal improvement in setup time. The article is advocating it for exactly that: overcoming that (maybe minimal) setup time on the client, which includes a one or more server round trips. In many cases, this will undoubtedly be premature optimization. But if the framework made it easy, then it might simplify your transaction model. You could unbundle transactions, knowing that you aren't paying a latency tax on them, at least on startup, since it's all happening on the server.
        aliakhtar 12y ago
        I would rather have something show up for the user immediately, than have him see a blank screen while DB calls are going on at server. But, to each their own.
    - heliodor 12y ago
      My perception of how fast a page loads is that if you show me an 'app loading...' splash screen, it makes me feel your page is slow and bloated. I react better to a blank screen with the browser's progress bar moving. I suppose it's because it allows me to shift blame away from your webpage to the quality of my internet connection.
- cromwellian 12y ago
  GWT UiBinder doesn't permit server-side rendering, but other templating systems do (Google Flights for example uses GWTSOY, Google Inbox uses something we call JsLayout) GWT has always supported minimizing the number of HTTP requests. For example, GWT RPC long supported pre-serializing the first couple of requests into the initial HTML, so that you don't need to do an AJAX request before you can render. It's also one of the first, if not the first, framework to support automatic asset packaging, sprite-sheeting, etc (since 2009). This inlines all CSS, small images, and other resources into a single chunk, which can be downloaded in one HTTP request. I am working on an architecture I call POA, Page Oriented Architecture, which combines the best of Web Components, React-JS style binding, and server-side rendering into a single framework for GWT. Google already uses "patching" to deliver small pieces of JS, we call DeltaJS. So when you visit inbox.google.com, the server computes the diff between what you have in local storage, and what has been recently pushed, and sends down a patch that updates your cached copied. I'm looking at combining this with ServiceWorkers for GWT so that all GWT apps by default can leverage offline and delta-js application. Hopefully I'll have something to show by the GWT.create conference (gwtcreate.com), we'll see.
  - aliakhtar 12y ago
    > Google already uses "patching" to deliver small pieces of JS, we call DeltaJS. So when you visit inbox.google.com, the server computes the diff between what you have in local storage, and what has been recently pushed, and sends down a patch that updates your cached copied. Does that mean that if a user has an app cached, but something changes within only a single split point in that app, then the user only has to re-download that split point, vs re-downloading the whole app again?
    - cromwellian 12y ago
      I'm not sure how that'll work yet. I don't maintain the DeltaJS infrastructure, I use just it, and as of now, Google Inbox doesn't use code splitting, however that is the focus of post-launch activities, reducing code size download, making startup faster, etc.
  - stephen 12y ago
- uaygsfdbzf 12y ago
  GWTP provides a feature to support SEO. Not sure how it works. I think it saves the pages rendered by a browser's emulator. It could be reused for this purpose. https://github.com/ArcBees/GWTP/wiki/Crawler-Support https://github.com/ArcBees/GWTP/wiki/Crawler-Support

neolefty 12y ago

By principle 1, "Server rendered pages are not optional", I think GWT is missing a big piece: it doesn't let you choose between server-side & client-side rendering -- instead it's designed to make client-side rendering easy. Yes, GWT can be quick, but it still has to make those extra round trips to get data from the server. If it had an option to render the initial page wholesale on the server, it could get that first impression up faster. In order to add that to GWT, you'd have to emulate the first few rounds of communication on the server --- incorporate a server-side DOM model & fake communication layer, either using the cross-compiled JS or Java. Maybe leverage the debugging tools?

aliakhtar 12y ago
Actually, with GWT you don't have to load your whole app on page load. You can divide your code, and only load the code needed to display a loading / splash page, on initial load. This way, there's only about ~100KB of code loaded initially, which brings up a splash screen very quickly, and then the next batch of code is fetched and displayed. Also all of these files are cached once loaded, so they don't have to be loaded again until they are changed.
- xtrumanx 12y ago
  A splash/loading page is a workaround to avoid the user seeing a blank/unusable page while your app loads. The goal of server-side rendering is to show the user everything he supposed to see when a typical single-page-app loads, shows the a splash page, fetches the initial data and renders it on the page. From your description, GWT does not offer that.
  - aliakhtar 12y ago
    Fair enough, but if you render the page on server, you will likely have to do some processing (e.g database/api calls) in order to get the data to display to them. The screen will be blank while all of this is going on. If you go the splash / loading page route, users will immediately see the loading screen come up. Plus, with the 'render on server' route, if users visit any other page, they will have to wait for a full page reload, whereas with an SAP, they will just see a loading icon for a second or three before the new page will come up. Its a lot more responsive overall, and the pros outweigh the cons in my experience.
    - neolefty 12y ago
      The article is advocating for a framework that does both -- it renders the initial impression on the server (yes, including a few DB reads), snapshots it as an SPA, sends it to the browser, and then lets the user continue the interaction that began on the server. It adds significant server complexity for what some would call a minimal improvement in setup time. The article is advocating it for exactly that: overcoming that (maybe minimal) setup time on the client, which includes a one or more server round trips. In many cases, this will undoubtedly be premature optimization. But if the framework made it easy, then it might simplify your transaction model. You could unbundle transactions, knowing that you aren't paying a latency tax on them, at least on startup, since it's all happening on the server.
      - aliakhtar 12y ago
        I would rather have something show up for the user immediately, than have him see a blank screen while DB calls are going on at server. But, to each their own.
  - heliodor 12y ago
    My perception of how fast a page loads is that if you show me an 'app loading...' splash screen, it makes me feel your page is slow and bloated. I react better to a blank screen with the browser's progress bar moving. I suppose it's because it allows me to shift blame away from your webpage to the quality of my internet connection.
cromwellian 12y ago
GWT UiBinder doesn't permit server-side rendering, but other templating systems do (Google Flights for example uses GWTSOY, Google Inbox uses something we call JsLayout) GWT has always supported minimizing the number of HTTP requests. For example, GWT RPC long supported pre-serializing the first couple of requests into the initial HTML, so that you don't need to do an AJAX request before you can render. It's also one of the first, if not the first, framework to support automatic asset packaging, sprite-sheeting, etc (since 2009). This inlines all CSS, small images, and other resources into a single chunk, which can be downloaded in one HTTP request. I am working on an architecture I call POA, Page Oriented Architecture, which combines the best of Web Components, React-JS style binding, and server-side rendering into a single framework for GWT. Google already uses "patching" to deliver small pieces of JS, we call DeltaJS. So when you visit inbox.google.com, the server computes the diff between what you have in local storage, and what has been recently pushed, and sends down a patch that updates your cached copied. I'm looking at combining this with ServiceWorkers for GWT so that all GWT apps by default can leverage offline and delta-js application. Hopefully I'll have something to show by the GWT.create conference (gwtcreate.com), we'll see.
- aliakhtar 12y ago
  > Google already uses "patching" to deliver small pieces of JS, we call DeltaJS. So when you visit inbox.google.com, the server computes the diff between what you have in local storage, and what has been recently pushed, and sends down a patch that updates your cached copied. Does that mean that if a user has an app cached, but something changes within only a single split point in that app, then the user only has to re-download that split point, vs re-downloading the whole app again?
  - cromwellian 12y ago
    I'm not sure how that'll work yet. I don't maintain the DeltaJS infrastructure, I use just it, and as of now, Google Inbox doesn't use code splitting, however that is the focus of post-launch activities, reducing code size download, making startup faster, etc.
- stephen 12y ago
uaygsfdbzf 12y ago
GWTP provides a feature to support SEO. Not sure how it works. I think it saves the pages rendered by a browser's emulator. It could be reused for this purpose. https://github.com/ArcBees/GWTP/wiki/Crawler-Support https://github.com/ArcBees/GWTP/wiki/Crawler-Support