Is there any web application framework, presumably encompassing both client-side and server-side code, that implements these principles? I'm guessing that Meteor comes closest.
It is really different and extreme -- in a good way. It supports both server side or client side rendering. It seems mobile performance and concurrency were the main goals in building it.
But it also takes things to another level, such as it establishes a Websocket connection after it loads the page then, lets you shuffle page data as a binary (!) payload over.
I've only played with it as I am not doing much web related stuff at the moment but it looks pretty cool.
By building on ShareJS, DerbyJS uses Operational Transformation for collaborative editing of data in realtime, which means that users can see data updated immediately in their browser even if other users can edit the same thing at the same time. This is the same approached used by Google Docs.
Basically, you build your application frontend with pure Erlang terms to construct server-side templates, then make live changes to the interface over and websockets (as of the soon-to-be-released v2.3), ajax, or comet (if websockets are not available, or the websocket connection crashes, it'll establish reconnection or fallback to comet/ajax).
I recently did a talk at the Chicago Erlang Conference about it: https://www.youtube.com/watch?v=nlV4gm8SpVA
All of the other things, including history management / back button, are built into GWT.
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?
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.
I went looking for Inbox's template engine and came across:
https://code.google.com/p/google-jstemplate/wiki/HowToUseJsT...
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?
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.
There's an old set of slides here: https://docs.google.com/presentation/d/1JobclkctBvciYZ8CzHIo...
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.
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?
Also all of these files are cached once loaded, so they don't have to be loaded again until they are changed.
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.
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.
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.
Server side rendering is on the roadmap tho.
Instead of trying to find one tool that solves all of your problems, try understanding what your problems are. Once you have a list of problems, ask how you can solve each of those problems. When you have solutions, THEN you figure out which technologies are best for implementing those solutions.
After we hit our initial development deadline, we had time to actually research Angular, Ember, and Backbone. We settled on Backbone on the grounds that we could refactor our codebase incrementally, and it seemed to fit our use case best. Unfortunately, this later led to clashes with the "write it myself" dev, as he didn't want to use any outside frameworks beyond jQuery.
Anyway, having used Backbone for the last year, it definitely has a lot of limitations, but it also provides a very definite set of well-tested pieces that clearly help solve common development use cases. So yeah, very much in agreement with you there. Why try to totally build something from scratch if someone else has already done it for you, and it's been battle-tested by other developers?
I personally prefer (and find it more fun and a better learning experience) to build things from scratch with no frameworks at all, but I don't think it's a very savvy business decision unless you're doing something very novel.