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.
The "jstcache" attribute looks the same. Although, looking at the code.google.com project's source, it doesn't look like any code/non-wiki changes since ~2008. So maybe a forgotten attempt at open sourcing the/precursor-to JsLayout?
POA sounds interesting; hopefully it'll have a great unit testing story too?
Yeah, that looks like an early version of it, I'll ask why we aren't developing it in the open anymore (it may have been because of rapid changes need by Inbox)
The central idea of Page Oriented Architecture is to return to the Web 1.0 era of "A URL for everything", where the application consists of a bunch of pages, and if desired, any page can be rendered server-side.
However, what really happens beside the scenes is GWT processes all the pages for the whole site, synthesizes an application, which each page between a GWT "splitpoint". So you have your cake and eat it too. An application that is developed a 'page at a time' with crawlable, indexable, server-side URLs for everything, while at the same time, you get a monolithically compiled, globally optimized, Single-Page-Application out of it.
However, that's since been super-ceded by a system I'm working on that makes everything look like Polymer, only it's monolithically compiled and optimized, and using ReactJS style virtual DOM-diffing.
I want to combine this with DeltaJS techniques and ServiceWorker to produce offline-by-default high performance mobile web apps out of the box.
> 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?
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.
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.