Opinion: Why the “Native vs. Web” contest doesn’t really exist

(Image Credit: iStockPhoto/BartekSzewczyk)

Web developers have suffered from debilitating cases of “app envy” by believing that GUI components traditionally used on native platforms represent the ideal, when instead they ought to be secure in the strengths of the web platform whilst honestly facing the challenges.

The truth is that “native vs. web” is a false dichotomy - the correct path to take for development is always dependent on the circumstances. In some cases developers will be wise to use both options, and the contest between native and web development is like arguing over whether to use a spoon or a fork.

Instead of trying to compare the proverbial apples to those proverbial oranges, it’s more valuable to think in terms of tradeoffs. Just as apples have more fiber and are nice, oranges have more vitamin C and will perform the job better if you’re trying to ward off scurvy. When considering native and web development, it’s best to go with the grain of the medium.

As Bruce Lee advised, “If nothing within you stays rigid, outward things will disclose themselves. Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle, and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.”

Native development has an edge when it comes to utilizing device features, offline access, performance, and user interface. Web shows its strength with discoverability, maintenance, platform independence, distribution, and lower development costs.

To better understand the web, think of it as a continuum of devices, capabilities, and constraints.

Strengths of the web (simplified):

-Ubiquity. The web is the most widely deployed runtime of any technology.

-Variability. This is not a constraint, but a feature of the web. Software for the web can display to a myriad of devices and resolutions.

Constraints of the web (also simplified!):

-Performance. This is limited by CPU (Webkit is faster than IE, but an iPhone 4S is equivalent in speed to IE8) and network speed (global broadband is growing, but the world’s infrastructure is still far behind - this makes for slow connections in such far-flung places as Equatorial Guinea, Bolivia, and, heck, even Boston.)

- Limited interface. Web users are only capable to the degree that they’re able to understand what’s on their screen and make sense of the controls. It is therefore the task of developers to make sure interactions are natural and easy no matter what devices and constraints are in play.

Constraints of the web have always been here, they’ve just been easier for developers to ignore when they are factors on someone else’s desktop. Developers lacking compassion might argue in defense of their software: “Well, the user should get a bigger monitor.” “Who uses a Core 2 Duo Processor anymore?” “Maybe they should get their eye-sight checked; this is the perfect size for text.” “People don’t use computers that way.”

The new reality of commonplace mobile devices has forced us developers to consider users outside of ourselves.

Mobile-First is a strategy for achieving device agnostic websites and web apps using responsive web design and progressive enhancement. With mobile-first design, developers guarantee that the software serves the harshest environment first. In this way, whether pursuing a path of native or web-based development, the software adapts to display beautifully and functionally on whatever device the user has to work with.

Do you agree that the “Native vs. Web” contest doesn’t really exist? Let us know in the comments.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.

17 Jun 2015, 1:59 p.m.

Good read, thank you! It's often exhausting to filter the noise from the actual correct thought process.
I agree that in some ways these two platforms serve difference priorities and should be considered in the context of the publisher. We see lots of sites who own great online properties squander resources in creating apps, when in fact it's their site that keeps drawing in both new and returning users, and their expensive apps generate little adoption.