Web Apps: Past, Present, and Future

Nico Valencia
Apr 18, 2019 · 7 min read

A brief chronology of web applications to explain what kinds of web apps exist today, how these came about, and what’s coming next.

Image for post
Image for post
Image credit: Katy Jeremko

🏰 Past

SSR was the original way to deliver web apps over the Internet. A computer in a warehouse (like Amazon’s AWS) runs code to build a page when you ask for it in your web browser.

📩 — SSR is like a snail mail order: you send a letter requesting something (web page). It goes to the warehouse where they put your order together and send it back to you (web page).

SSR is less of a web app category, and more about the way pages are built and delivered to you over the Internet.

At the very end of 1999, browsers began adding support for XHR. This allowed the use of Asynchronous JavaScript and XML (Ajax) to build web apps that could load additional information, after the original page was finished loading, then modify the page without navigating to another part of the app.

🍜 — Imagine ordering soup at a restaurant (web page). It’s not spicy enough. Instead of asking the kitchen to make a whole new bowl of soup that’s spicier, you just ask for some pepper (additional information). Ajax lets the browser ask for additional information to modify the web page.

Ajax gained popularity in the early 2000s, exploding with the introduction of the Prototype and jQuery JavaScript libraries in 2005–2006.

Popularity of Ajax continued to grow, until the mid-to-late 2000s when the open source community began experimenting with SPAs. A SPA loads a single web page from the server, then continues to modify that page for the entirety of the app experience.

💅 — a SPAs is like an all-inclusive resort. Once you travel to the resort (web page), everything you want is managed and brought to you behind the scenes. You don’t need to travel anywhere else or change your context the entire trip. The experience is fully fluid, and there are no jarring wait times or holdups.

Most JavaScript web app frameworks & libraries based their architecture on a SPA experience: Backbone.js, AngularJS, Ember.js, Knockout.js, Meteor.js, ExtJS, Vue.js and React.

When the iPhone launched in 2007, Steve Jobs originally intended iOS apps to be written and delivered as web apps. The terrible performance of web apps resulted in a need for something snappier, thus iOS and Android native apps were born, eventually delivered via the Apple App Store and Google Play Store.

While many popular apps were delivered in native code — Objective C (iOS), and Java (Android), many web developers wanted in on the app store action. Projects like PhoneGap allowed a web app to be wrapped in native code and deployed to the app store as a native app.

🗣 — *Native apps* are like speaking fluently in your own language: you understand the features and intricacies of the language and are efficient in communicating complex thoughts. *Native-wrapped apps* are like speaking in a foreign language: you understand how to use basic features, but are slower and struggle communicating more complex ideas.

These solutions were great for certain things; however, they faced tremendous performance and consistency issues across the growing number of device types.

PWAs encompass browser functionality that enable traditional web apps to behave more like a native app. Core features include offline support, push notifications, and a growing number of hardware features like camera or GPS integration.

🦄 — Adding PWA support to a web browser is like offering a common language so everyone can collaborate with the same efficiency. Rather than needing a personal translator, web apps can communicate fluently with features (like camera or GPS), regardless of the language (web, native, etc.).

Google has been a significant advocate for supporting PWA functionality in desktop and mobile Chrome. The concept of PWAs only work as much as browser vendors support the W3C specification.

Facebook championed the concept of hybrid web apps in 2015, launching React Native. Hybrid web apps allow certain parts to be written in web code, and other parts in native code.

This approach was meant to fix many of the performance issues with Facebook’s then-web-heavy app approach by combining the benefits of native with web in a way that helped support code re-use and team collaboration.

💻 Present

These three options represent most of today’s web applications. No method is “right” or “wrong”, as they solve different problems.


  • Build once, use everywhere
  • Some control of device functionality


  • Poor performance
  • Complex build process
  • Limited or inconsistent control of the device

Conclusion: access to device functionality — cameras, GPS, etc.— can add great opportunities to enhance modern web applications. A wrapped application can save significant money, compared to building native apps for iOS, Android, and Windows. That being said, many teams are opting for hybrid web apps instead, seeking better device support and performance. Today’s primary use-case is quick and inexpensive development on a cross-platform app that needs to be distributed via the app store.


  • Build some parts once, use everywhere
  • Use familiar framework across web/mobile teams
  • Better control of the device than a native-wrapped web app
  • Native performance


  • Difficult to customize interface
  • Requires native and web developers

Conclusion: hybrid apps have resulted in high profile experiences that feel snappy, and have access to specific hardware features, like Facebook, Instagram, and Twitter. This approach saves cost when building well-vetted designs across multiple platforms, but can cost more than it’s worth on an early stage application. The deciding factor for choosing a hybrid app is typically the overhead attached with writing both native and web code, the need for hardware specific features, and app store distribution.


  • Build once, use everywhere
  • Offline mode
  • Native push notifications & add to homescreen
  • Search Engine Optimization (SEO) advantages
  • Partial native device functionality
  • Most reliable/stable


  • Partial support in iOS
  • Lacking some native device functionality

Conclusion: PWAs are currently undergoing a major growth-spurt. Web browser vendors, particularly Apple, are rapidly supporting more progressive functionality, and the combination of speed, SEO, offline mode, and various device functionality has made PWAs a perfect strategy for launching cross-platform application experiences, at an approachable cost. PWAs can also be enhanced with hybrid functionality at a later time, as well as be rendered server-side (SSR) or client-side (CSR). A PWA is most likely the best choice if the core user interactions can be technically supported.

🔮 Future

A collaborative project (W3C, Mozilla, Microsoft, Google, Apple) that allows developers to write code in any language, then deploy it across hundreds of devices.

Wasm is intended for highly performance-intense operations and — while mostly experimental now— is being leveraged by a significant number of companies to develop next-generation graphics and processing abilities for web apps.

The blockchain ecosystem has invented a concept for the Internet’s infrastructure: allow everyone in the world to lend their computer, laptop, or cell phone, in order to create a massive world-wide computing system.

This decentralized system could solve several traditional challenges, such as sharing data in low internet connectivity areas, ensuring security and availability of important web content, and allowing safe and affordable financial transactions to happen between international parties.

Due to the alternative approach of this system, a slightly different set of end-user experiences are required to interact with this concept network. Decentralized applications — or “Dapps” — combine traditional [Web 2.0] app technology with decentralized “Web3” counterparts.

Adoption of progressive functionality has spurred massive collaboration between browser vendors, which will likely result in converging benefits between native and web development. This means investing in PWAs now will likely pay-off down the road, as new functionality is added in the coming months.

Google has doubled-down advancing PWA capabilities over the past year, bringing more of the functionality from native devices to web apps that maintain effective SEO, customizability, offline support, and affordable development costs. These abilities will continue to trend towards those of native apps found in the app store, creating a diverse set of approaches to creating an excellent user experience.

We’d love to see more integration with IoT and digital assistant ecosystems. This might include hybrid web and voice-controlled apps, or IoT networked systems that lend functionality to web apps. What will web apps look like when cars can fly, robots cook breakfast, and disco is back in style?

tl;dr — web apps can be built and deployed several ways. Each method is great for specific reasons, so make sure to understand the benefits and pitfalls of each.

Are you building a web app? We’d love to hear about it, or work together at Two’s Complement. Share your thoughts with us on Twitter!

Image for post
Image for post

Nico Valencia is a Partner at Two’s Complement, a design and technology studio. Connect with him at @nico_valencia.

Two’s Complement

2C is a design and technology studio.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store