Web applications provide many benefits. Most organizations seek to improve the efficiency and effectiveness of business processes through the use of software.

The benefits of web applications include:

  • Simple distribution model for end users (e.g. no installation required)
  • Instant propagation of changes
  • Unified code base to support many platforms (desktop, tablet, mobile, etc.)
  • Easy piloting of new features with a subset of users
  • Lower total cost of ownership
  • Well-established scalability models as user-base grows

Over the past few years, building the client-side portion of web applications has changed significantly. Web application development, while arguably better than any other platform available today, is not without its challenges. We categorize these issues as coming from three sources: technology, process, and people.

We thought it was a good opportunity to take a step back and look first at the challenges, and then the solutions for building modern web applications, and to share some of the strategies and techniques we use at SitePen to improve our approach.

In this installment, we’ll begin by looking at the challenges currently faced when building web applications.

Technology challenges

There are a number of technology challenges with the current web stack that occur when building ambitious applications.

Evolution and change

JavaScript and the associated standards came out of expediency 20 years ago. In the past, JavaScript was not seen as a first class language. It was great for doing simple animations or form validation, but it wasn’t thought of as a platform for developing “real” application. However, the last several years have brought about a realization of how much power JavaScript really can bring to a modern web application. As a result, JavaScript has received an immense amount of interest over the past few years. We now we have a community that is finally advancing the language, trying to a) keep up with evolving technology and b) bring significant features from other languages to JavaScript, which is what is leading to a lot of churn through the regular introduction of new libraries, toolkits, and frameworks, and the underlying language undergoing its biggest change in more than a decade with ES6.

Developers are now faced with the constant battle of staying current with these changes, and managing an environment where the foundation is moving underneath them. At times, it’s exhilarating, to see so much progress happening so quickly, whereas at other times, it’s frustrating as things you might assume are finished may still change.


The capabilities of web applications used to be fairly simple, but today a web application can be composed of hundreds of different technologies and approaches, and developers of large-scale, full stack applications need to understand far more than ever before. Beyond just understanding the programming language and available APIs, an understanding of network performance, rendering engines, and a wide range of new and emerging technologies and techniques is generally more than any one person can keep in their head at a given time.


Application source code is difficult to test if sections of the application are not easily separable. Code that is easy to test separately is also more likely to be easy to maintain and reuse.

Also, when an error with an application is reported, it often manifests itself in the front-end, so errors are almost always reported against the JavaScript development team. Having assurance about the front-end code makes it easier to quickly detect and isolate issues elsewhere in the application.

Furthermore, with so many different platforms and devices, the ease of automated testing is increasingly important.

Measuring quality

There are many different ways to measure quality of a codebase. These include but are not limited to code standards, performance, consistency, documentation, test coverage, efficiency, and comprehension. The challenge that faces many organizations is agreeing on a set of metrics and then sticking with them, and applying those standards as new engineers join the organization. The value of measuring quality is to gain confidence that what you’ve created will work as expected and be easy to maintain over time.

Tool selection: Marketing vs. quality

With a robust and growing ecosystem, there are lots of solutions to lots of problems. The challenge is determining if a solution can actually deliver. Often, the examples and demos of a technology over-simplify the use case and don’t really answer the critical questions. It’s far more challenging to measure how well an underlying technology will actually do under the constraints of your requirements, and assuming you have spent the time to learn how to use it effectively. Most proof of concepts stop short of this, and favor what a current group of engineers is most comfortable with or what is easiest to use, rather than what might be best for their long term goals and objectives.

Organization and process challenges

Beyond the technology decision-making process, organizations face a number of challenges related to process and methodology.


Many organizations have moved to more modern, engineering-led, development techniques like Agile, TDD/BDD, XP, Kanban, etc. This is in direct response to the waterfall method, which had the challenge of trying to solve every question in advance of development, leaving insufficient time to complete development, or resulting in development of features that did not meet the users’ needs once built. But the biggest challenge we find with agile is that many organizations eliminate most or all upfront thinking. And while agile can work with an environment where key decisions are made late in the development process, it can be difficult to leave enough time to refactor and improve the codebase to ensure it has a solid architecture.

Substantial changes to functionality may necessitate very different approaches to architecture. A typical agile methodology can lead to high levels of technical debt. It can also lead to rewriting the same feature many many times because the requirements and use cases were not sufficiently understood up front. Furthermore, deadlines often lead engineers to take short cuts at inopportune times, costing the organization even more in the long term through fixing more bugs and maintaining poor quality code over time.

In other words, teams often struggle to balance the need to be agile in response to short-term business objectives with the need to develop stable, maintainable and scalable applications that support longer-term requirements.

Simplicity and death by a million paper cuts

Simplicity does not precede complexity, but follows it. Alan Perlis

We are often asked why it is so difficult to build a web application that feels simple. One factor is what we describe as “death by a million paper cuts”. It’s rarely one insurmountable problem that makes web application development challenging. Rather, as our expectations continue to grow with application development, we find that the sheer number of details to track and remember is ever-increasing.

Paradox of choice

With a sometimes dizzying array of choices for everything, no one wants to make the wrong choice and pick a technology that is not right, or is later abandoned. One of the things we’ve learned with Dojo over the past 12+ years is that a flexible architecture makes it possible to delay or change your mind later on key dependencies, without having to throw away an application and its architecture regularly. Designing a truly flexible architecture up front allows you to make a choice now, and change your mind later, with minimal impact on your development.


The team that creates any application will face many technology and process challenges, but there may also be challenges with the team itself.

Quality and continuity

What determines that something is good or bad? Even the best engineers have bad days, and it is near impossible have an entirely effective A-Team. As mentioned during our Caveman Coder talk at FullStack 2015, we believe that an emphasis on reviewing and guaranteeing code quality across a team is the only way to prevent bad engineering practices from entering a code base.

Furthermore, the rate of turnover at some organizations is very high. This prevents long-term consistency around the way software is built at many large enterprises. It can also lead to each new team member second-guessing the technology and architectural decisions made previously. This problem can be even worse when relying on offshore teams, where some countries have a typical employee turnover rate of over 100% per year.

Scaling and collaborating across large teams

It can be a significant challenge to scale code bases across multiple teams. Whether it’s simply shared code libraries, or larger applications, there are many technological and organizational blockers to efficiently building up both institutional knowledge and a shared approach for consistency.


While we’ve started with all of the challenges, it’s not all doom and gloom as there are proven ways to address these issues.

In the next installment, we’ll look at some solutions, so we may move beyond the challenges of technology, process, and people, and focus on the benefits of building web applications.