Sep 27, 2010
Oh, and those benchmarks! Compared trivially to the currently popular web technologies, it seems an obvious leap forward.
Not exactly the revolution I was hoping for.
You know what would be awesome? If we wrote our libraries so that they could run either on the server or on the client, and they did so in a transparent way. Maybe it would help to give a concrete example of how this could be awesome. Let's talk about HTML templating.
Imagine a framework where the first page-load was always rendered server-side, meaning the client gets a single fully-rendered page. Then for desktop browsers, browsing around the site just made calls to API endpoints returning JSON or XML, and the client rendered the templates for the changed portions of the page. For mobile browsers with less power or for search engines, the rendering would always be done on the server. Imagine that the templating library could record some key metrics to determine how long things were taking to render, and dynamically switch between rendering on the server and client based on server load or client speed.
Imagine a case where a back-end service fails temporarily. In this case the rendering of that particular component could be deferred, the browser could be told to poll a resource. When the back-end service is recovered, it could send the data for the client to render on its own.
How awesome would that be?
It's not just HTML templating, either. This same principle could be applied to any number of things: URL routing, form validation, hell even most application logic could be done using this style.
I just really hope that someday we stop re-inventing the same exact wheel, and instead build something substantially different and better.