Chapter 2: Challenges Faced by Frontend Web Application Developers
Frontend web application developers are tasked with a tough challenge: ensuring that web apps work and perform exceptionally well across all digital channels (web and mobile). In an era when a new desktop web browser version is released into the market every month, with numerous mobile smartphones and OS versions to support, this task is quite hard. Frontend web developers should address both the quality and velocity, as well as the stability of their apps, continuously.
This chapter covers the key challenges modern web application developers face and their root causes. It is specifically designed to cover the constant debate about velocity, quality, and key non-functional challenges that are a pain for developers. By the end of this chapter, you will have an understanding about the common pitfalls in web application quality assurance that covers both the functional aspects, the non-functional ones like performance, and equally important – the security level of the application being built.
This chapter will cover the following topics:
- Web application development challenges
- Coverage challenges for web application developers
- Non-functional challenges in web application development
- Compliance challenges for web applications
Web application development challenges
As highlighted in the previous chapter, the digital transformation over the years has increased the complexities in building top-notch web applications. By top-notch, we mean apps that can function properly across all web browsers, mobile devices, and operating systems, across various environment conditions, and under massive load conditions. In addition, with the rise of digitalization, security and accessibility have become key requirements for any application prior to its release.
In an insightful report (https://insights.developer.mozilla.org/reports/mdn-browser-compatibility-report-2020.html) published by two of the leading browser vendors, (Mozilla and Google), it was clear how complicated it is to build a web application that is compatible with all technologies and platforms in the market.
One of the top items found in this study was ensuring compatibility with old browsers, even with the old and end-of-life Internet Explorer 11 browser. Next on that list were layout and styling items, which consist of CSS, responsive web layout issues such as viewports, scrolling on responsive web apps, and other UI-related issues.
Layout and styling around CSS were attributed to two main CSS configurations: Flexbox and Grid.
A comparison between these two configurations can be found at https://www.geeksforgeeks.org/comparison-between-css-grid-css-flexbox/.
These two options help developers position UI elements within the web application in ways that can fit different screen sizes, layouts, and platforms. At the URL showing a comparison between the two configurations, there are a few examples of how the HTML code looks in both the implementation of the <style> code block and the trade-offs between them. While we won't dive deep into the implementation of CSS types, this item is one of the challenges developers face when building their apps. Developers find it challenging to ensure the CSS sticky and animation grids are consistent among browsers.
CSS sticky elements are used by developers to keep an element fixed on the web page while a user is scrolling throughout the page. Items such as headers and navigation bars or other core elements of the web application could be set as sticky to always be visible and accessible to the user. While this is a great usability feature for developers, this isn't always a compatible feature across browsers on web and mobile.
Other issues that were high on the list were web performance maintainability, web app quality on the Safari browser on mobile platforms, and the item previously covered in Chapter 1, Cross-Browser Testing Methodologies: PWAs.
In the following summary graph, for each survey respondent, the report classified their top five categories out of the 12 available. With that in mind, the following shows the top pain points averaged by all respondents that are listed; the IE browser and layout and styling emerged as top challenges.
Figure 2.1 – Top pain points for web application developers (source: MDN Web Docs, Mozilla
(https://insights.developer.mozilla.org/reports/mdn-browser-compatibility-report-2020.html))
JavaScript is the dominant development language for building web applications, but it is also among the pain points developers tend to highlight. In some cases, the reason is coping with different ECMAScript versions that are not always aligned across all browser versions, and sometimes it can be very specific language issues on a given browser version and how that version can be used in each web application scenario.
ECMAScript
ECMAScript is a standard for ensuring the interoperability of web pages across different browsers. JavaScript is, in a sense, an implementation of the original ECMAScript standard. The most recent standard version out there is the ES6 edition (https://262.ecma-international.org/12.0/). Web application developers should use this set of standards throughout the implementation phases.
Next, we will dive into additional challenges around market platform coverage, and later in the chapter, we will discuss non-functional related aspects such as security, performance, availability, and accessibility.
Quality vs velocity
An important debate that is agnostic to any software development project is the one that tries to balance between the velocity of the release cycles and the quality of the deliverables. To take the debate forward, practices such as Agile, DevOps, and continuous testing were defined to allow practitioners to better balance release velocity and quality while being able to continuously deliver value to customers. Velocity varies between organizations, and it depends on the application complexity, the scope of the release, and the maturity of the teams working on the release. All these considerations can impact the release frequency (velocity). On the other hand, the quality of the app is something that can be considered infinite because you cannot test each single line of code and use case; therefore, risks are taken all the time. The art of Agile software development is to properly balance the speed and release cadence with the quality criteria that are considered safe to the end users. Test automation is a key enabler for software velocity since it drives faster feedback back to the developers and allows them to gain confidence in their latest code changes as well as the overall application quality from a regression standpoint. When product management and engineering work together with the QA teams to define a software iteration cadence of, for example, every 2 weeks, the teams must plan these iterations carefully and allocate room for test automation development and execution so that quality goals match the velocity ones with minimal risks.
Coverage challenges for web application developers
An additional challenge that developers face is coverage across web and mobile operating systems and platforms. On a monthly basis, both Google (https://www.chromestatus.com/features/schedule) and Mozilla (https://wiki.mozilla.org/Release_Management/Calendar) release public General Availability (GA) and beta versions to the market. Such releases disrupt the web applications in many cases and require developers to ensure that the new versions are still compliant with their apps. As web traffic is higher on mobile platforms nowadays, ensuring the continuous quality of the web application across different iOS and Android devices and OS versions is key to success.
The following figure shows the browser market share month on month for the period from October 2020 to October 2021:
Figure 2.2 – Browser market share worldwide, all platforms (source: Statcounter GlobalStats)
Google Chrome is the most used browser in the market, but with a monthly release cadence, the cost of failure is high; hence, developers and testers must keep up with the newly introduced browsers and features. After the Apple Safari browser, which holds a significant market share, the bigger problem is the rest of the market share is distributed across five or six browser vendors with similar levels of adoption. This mandates proper attention to the other less popular browsers such as Opera and Samsung internet since these browsers carry similar market share as Firefox and Edge.
In the following market share snippet, also from Statcounter (https://gs.statcounter.com/browser-market-share/mobile/worldwide), we can see a different market segmentation across browsers when we only focus on mobile platforms:
Figure 2.3 – Browser market share worldwide, mobile only (source: Statcounter GlobalStats)
In the preceding screenshot, Google Chrome on Android is leading the industry, with the second highest market adoption rate being seen for Safari WebKit, and Samsung Internet Browser.
We should now also consider on top of the above web browser compatibility challenge, the ever-growing mobile challenge with so many Android device providers globally, and the numerous iPhones and iPads on the market.
Based on the Statcounter market share analysis of mobile device providers (https://gs.statcounter.com/vendor-market-share/mobile), Apple holds around 28% of the global mobile market share, which leaves the remainder of the market to various Android providers, such as Samsung, Xiaomi, and Huawei, among others. Some of these vendors (for example, Samsung) provide their own built-in browsers, and others support Chrome, Opera, Firefox, and UC browsers running on their devices.
With the various types of web applications that were introduced in Chapter 1, Cross-Browser Testing Methodologies, web developers need to ensure that regardless of whether they are building a responsive web app, a PWA, or a standard web application, they should all work perfectly well across the different mobile and web platforms.
To be able to at least know where to focus the platforms testing on in this complex marketplace, it is highly recommended to periodically obtain a web traffic analytics report that can provide developers and testers visibility into the top user agents and platforms that are visiting the websites, and also, from which country or location they originate. It's known that each geography has a different mobile and web market share; therefore, knowing which users visit your website the most is key to building a proper development and testing lab.
From market analytics sources like the one in Figure 2.4, developers and testers can realize the breakdown of mobile platform per country and better plan their testing.
Figure 2.4 – Mobile vendor market share worldwide (source: Statcounter GlobalStats retrieved from https://gs.statcounter.com/vendor-market-share/mobile)
Note that on top of the standard web and mobile platforms, there is a new set of mobile devices called foldables. Such devices are unique in many ways, having two layout features (folded and unfolded) and the ability to run up to three applications in the foreground in parallel, including the browser; therefore, these devices need to be also considered as part of the web application development and testing. Another growing trend in the market is a new type of framework called Flutter, (some organizations might consider React Native as an alternative to Flutter). The challenge with such apps is that while a single code base can produce multiple binaries that run on mobile devices and desktop browsers, such apps are built with the Dart language and use a unique architecture developed by Google that web application developers are not yet familiar with.
Flutter
Flutter is Google's free and open source UI framework for developing cross-platform rich applications from a single code base. A Flutter application can be compiled into a mobile Android and iOS binary, as well as a desktop and Linux application. The Flutter framework consists of various reusable UI elements, such as sliders, buttons, and text inputs. Developers building mobile applications with the Flutter framework will do so using a programming language called Dart. You can read more about Flutter architecture here: https://flutter.dev/docs/resources/architectural-overview
Figure 2.5 – Flutter application architecture (source: the Flutter.dev website)
With the aforementioned challenges in mind, it's also important to note the growing selection of web development frameworks as highlighted in Chapter 1, Cross-Browser Testing Methodologies, which includes Vue, React, and Ember. This is an additional challenge for developers who need to select a framework that will grow with their web applications for the long term. There is a lot at stake when choosing the right technology.
Let's summarize the high-level pain points that we've covered so far in this chapter:
- Compatibility with new and trending digital platforms as well as old browser support
- Coverage strategy for web and mobile platforms
- Style and layout across different browser versions and OS versions (CSS, animation grids)
- JavaScript and ECMAScript compatibility across browsers
- Complexities around new types of web applications, including PWAs and Flutter
- Choosing the right web development framework
Now that we have understood these key functional challenges, let's learn about non-functional challenges web application developers face.
Non-functional challenges in web application development
In addition to the challenges mentioned so far, web application developers are also required to continuously guarantee high-performing web applications that are always on and available, as well as an app that 100% adheres to complex accessibility requirements. In this section, we will explore performance and accessibility challenges across web applications.
Performance challenges
For many years, the industry considered a response time of more than 3 seconds for a web application to load (whether running on a desktop browser or a mobile browser) to cause a customer to move to a different website. Research conducted by Limelight Networks, which was featured in an online document published by Broadcom (https://docs.broadcom.com/doc/its-all-about-the-user-experience), shows the different time thresholds and the patience levels of end users today when using web applications. The majority of users will not be willing to wait more than 3-5 seconds for a website to load. For websites that exceed these thresholds, users will switch to an alternative website.
Ensuring high-performing web apps with the growing load and usage that is experienced nowadays is a huge challenge for developers. Developers should consider performance and availability as part of the web application design, think about ways to optimize load times across the different web pages in a web application, consider multiple platforms across geographies and network conditions, and consider peak usage versus standard usage. Businesses consider data-driven strategies to enhance the user and customer experience (UX/CX) by providing the most relevant, highly downloaded content at the top of their web applications to keep users engaged and satisfied.
Performance testing as well as load/stress testing is no longer simply a nice-to-have or an activity that can be left to the end of the software sprint; rather, it needs to be shifted to the early stages of the sprint. Identifying bottlenecks and performance issues against agreed benchmarks and key performance indicators (KPIs) late in the cycle is a very risky and expensive practice. Finding the root causes of such issues and fixing them is a highly time-consuming activity for developers; hence, this type of testing must be given equal importance among other functional testing processes.
Developers have various mature performance testing tools that perfectly integrate with the CI and Continuous Deployment (CD) tool stack that can be adopted and used regularly to ensure the continuous performance of web applications. In addition, web browser vendors, including Google, Microsoft, Mozilla, and Apple, provide built-in developer tools that can cover performance and monitoring aspects, as well as accessibility and PWA compliance.
Accessibility challenges
Organizations and practitioners might argue that accessibility is not a non-functional requirement but rather a function of the app that needs to be always covered. Regardless of the segment or testing type in which we classify accessibility testing, this type of testing, like performance testing, should be part of any software sprint and automated and shifted left as early as possible in the development cycle. Web and mobile accessibility is not an option but a key requirement that comes with massive fines and business implications when done wrong.
Based on the ADA compliance law website (https://getadaaccessible.com/ada-compliance-law-and-penalties/), organizations can expect fines of $55,000 for their first WCAG violation and/or 508 non-compliance, with a double fine of $110,000 for any subsequent violation.
WCAG
WCAG is a wide range of recommendations that can help make websites more accessible for impaired users and people with disabilities. W3C stands behind the definition of the rules, and constantly updates and maintains them. These rules are technology agnostic and are developed to ensure that people who suffer from low vision, deafness and hearing loss, cognitive limitations, and other issues can also consume website content at all times.
The WCAG (https://www.w3.org/TR/WCAG21/) organization has defined and continuously maintained its requirements around web accessibility to ensure that any user with any kind of disability can consume the web application content, engage with the application across any form factor, and get the same value from the web as any other user. Developers are required to keep accessibility at the front of their minds when adding any new field or element to their web application. They are required to provide accessibility IDs, tooltips, voice-over functionality for screen readers, and much more. To comply with these accessibility requirements, product managers, R&D managers, and businesses need to properly allocate time within the sprint to allow developers to properly implement their features and meet these guidelines.
At the other end, software testers must continuously test and cover the accessibility aspects of the web applications using automated software and other exploratory techniques.
There are several tools available for automatically checking for accessibility issues. Here is an example of an accessibility issue that can be easily and automatically captured through the Google Chrome built-in Lighthouse tool running against a given website, in this case, http://msn.com. As identified by the scan, the contrast ratio between the background and foreground colors is insufficient, which will make it hard for visually impaired users to see the images on the website:
Figure 2.6 – Accessibility scan via the Google Lighthouse tool on the msn.com website
Web testing for accessibility can be done free today by using the open source AXE (https://www.deque.com/axe/) framework from Deque. Running this tool in conjunction with the W3C Selenium framework provides both functional and accessibility coverage. The AXE plugin was also added to the Cypress plugin store and allows developers and test engineers to create JavaScript test code that validates both the functionality of a web application as well as its accessibility level.
Later in the book, we will cover in more depth how Selenium and Cypress can help web application developers validate many of the challenges highlighted in this chapter.
Now that we've looked at some of the non-functional challenges faced by developers during testing, let's look at some compliance challenges.
Compliance challenges for web applications
Data privacy and cyber security have grown to become two of the biggest challenges and concerns for web and mobile application developers. Failing to protect a web application from significant data breaches and other vulnerabilities can mean the difference between a living business and a failing one. Since security and data privacy is a 24/7 risk, web application developers must build security early into the functionality of their apps, leverage Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools, and maintain their code continuously.
SAST
SAST is a method for inspecting and analyzing application source code, byte code, and binaries for coding and design conditions to determine security vulnerabilities. Unlike DAST, SAST is also known as a white box testing approach that scans the source code of the application in a non-running state.
DAST
DAST is a method that is also known as black box testing. It is designed to scan the source code of a running and compiled application. It tests the application software from the outside in, unlike SAST, which tests the application code from the inside out. To run a DAST scan, developers need a running and compiled application made available to them.
There is no good or bad with SAST and DAST: both are important and provide value to developers in the different stages of the software development life cycle.
Developers are adopting static and dynamic code analysis tools more than ever and are executing security scans across their web apps to ensure high security and compliance with standards.
Google is enhancing its data privacy restrictions, and GDPR requirements are becoming stricter across Europe and North America. Developers should better understand the various risks and rules around data privacy and security across different market segments; for example, if the web application is intended for healthcare, then regulations such as Health Insurance Portability and Accountability Act (HIPAA) are relevant, and for financial industries and payments web applications, Payment Card Industry Data Security Standard (PCI DSS ) is relevant.
Based on a Forrester report (https://www.forrester.com/report/Using-AI-For-Evil/RES143162), cyberattacks will soon be utilizing AI to attack businesses in more sophisticated ways, and with greater implications for the business.
Also, with the rise in 5G and IoT, more data streaming services are out there and being consumed across automotive infotainment systems, such as Apple CarPlay, Android Auto, and other devices. This big data and greater exposure bring higher risks to the business.
Developers and software testers should embrace coding standards and static and dynamic analysis of their source code earlier in their development cycle. There are many maintained security compliances, including Common Weakness Enumeration (CWE), Open Web Application Security Project (OWASP (https://owasp.org/www-project-top-ten/), and other market-specific compliances such as those mentioned earlier, to be executed and scanned within the CI/CD pipelines.
The following figure shows the trend summary of security vulnerabilities, revealing that there are a lot of shifts in security issues across applications over time:
Figure 2.7 – OWASP top 10 security vulnerabilities (source: OWASP.org - https://owasp.org/www-project-top-ten/)
As shown in the preceding figure, broken access control has shifted from being fifth on the OWASP list to first in 2021. Such shifts are attributed to the number of incidents that are being reported in the market across applications. More occurrences of such cases contribute to moving such risks higher on the list of issues. The broken access control vulnerability is part of the common weakness enumerations (CWE) set of security rules that applications should cover as part of their security testing. There are many areas under that rule that can cause a broken access vulnerability. Based on OWASP documentation, allowing attackers to bypass access control by modifying a URL, permitting a view or edit of someone else's account, or elevation of privilege through acting as a user without being logged in, can result in the above security issue.
Developers should in such cases enforce record ownership as part of the web application model access control or disable a web server directory listing to ensure file metadata and backup files are not present within web roots.
Security, data privacy, and compliance are huge challenges and great business risks, and as such, must be part of web developers' objectives and strategy. As identified previously, security threats are dynamic and can vary across segments; hence, it is critical to train web application developers on security topics, mitigation of such vulnerabilities, and provide them with access to online training tools around security such as Secure Code Warrior (https://www.securecodewarrior.com/) and others.
Summary
Web application developers today are not only required to be highly skilled JavaScript developers, but also trained and aware of many other considerations, to ensure that a web application is successful, high-performing, and secure.
In this chapter, we covered the various challenges that developers should not only be aware of but need to plan for, as part of their ongoing software iterations. We specifically covered the functional challenges involved in building a winning web application, such as coverage and cross-browser compatibility, as well as the layout and styling, such as CSS, of web applications. We then touched on JavaScript coding challenges before moving on to non-functional challenges. These non-functional challenges included the performance, accessibility, and security of web applications, and what web application developers should consider daily to prevent such issues.
Keep in mind that all the challenges that were covered in this chapter are relevant for a moment in time – security risks change, accessibility requirements change, and so do functional issues across new browsers and mobile platforms. Continuous coverage of the previously mentioned challenges as part of a quality strategy can ensure ongoing application functionality, performance, and security.
When building a quality plan for your web application, developers, testers, and product management must huddle together and ensure that all of the considerations covered earlier in this chapter are addressed and have dedicated owners.
In the following chapter, we will start covering the top market cross-browser test automation frameworks: Selenium, Playwright, Cypress, and Puppeteer.