Of Satellites and Rovers
- 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.
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.
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.