The web has come a long way over the years. From the early days of the information super highway, through the Web 2.0 phase to the modern day, more and more traditional desktop applications are moving online. There are so many reasons that the web is becoming the platform of choice, including accessibility from a multitude of devices ( tablets, phones, consoles, and smart TVs), limited system requirements, less up-front overhead, and search engine optimization, to name but a few. With the emergence of these rich applications on the web, developer tooling had to change. Welcome to the world of modern web application development.
From the server to the client
Enter the web application framework
Frameworks and libraries have long been essentials in the developer's tool belt. They provide features and design patterns that help us move quickly, iterate fast, and build rich applications without reinventing the wheel with every build. There are many client-side web application frameworks out there for developers to choose from, with a few front-runners worth mentioning. Google’s hugely popular AngularJS framework (which we love!) is in alpha with the brand new Angular 2.0. Facebook’s ReactJS growing in popularity at a rapid pace. EmberJS, Meteor, Ionic and many more, all provide their own unique approach to the development of client-side web applications. All of these frameworks and design patterns have a few things in common that are essential in building fast and powerful apps.
Reimagining the DOM
Reactive data flow
Another concept revolutionized by client-side application frameworks was data flow throughout an application, from user interaction to memory to the server and back. This solves an issue especially prevalent in real-time collaborative applications. Two way and three way data binding and reactive data flow were popularized by frameworks and tools like AngularJS, ReactJS, Meteor, and Firebase. Allowing data to flow from the server to the client and back again, keeping the UI, application and multiple concurrent users in sync throughout an application lifecycle. This breakthrough allowed developers to build highly collaborative real-time apps with ease, giving way for even more traditional desktop apps to move to the web. Collaborative document editing, chat rooms, social features, and realtime data sources became commonplace on the web and users can no longer live without them.
Components, components, components
I’m sure it’s no surprise to hear that the world has gone mobile. More and more web traffic is coming from mobile devices, tablets, and watches, and web applications are not excluded from this. Web applications need to be built from the ground up, both visually and in terms of functionality. The concept of mobile-first reaches much further than world of development. It’s a concern for strategy, user experience, design, and development. Users may have different goals depending on their environment and these issues need to be considered throughout the application design. From a development perspective, we need to consider the constraints and feature sets of these devices. We can no longer build a beautiful desktop application with fallbacks for handhelds. We need to build our applications to support a huge range of devices and environments, including hardware and network constraints. Building from the ground up and progressively enhancing our applications is the only logical way to conquer this oftentimes overwhelming modern landscape.
Speaking of mobile-first, web applications cannot always rely upon the web! As ridiculous as this may sound, the mobile world has led to users expecting to be able to interface with our applications wherever they are. This may be on their business spec wifi connection, commuting on the subway, or in parts of the world where LTE cellular data is a thing of dreams. These constraints led to the birth of offline-first. In the world of web applications an initial connection to a server must be made in order for the application to be sent down the wire to the user's device. Only after this initial connection can offline-first kick in. The idea is that a user can continue to use an application regardless of spotty connections, subway stations, or that frustrating in-between phase as you walk away from wifi. Ensuring we are not reliant upon an internet connection introduces a number of issues for developers to consider. Server pushes and pulls must be queued and must wait for that connection to return. User actions that require server communication must also be queued and ready for action at a later date. All of this must be coupled with a friendly interface that ensures the user that all is working as usual. You can think of email as a good analogy for this pattern. Email goes into your outbox even when you are offline, and when your connection returns, mail gets sent out. Client-side caching systems like LocalStorage, IndexedDB, and the Application Cache first made this possible. More recently, the ServiceWorker API has given developers much more flexibility in intercepting network requests and taking appropriate action. It’s certainly not easy, but with the help of some awesome tools like PouchDB, Hood.ie and carefully crafted codebases, developers can build amazing offline experiences, and in some cases, the user is none the wiser.
Where we're headed
The landscape of web applications has drastically changed over the years, from traditional server/client applications to mobile-first client-side apps, yet it shows no sign of decline. Frameworks are constantly pushing the boundaries to feed the forward obsessed innovators. We for one can’t wait for Angular 2.0. However, there are still many areas ripe for innovation. Perhaps the most exciting for us at Digital Surgeons is innovation of the interface. Gesture devices like the Leap Motion and Oculus Rift, plus technologies like WebGl and WebVR, leave the door wide open to extreme innovation of the interface. Controlling your application in a virtual world or 3D space could provide that extra level of human computer interaction that we need to feel at one with our applications. This is exciting, and trust us, we are already experimenting.