You are here: Home / The Mobile Web / Mobile JavaScript Apps - The Problem with the Mobile Web

Mobile JavaScript Apps - The Problem with the Mobile Web

mobile-javascript-apps

Creating an amazing mobile experience has become the holy grail for JavaScript developers in recent years.

This is somewhat frustrating for web developers. We never had our day in the in sun.

Just as we finally started to feel cozy around desktop browsers, the smartphone market exploded.

We now faced slew of of new mobile browsers we had to deal with. These mobile browsers had far less processing power than their desktop counterparts. And they added new things we had to deal with like “gestures” and “touch events.”

But life goes on. And we adapted to the mobile web.

We switched from cursing at IE8 to cursing at the Android Stock Browser. We spent days optimizing performance and user experience, dreading the most feared enemy of all. The page reflow. We still do.

We now mumble silently whenever someone mentions ServiceWorkers. We pray it’ll soon come to Safari so we can actually use it. Together with getUserMedia.

Safari has become the new Internet Explorer. The only major browser that still only receives major updates yearly.

But the mobile web isn’t enough. As JavaScript developers want to go to the one place that closed off to us. The App Store.

We want to bask in the App Store glory. Turn our genius idea into the next number one App Store hit. But we wanted to do it on our terms, written in JavaScript.

We thought it would be easy.

“Just stick a browser in there” we said. The web will do the rest.

We were wrong.

The Problem with Mobile Web Apps

As engineers, we know that before solving a problem we must first understand it thoroughly.

Mobile web apps, and especially hybrid mobile apps, have their fair share of problems.

The mobile web is not native. And it’s not going to match the native app experience in certain key aspects. At least for the foreseeable future.

We can concede defeat at this point.

But the term “mobile web apps” is too wide to discuss here as one entity.

For example, there’s very little in common between this WordPress blog, Facebook’s mobile web app, and an Ionic hybrid mobile app.

So let’s break the mobile web into three categories. I’ll also assign each category a difficulty level based off of how hard I think it is to create something decent in that category.

1. Mobile Websites

This is your friendly informational website. It’s your company’s website, News websites and this blog. The vast majority of the web is made up of websites, including the mobile web.

Mobile websites are characterized by having very little interactivity involved. You can navigate around and read articles. You might be asked share a page and submit a form like “Request a quote” or “Signup for our weekly newsletter.

But that’s about it.

Difficulty Level: Medium

I’m going to go on a limb and say that for the most part, we got these nailed down. Competent developers can create great mobile websites. And do so with a medium amount of effort.

In fact, most of the issues facing mobile websites are self inflicted wounds.

I’m talking about the gazillion analytics/ad scripts these sites use that end up hurting performance. And the million annoying popups, fixed sharing toolbars and fixed headers that fill the already small mobile view.

But when we remove all the clutter so many websites inflict on your helpless mobile browser, we end up with a pretty great experience. That’s why ad-blockers are so mainstream right now.

Mobile JavaScript Adblock Hipster

I’d like to take this moment and point out that I used ad-blockers before it was cool.

2. Mobile Web App

Mobile Web Apps are a subset of mobile websites.

These are the mobile versions of Twitter, GoDaddy, and Udemy.

Mobile Web Apps are based on user engagement. Whether it’s tweeting, buying a domain, or purchasing and then watching an online video course.

The difference between mobile web apps and mobile websites is purely semantic. I’m sure that 5 different people will have 5 different definitions of what exactly the differences is.

For sanity’s sake, we’ll use this definition: A mobile web app’s main goal is to enable interaction, user engagement and allowing the user to perform different actions.

Difficulty Level: Hard

It’s hard to create great mobile web apps. I’m sure that if you ask the team behind the new mobile.twitter.com they’ll tell you it was no cakewalk. Same goes for m.facebook.com.

I’m using those two as examples for great, borderline awesome mobile web apps.

But Some of you might be twitching your noses uneasily when reading this. Because when you compare these two great examples to their native app counterparts, they kinda suck.

And you’re right.

A few years ago, the entire web dev community was outraged when Mark Zuckerberg infamously stated: “The biggest mistake we made as a company was betting too much on HTML5 as opposed to native.”

You see up until that point, Facebook’s mobile apps in the App Store/Google Play were essentially mobile web apps stuck inside a native wrapper. We’ll deep dive into that type of beast in just a moment.

But the reason I think Mark was so dramatic about this “mistake” is simple: His belief in the mobile web was so strong that it took him far too long to realize he was hurting Facebook’s user experience.

And if a user doesn’t have a great experience on Facebook, they won’t come back to Facebook. Which would be a problem for Mark.

Mobile Web Apps are Hard Even for Google

When we think about web innovation, and “moving the web forward,” the name Google often comes to mind.

And with good reason.

Google and its employees have done a tremendous job at pushing the web forward.

This is at least in part because Google’s main revenue stream is tightly coupled with the web. The more time you and I spend on the web, the more likely we are to click on a Google Ad.

That’s why it’s no coincidence that web rockstars like Addy Osmani, Jake Archibald, and Paul Irish all work at Google. Normal people have the Kardashians, we have them 😉.

But Google doesn’t fare any better any better than the rest of us mere mortals with its own products. At least when it comes to the mobile web.

During the recent Google I/O we’ve seen a lot of hype regarding progressive web apps, using the web platform and all of that.

Keeping that in mind I invite to try and visit the mobile web versions of flagship Google products such as Gmail, Google Inbox, Google Photos and Google Calendar.

You’ll be unpleasantly surprised to be greeted by something Google calls “App Download Interstitials.” This term loosely translates to: “An annoying modal window that covers the entire screen and invites to download the native app version of a website.”

The only reason I even know the term “App Download Interstitial” is because I found it under the common mistakes section in Google’s own mobile web guidelines.

Yes, Google is actually violating its own mobile web guidelines in several of its flagship web apps.

I can only assume Google does this since it believes its mobile web apps don’t come close to matching their native counterparts user. Both in user experience and functionality.

Google Inbox flat-out doesn’t even have a mobile web version. They didn’t even try.

Priceless.

3. Hybrid Mobile App

We now arrive at the final frontier. The promised land. The land of the App Store.

The two previous categories were both accessible from any browser. This last one isn’t. That’s why a lot of people don’t even consider it part of the mobile web.

Hybrid mobile apps are our attempt at reaching the closed garden of the App Store.

The way this works is simple: Both iOS and Android have something called a WebView component which allows you to render web pages. Think of it as Chrome minus the tabs, url bar and everything else that isn’t part of the browser’s viewport. This component is only the part that actually renders the web page.

Here are the basic steps to create a hybrid mobile app:

  1. Create a WebView UI component inside your mobile app.
  2. Make it the main and usually the only native UI component. It should appear immediately after startup.
  3. Direct the WebView url to your mobile web app. This could be a remote url or an html file that’s embedded inside the mobile app.
  4. Victory!!!

But is it really a victory?

Difficulty Level: Insane

As I mentioned earlier, building decent mobile web apps is hard work.

Building great hybrid mobile apps is insanely hard work.

By creating a hybrid mobile app we’ve taken all of the complexity of a mobile web app and added a new equally complex layer on top of it. This layer includes the native app’s behavior and functionality.

On top of the added complexity, we’ve also significantly changed our user’s expectations. Users will no longer expect a “web experience” but a “native experience” instead.

Every time your hybrid mobile app won’t behave exactly like its native counterpart your end user will feel somethings wrong and “behaves weird.” This means we’re sort of setting ourselves for failure before the first line of code was written.

It’s also by definition a hack. Since no one ever intended for us to create apps this way. But the Cordova framework did a great job at bridging the gap between the WebView and native code. So we gave it a try.

I’m now going to share with you something now that I’ve learned over the last 3 years working on a hybrid mobile app. Something PhoneGap, Ionic or any other hybrid app evangelist will fail to mention:

Building hybrid mobile apps will require triple the effort and triple the developer proficiency to achieve the same or slightly worse results than their native counterparts.

There’s so much native developers “get for free” and so many workarounds & hacks required to make this whole thing work. After all of that, the end result still isn’t what I would call “show off worthy.”

That’s why I have to say the investment in hybrid mobile apps just isn’t worth it. At least not for consumer apps.

Enterprise Mobility: The Saving Grace of the Hybrid Mobile App

There’s only one place where going down the hybrid app path makes sense: The Enterprise™.

When you create a custom enterprise app you know the user can’t just go to the app store and choose between 7 different apps that do the exact same thing.

Only your app will be fulfilling that specific function. And supporting both iOS and Android from launch is crucial. Having a web version is an added bonus too.

Enterprise users still set a high bar when it comes to mobile user experience. But you don’t have to wow or dazzle them. And you’ll usually end up enabling functionality that was only available on the desktop up until that point.

For these reasons and a few more I won’t get into, hybrid mobile apps found great success in the enterprise.

But little success anywhere else.

Is There Any Hope for Mobile JavaScript Apps?

In the long term, there’s always the chance that what I like to call “The Prophecy” will be fulfilled. Something JavaScript developers have been dreaming about for years.

The Prophecy foretells that one day the browser will rule the mobile platform. Just it does with the desktop. You’ll only have a handful of apps, and use the browser for everything else.

Us JavaScript developers used to believe that The Prophecy will be fulfilled by “The Annotated One”: A third mobile platform that’ll gain at least 20% market share. This, in turn, would make native app development prohibitively expensive ushering in a mobile web utopia.

With the looming death of Windows Phone, The Prophecy now seems farther than ever.

But there is hope!

A different breed of JavaScript mobile frameworks has come to maturity. These mobile frameworks use JavaScript runtimes but aren’t browser based.

Instead, frameworks such as React Native and NativeScript let you write JavaScript code while rendering native UI components. It sounds amazing, and it is.

But there’s a growing debate in the JavaScript community whether these frameworks are generally a good thing.

Are these frameworks doing more bad than good by bypassing the web platform entirely? Or perhaps they’re the mobile JavaScript heroes we’ve all been waiting for.

This article part 1 of a 2 part series. Click here for part 2.