How To Make The Web Great Again

5 Major Challenges Faced by Web Application Development Teams Today and Solutions to Solve Them Without Breaking Your Company’s IT Budget

The first challenge with web application development is Monoculture.

What is monoculture?

Even though there seem to be different approaches when it comes to developing web applications, companies are still focused on the main fundamental idea of shipping a web application to production while accounting for the scope of project, cost and time to deliver the scope.

Let’s look at the above triangle. 

When you increase the scope of a project, you either will need to increase the cost or project will not hit the deadline as it’ll take more time.

Thanks to agile development, software development teams are familiar with this fact. 

But let’s look at a different perspective outside of scope, cost and time. 

1. Performance i.e. your app’s technical performance i.e. scalability, for example.
2. User Experience (UX) i.e. how the user perceives the performance of your application.
3. Developer Experience (DX) i.e. how the developer feels with the tech stack used to build the application measured in terms of developer productivity, time to production, and subjective happiness or frustration of the developers.

The tech giants like Google, FB, AMZN, NFLX have a strong focus on application performance. Large companies have a huge amount of concurrent users so they have to navigate scalability and performance issues regularly.

But they also have lots of cash in the bank and they can hire more developers to fix the app’s performance. So DX is not as important for them.

But for the rest of us, it’s cost-effective to add a bigger server than add an additional head-count as a developer.

User Experience (UX) is another one that’s critical.

Companies love to evangelize their way of doing a thing — whether it’s design or development. 

98% of the time, that’s for recruitment purposes. But it also leads to developers drinking the cool-aid and they go — “React/Vue.JS/Angular etc is the right way to go.”

The problem is that most of your applications don’t have to scale to serve 1M+ concurrent users. 

For that kind of setup, there are different tradeoffs relevant to what big tech companies have.

So in order to address the challenge of monoculture, how about we:

- Optimize for DX first i.e. if there’s a choice between choosing something for increasing developer productivity versus optimizing for the server, choosing developer productivity could have greater long-term gains as it directly contributes to developers being happy and willing to stick around as they enjoy working on the tech stack.

Combining this with a framework that is built-in with good UX at its core, companies can get both, DX and UX without having to worry much about scalability from the get-go as there’s always one extra node you can add to your cluster.

The second challenge with web application development is Hype-Cycle.

Framework of the month — Angular, React, Vue, Flutter, etc.

Architecture of the year — SOA, Serverless, Microservices, etc.

As engineers, we like to use bleeding-edge technology. It makes us feel powerful and in control of keeping up with time.

But companies prefer stability. 

1. They want to build an app and then put it in maintenance and don’t want to have to update from Angular 1 to 2 to 3 every year.
2. Companies prefer to have minimal efforts to keep an application running. 
3. It also makes a lot of business sense to want to use the same tech stack for the next application in order to minimize training costs.

When Google builds an application, it explicitly plans to deprecate the stack at the end of 5 years. So when the time comes, they’re not refactoring or redesigning their app and prefer to start from scratch.

Another thing you end up with due to Hype-Cycle is the mashup of best practices. 

You pick the best template engine, best REST API Framework, best CSS pre-processor and then you integrate those because they’re all best practice. And we all know how complicated web development can become due to this mindset.

So what’s the solution?

Using an integrated solution. 

1. Focus on Web Standards. It doesn’t matter which message bus you want to use. When you use Web Components, it is agnostic of whether you’re using LitElement or Polymer 3 or React or built the interface using low-level JS/HTML stuff. 
2. Have an Integration Solution i.e. a full-stack solution that comes with a front-end framework, client-server communication layer, theming solution, set of web components based on web standards.

When you get the above open-source solution from a single vendor, you mitigate the risk of not having stability or incurring extra costs due to mash-up of different tech stack across your engineering team.

An additional advantage of choosing a vendor backed open-source solution is that when things break (and trust me it will) and it’s a critical situation where your CIO is up all night and having to scream at people on the phone — you can reach out to experts who’ve built the technology you’re using and get it fixed with an SLA versus letting your developers post on SOF and hope a community member comes and saves the day.

JavaScript: That’s the 3rd challenge with web application development today. 

Why?

Because it’s doing something totally different from what it was designed for.

Sir Charles Anthony Richard Hoare is a British computer scientist who calls his invention of the null reference back in 1965 as a billion-dollar mistake.

But programming languages started to copy it as well and the fact that JS doesn’t have 1 kind of null references but 2 different ones, could JS be a 2b mistake?

What’s happening is that — JS isn’t used for what it was designed for.

Back in 1995, 1996 — when both Java and JS were relased by Sun Microsystems and Netscape respectively, the plan in collaboration was that Jave would be universal app for building complex things but there’ll be JS for building smaller scripting kind of things.

Today, Java has become write once, read everywhere. But they’re also using JS as a virtual machine similar to Java byte code.

They write an app in other languages and then at compile time it’s translated into JS. One of the biggest reasons for this solution is to get static type-safety.

Why have static type-safe code from your client to server-side logic?

1. Static typing often serves as documentation. When you have explicitly defined types in your code, it makes it much easier for someone who’s not familiar with that code to still know what it does.
2. Static typing also helps to use the compiler to make better optimization like dead code elimination and inlining things. So, the only thing you’re actually using ends up in compiled JS.

Type safety is business-critical when you’re building a huge Enterprise application with lots of developers coming and leaving but you want the code to be optimized for end-users. 

So what’s the solution?

• Using static typing both, in the client-side and server-side logic. For example, TypeScript in FE and Java in BE.

The 4th challenge is around Client-Server Communication.

Yes, project managers face their own set of communication challenges during the SDLC. 

But an even more critical challenge is how the client and server communicate with each other.

The big challenge is that we have a process boundary. We have different things that are separate with latency between them.

We have to do things in a synchronous way. We have to do an optimistic update which comes with its own set of challenges you have to solve.

Latency makes it even longer. If you have infinite latency and you have an offline situation, you have to deal with problems of how to keep things in sync.

How do you ensure when users return online, things are put into the database and conflicts are resolved?

It also causes a language barrier. 

What you typically have is that you have Java or C# on the server and on the client, you have JS. 

There’s the alternative of using NodeJS on the server or GWT on the client that gives you Java everywhere. 

Different programming languages come with separate code bases so there’s the difficulty of having shared validation rules or shared constants.

So you end up duplicating things or doing it in a not so optimal way.

When it comes to the web, the question for communication is —  do we use REST or GraphQL? 

Both of these are for the use-case when you have front-end team doing FE and back-end team doing BE and the interaction between them is the communication layer.

REST requires you to define what the client and the server will do.

GraphQL gives slightly more power to FE teams but you still have a hard boundary between the client and the server

Communication is difficult enough without having to add this encapsulation layer.

So what’s the solution?

Transparent communication from encapsulation between front-end and back-end. 

What if the front-end team is also doing server-side part of the communication which has a thin layer that talks to the business logic. 

In doing this way, you separate 2 complex things — encapsulation and overall communication challenge and helps to do things in a smoother way.

By tightly coupling your FE and BE in your client-server communication layer, it lets you avoid all those problems like not being able to share constants and shared validation rules, etc.

Mobile: The last of the major challenges with web application development today.

In theory, you should just do mobile-first and everything will be awesome.

Why?

In many cases, you still need to do native apps. Because mobile-first web app won’t be good enough

What you end with is multiple clients with different codebases — 

1. Web for Desktop
2. iOS for iPhone
3. Android 

3 separate code bases (i.e. web, iOS, Android) also add up the development costs.

What you want is a single code base so that you change things once when there’s a business requirement or when you have to fix bugs.

Another challenge with mobile-first app development is how to deal with offline functionalities. 

In addition to the synchronization of data problem, you have the additional problem of how to cache static asset so that your app can be truly offline.

So what’s the solution?

Progressive Web Applications (PWA). 

Maybe it’s still a buzzword today. 

But the reason it will stick is that it’s the 3rd iteration by Google. 

Based on Google’s record, the 1st and 2nd time they build something, it’s not really good because they’re themselves learning what to keep in mind but the 3rd time is often a home run.

Google’s 1st iteration with mobile app development was the same as everybody else does i.e. separate web, ios, and Android clients.

Their 2nd iteration was — do as much as possible in Java. Android clients natively running java and web client using GWT to compile Java into JS. 

Google has a similar solution for compiling Java into iOS clients. Much of the client-side logic can be implemented in the same codebase. But they’d be doing UI in respective native tech for each stack.

Google’s 3rd iteration is PWA.

The Big Idea

 — Turn the problem upside down. What if we don’t need a native client by making the web browser strong that makes it easier to deal with caching of the static asset.

So there you have it. 

The above are the 5 challenges based on our experience here at Vaadin helping companies with their business web application development needs and how we’re navigating it. 

Whether you’re a web app developer, architect, or engineering leader responsible for ensuring the business goals are met when selecting the tech stack for your team, what is your #1 single biggest challenge when it comes to building business web applications based on your current team dynamics? Share your thoughts below in comments.