Robert Važan

The surprising architecture of future applications

If you think the future is in JavaScript, you are mistaken. 'Downloading the universe' to the client is an old problem from the 90s that has a very simple solution.

Spoiler: The future lies on the web, in cross-platform data formats, mostly interactive video, with fully server-side application logic communicating with really dumb clients via specialized "view" servers. There's more to it. I will elaborate in a moment.

Predicting future is tricky. All predictions are based on extrapolation of current trends while distant future is always dominated by phenomena that haven't started yet. I think I can see 10+ years ahead with fair accuracy though, because technology doesn't change that fast due to users' resistance to change.

Mobile apps are a passing fad. Aside from disastrous usability of apps, it's not economical to port half a billion websites to multiple mobile platforms. Single global commercial platform is unlikely for political reasons. Mobile apps can provide extra revenue for the big players, but they are of no use for your small business or community app. You need one universal platform.

Another fashion trend that is currently underway is the HTML5 single page app. The problem is that apps are always built using tons of frameworks and libraries. It takes ages to download all that stuff to the client and mobile devices will never be able to run it efficiently due to the tight power envelope on the device.

While CPU power is already maxed out on mobile devices, network connectivity keeps growing. 4G networks will provide 5ms round-trip times, over 100Mbps in cities, and over 1Mbps in the country. Femptocells in apartments and offices will go up to 1Gbps. Fixed lines will go above 1Gbps. Connectivity will be truly universal, with remote areas connected via cheaper masts, balloons, and unmanned airplanes rather than the expensive satellites.

It is more efficient to run everything in the cloud and stream fully formatted content to the client as an interactive video. Web is already a primitive form of interactive video. You click links and get fully formatted pages back after every click. AJAX, WebSockets, and HTTP 2.0 are all designed to shorten latencies and to provide smooth transitions between frames of this primitive interactive video system.

The last obstacle is latency. It can take up to 200ms for full round-trip to complete even with fairly efficient Internet. Big sites can just build a global network of servers, so that everyone is close to one of their servers. Small sites will have to use "view servers" or whatever they will be called. View servers are an interactive version of CDN. They execute simple view logic in order to hide latency to the main application server.

This arrangement provides for maximum service quality and lowest total cost of the service. Video rendering works efficiently on dirt cheap devices thanks to hardware acceleration. Cloud servers have negligible cost per client. App developers can rely on full power of the cloud and they can choose development platform independently from publishing platforms. Every development platform will have its own network of specialized view servers that work well with that platform.

While most of these changes depend on expensive infrastructure, some steps can be taken even today. I wouldn't bother with client-side code in any new application except for short generic scriptlets that pull data off a WebSocket and merge it into the DOM tree or canvas or whatever. I wouldn't bother with native apps at all. Existing request-response databases and web servers should be dumped in favor of reactive alternatives.

I develop apps at my current job like this. I use my own frameworks, which is hard and it sucks time, but it's still more efficient than patching reactivity onto fundamentally request-response architectures. I went through a lot of app architectures before I found this one. There's more to app architecture than network layout and platform choice, of course. Perhaps I will be able to elaborate in later posts.