Angular 2, ReactJS, and the State of Modern Web Apps

Written by in Technology on

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

One major and notable difference between the early web applications and the apps of today is the steady move from the server to the client. Browsers and JavaScript rendering engines have been growing in sophistication and nowadays are extremely powerful. This allows developers to move more of their intensive logic away from the server and onto the client running directly in your browser, improving performance at an incredible rate. Users no longer have to wait for a round trip to the server and back, or long-winded page refreshes. Plus, many other techniques developers can implement mean web applications can suddenly compete with the traditional desktop application. 

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.

Performance matters

Although client-side apps drastically improve runtime performance when compared with traditional server/client applications, the first major hurdle developers had to overcome was load time. You probably remember the time that Twitter went through a major redesign, resulting in a blank screen with a few second delay before the first tweet was displayed. That was the result of this exact problem. The server responds to the initial request very quickly and sends the entire client-side application down the wire. However, that results in a blank screen while the masses of JavaScript powering the application are evaluated and rendered in the browser. There are many stats to show the importance of a rapid load time in this fast-paced on-demand world and this situation simply would not do. Developers set to work on building solutions to combat this huge issue and client-side applications took a step back. Servers are powerful and can be used to our advantage in loading applications quickly to give the impression of fast load time while our client-side app renders in the background. Server side rendering of client-side apps is no easy task, but tools like PhantomJS, Prerender.io and numerous NPM packages made it manageable, and now client-side applications can load as fast as their traditional counterparts. 

Reimagining the DOM

Once the load time problem was solved, client-side applications ruled the world of performant web applications. However, talented developers did not stop there. Perhaps the most expensive task on the client-side is reading and writing to the DOM. Excessive and careless reads and writes can result in a janky user experience, terrible rendering performance, in some cases unusable UIs and crashed browsers. To combat this, developers imagined clever techniques like batching DOM writes and utilizing the GPU for intensive graphics rendering. However, Facebook was the first to revolutionize and popularize the concept of a virtual DOM. Moving the DOM into memory, managing reads and writes in JavaScript, and comparing the differences before finally writing to the DOM improves rendering performance to an extreme degree. ReactJS brought us a virtual DOM and many frameworks followed suit, Famous and Angular 2.0 both boast similar concepts. It’s truly amazing what the smartest minds in web technology can do when faced with a problem!

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

With the big move from the server to the client comes the overhead of a large codebase. Gone are the days of a single JavaScript file, piled high with spaghetti jQuery code. Try maintaining a large web app written in that manner! Instead, developers have sought after structure and coherence to their codebase, something that is manageable and maintainable in a large team over time. Client-side frameworks have been offering MVC-like structure for a while now but more recently we have seen the emergence of component-driven UI design. Building standalone UI components that handle single pieces of functionality provides some sanity in working with these large code bases, not to mention testability and debugging! React’s components and Angular’s directives are good examples of this componentization of the UI, and many of these framework’s custom implementations lead to native Web Components and frameworks like Polymer. Although the Web Components spec may still be maturing, developers can take this approach in designing their applications and reap the benefits today.

Mobile-first

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.

Offline-first

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 PouchDBHood.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.

Discuss on Twitter