Already more than 10 years ago, when Google Docs came out, IT experts predicted the time of fat-clients, needing to be installed on your local PC, would long be over. With the ever-increasing power of modern browsers, any application could be served as a web-app and your PC would transition to a light-weight terminal, on which only a browser would be installed and running. Unfortunately looking at my PC today, this trend is far from being completed as I still have dozens of applications deployed on my PC.
As always reality did not quite catch up with the predictions, for multiple reasons:
- Browsers still have certain functional limitations, making it difficult to build web-applications with same feature completeness as a desktop application
- Technical performance of web-based applications is often worse than when installed locally. E.g. Google’s gaming platform (Stadia) only came out in 2019, as it took Google years to resolve the latency issue, which is crucial for a good gaming experience.
- Access to the internet: when applications are not installed, but instead are offered as SaaS solutions, it is required to have an internet connection at all times. While at home and in the office, this is not really an issue, when working on the road (e.g. on the train or at a client) this can be quite challenging. 4G (and soon 5G) networks are a solution, but for personal usage continuously retrieving applications of several dozens of megabytes over your mobile internet connection, will soon exceed your quota.
- Size of application: currently many desktop applications are monolithic. If they would be migrated to a single-page app, this would mean a download of dozens of megabytes before being able to start the application. It will be required to make them more modular and only download the modules required at a certain moment.
- Legacy of software vendors: vendors like Microsoft (with Windows and Office suite) have invested millions and several years in creating current code base. Transforming this legacy into a fully web-based application is easier said than done. Office 365 is a first step, but as most of you probably already experienced, the user experience of the online Excel tool, compared to the locally installed Excel is far from the same.
- Legacy of companies: many companies have developed internal web-based tools, which are not compatible (or at least not guaranteed through extensive regression testing) with modern versions of browsers. As a result, many companies are forced to stay on old version of browsers, which make it impossible to develop new innovative web-based apps in (requiring modern web-browsers).
- Data privacy concerns: when all applications are working in the cloud, this means also that all data is automatically in the cloud. As many people are still resisting to cloud for data privacy reasons, this is also an important concern to be addressed.
Nonetheless the advantages of browser-based apps are so big, that ultimately they will win over locally installed apps, i.e.
- Everybody is automatically working on latest version of an application (avoid having to support old software versions, having to push security patches…)
- Browsers come with strong built-in security features, which are automatically applied to a browser-based app. If there is no software installed locally anymore, several security issues (like viruses, worms…) can be significantly reduced.
- Users don’t need to reinstall and reconfigure all applications when switching PC
- As a lot of the heavy calculations can be done at server-side, the computers can have cheaper, less powerful hardware
- Cheaper usage-based licenses, instead of having to acquire software you almost never use
- All files are automatically and immediately stored in the cloud, meaning files are automatically backed-up
Several new emerging technologies might finally allow to transition to the fully browser-based app world:
- Web assembly: this new technology allows binary files (i.e. compiled languages like C++, Go or Rust) to run in the same browser sandbox as regular JavaScript code. This enables high-performance applications in the web-browser and opens the browser to code from any programming language.
- Progressive Web Apps (PWAs): these web apps combine the best of both worlds, allowing to run in the browser, but also allowing to be used when offline (or on a low quality network), to push notifications to users (even when web page not open) and to access device hardware.
- Single Page Applications (SPA): these are applications contained in a single web page, allowing several user interactions without the browser having to load new pages. Contrary to the 2 above technologies, this technology has become already very common (i.e. all well-known websites like facebook.com or gmail.com, use already this technology). The technology allows a high responsiveness and less network load, but the size of the application to be loaded starts becoming an issue. This is being tackled by minification (removing all unnecessary characters from the code), compression (gzip) or a modular architecture, where only a core composer component is loaded, which retrieves, initializes and runs other modules only when needed.
- Static site generators (also called Jamstack), like Gatsby, Next.js, Hugo, Hexo, Jekyll, Slate… These tools allow to pre-build (pre-rendering) different static HTML-based pages of a website, based on the HTML, CSS, data and JavaScript code. This means that page can be automatically retrieved and does not need to be built at the moment the user requests a specific page. This technique allows to improve performance considerably and gives also certain security benefits (as there is less interactions with the server). Of course, static site generators also come with the disadvantage that the site becomes much less interactive.
- Content Delivery Networks (CDNs), such as Akamai, Limelight and Mirror Image, provide growing networks and more and more features (e.g. AI based smart routing and smart predictions of CDN cache renewals) to help boost the performance of heavy and complex web apps. Especially in combination with static site generators, CDNs can even more effectively improve the performance by caching all the static content.
While on personal computers, there is a trend towards browser-based apps, it is strange to see that we don’t see the same trend in the mobile space. While initially we saw a lot of "m." websites and later responsive websites (websites which could also be correctly rendered on a mobile device), today almost for everything a native app is being created, even though we see here similar issues:
- Slow release cycle, especially with certification processes of Apple and Google sometimes taking several days
- User having to continuously reinstall dozens of apps, often resulting in version conflicts with mobile operating system version or with app backend if not correctly upgraded.
- Valuable disk space on the smartphone being filled by apps, leaving little room for user data (like pictures)
- Difficulty to have different apps depending on environment, user…, making segmentation and testing strategies (like A/B testing, canary testing) more difficult to achieve
- Users not wanting to make effort to install app for infrequent or one-time usage
At the same time the features of mobile phones are still evolving strongly, which means that the browser cannot always follow the latest new features provided by mobile phone providers to native developers (e.g. advanced access to camera, compass, accelerometer, swipe gestures, AR-toolkit…) and native apps provide the fastest, most reliable and most responsive experience to users. Furthermore, users are well-acquainted finding apps on their phone, rather than having to open browser and go to a specific website.
But also, in the space of mobile devices, technological evolutions will gradually make the deployment of apps, which needs to be installed on the device obsolete:
- Most native apps currently require a separate development for Apple phones (native iOS apps are usually written in Swift or Objective-C) and Android phones (native Android apps are usually written in Java), making the development cost very high (more than one code base) and quickly resulting in inconsistencies between both mobile platforms. Cross-platform development frameworkslike React Native (from Facebook and used by e.g. Facebook, Walmart, Tesla and Airbnb), Flutter (from Google), Titanium (used by e.g. eBay or PayPal) or Xamarin (from Microsoft and used by e.g. Slack and Pinterest) try to give a solution to this (develop once and build for multiple platforms), but come still with certain limitations (as they typically need to foresee the common denominator between all supported platforms) and still require to install an app. Thanks to large open-source communities these limitations are rapidly resolved, while remaining gaps can still be resolved by a partial native development (but this mix of technologies complexifies app considerably).
- Responsive web apps are web sites which render nicely in the browser on a mobile device and are developed using JavaScript, CSS and HTML5. Due to evolutions in these languages, the features of such sites are becoming more and more rich.
- Hybrid apps: these apps are installed like a native app, but actually are a simplified browser, in which a web-app (built in JavaScript, CSS and HTML5). Typical hybrid app platforms are Apache Cordova (PhoneGap) and Canvas. These apps are easier to scale and upgrade (new versions of code don’t require an upgrade by the user), have only one code base to manage and still give the app experience to the user. On the other hand, responsiveness and UX will be negatively impacted and it’s also more difficult to make use of the latest feature of a mobile platform.
- Low- and no-code platforms: the rise of low- and no-code platforms for developing web and mobile apps results also in a rise of hybrid apps, as these platforms typically result in hybrid apps.
Will be interesting to see how all those new technologies unfold, but with an increasing digitalization of our world, it’s clear that any overhead and non-productive work (like maintaining 2 code bases for different mobile platforms, having to install and continuously upgrade apps on devices…) will gradually disappear, when feature sets of browsers become more and more powerful.
What is less clear is where compute and business logic will be executed, i.e. on the client or server-side. Executing code on client-side typically gives better responsiveness and a more dynamic app behavior but means also higher hardware demands at client-side and less control by the app provider. Many technologies mentioned above (like e.g. web assembly) will further enforce this movement. On the other hand, execution on server-side gives more control and requires less compute power on client-side, but on the other hand requires more network bandwidth and a highly scalable server-side. Also in this domain, many new technologies provide answers such as elastic scalability (thanks to cloud infrastructure, container orchestration systems, functions-as-a-service…), compression techniques, more sophisticated CDNs… As in many situations, this comes down to the traditional choice between decentralization (execution as much as possible on client-side) and centralization (execution as much as possible on server-side), which traditionally swings back and forth, but will ultimately end in between, making use of each side depending on the use case.
Check out all my blogs on https://bankloch.blogspot.com/
Comments
Post a Comment