Of Satellites and Rovers
A few months ago I responded to some well publicized criticisms of client-side JavaScript web applications with some counterpoints. I promised a followup post to help clarify architecture decisions for web applications, and here it finally is…
When deciding whether to develop a traditional web app that generates HTML on the server or a client-side JavaScript web app, it's easy to focus on questions such as:
- Which language can I use to write the bulk of my application?
- Which approach is faster to load initially?
- Which approach is faster to respond to subsequent actions?
- Which requires the fewest architectural layers?
These questions have fairly quantifiable answers, and one factor may be so important for your application that it overrides all others. However, when this is not the case, you may end up feeling like your architectural decisions are going to involve a lot of unpleasant trade-offs.
A Thought Experiment
If you're racked with indecision, consider this: should your app be a communications satellite or a Mars rover?
A communications satellite, placed in close orbit around the Earth, acts as a relay for transmitting data between two points on the planet. The satellite does not need to understand the data: it relies on the transmitter to package up content that the receiver needs.
Similarly, a traditional web app relies on the server to generate HTML content, which is sent directly to the browser when requested. Once it reaches the browser, content is presented to the user with little manipulation. Every interaction with the application requires a round trip to the server. The browser becomes a relatively dumb but efficient intermediary.
On the other hand, a rover is imbued with artificial intelligence. It needs to be able to navigate remote landscapes, react to unexpected obstacles in real time, and communicate findings back to mission control. It should be able to survive communication problems while still interacting with its environment. A rover is more complex and autonomous than a satellite, so it needs to be particularly well tested before launch.
Just as a rover receives instructions from home and then uses them to interact with its landscape, a JavaScript web app receives raw data and needs to be able to make sense of it. It interacts directly with a user through the browser, without the need to involve "mission control" in real-time micro-decisions. Instead, it communicates in short bursts that contain exactly what it needs and what it's found. It must maintain its own state and have rules defining how it should respond to state changes.
Futurama
If you're still on the fence, try to look beyond the present. I consider these to be safe predictions:
- Processors and browsers will become more performant.
- Applications will be able to target evergreen browsers as they become the norm.
- Improvements to JavaScript will make it more modular, capable and easier to code.
- JavaScript frameworks will mature. Client-side data libraries will become more sophisticated and will better handle caching, transactions, undo / redo stacks and synchronization.
10…9…8…
In short, if interactivity is important for your app, then launch its intelligence and its sensors as close to users as possible by building a client-side web app. Ember.js is particularly good at building complex, autonomous and interactive web apps, and it's only getting better.
On the other hand, if your site is fairly static and you simply want to broadcast content to users, a traditional server-driven architecture may be right for your app.
Either way, it's worth pausing to consider this decision carefully, because a change in your approach will be both time consuming and costly.