Interview Peter Nielsen and Ole Gammelgaard.

Web vs Native

- Is there bad blood between the technologies?

At ColdFront 2015, the issue of ‘Web vs. Native’ came up several times. ConsultantNews decided to find out what all the fuss is about. Several blogs address issues like: ‘Do I need a native application, or can I get by with a web application?’ And because these are blogs written by either native app developers or web developers, naturally enough, their answers are colored by prejudices against the ‘competing’ technology. So we set up a meeting between native app developer Ole Gammelgaard from Shape and web app developer Peter Nielsen from Nordlys to chat about their views on advantages, disadvantages and prejudices - and to find out whether one of these technologies has the potential to outcompete the other.

An application is many things

A native application is an application that is primarily developed for smartphones and tablets (iPhone, Android, etc.) The code and design of the app are unique to the specific platform. A native app can utilize the functionalities of the platform to the maximum (camera, GPS, etc.)

A web application or web app is a website that functions in a platform’s browser. Web apps are designed to emulate native apps as precisely as possible, especially when they’re designed for smartphones and tablets. However, the possibility of using smartphone-specific functions varies from platform to platform. Web apps can also function in a browser on a PC or Mac, where users have a mouse and keyboard at their disposal.

Hybrid or shell apps are created when development takes place in a common language (such as HTML or JavaScript as for web applications), but are wrapped in a native ‘shell’ and installed in the same way as native apps. These apps then gain access to native functions on each platform through a shared library. But if the shell and the language are based on running on a built-in browser, shell apps can have some of the same performance as web apps, for example limits on speed.

User-friendliness depends on the specific user case.

It’s often said that native apps have sleeker user interfaces (UI) than web apps. So when we met one morning, one of the first topics on the table along with our coffee was the issue of the advantages of native app UIs. For Shape, this advantage is a selling point. CTO Ole Gammelgaard explains:

”A native application gives you a classy, well-designed feel that engages users much more than a web app. What’s more, native applications run more smoothly than web applications, where loading can take time, for example. On a native app, you’ve already installed the files you need to use, which speeds up loading times. It’s particularly important for an application to run smoothly, regardless of whether it’s a native app or a web app, because it’s a tool you use several times a week.”

A native app has the same ‘feel’ and is based on the same UI concepts as the programs that are pre-installed when you buy a smartphone, which means that native apps feel more natural and are easier to use. Native apps are often faster than mobile websites and shell applications, and the more quickly a user can complete a job with an app, the more likely it becomes that he’ll use it again and even save it to his home screen. Push messages are one of the best ways to engage and retain users.

Entrepreneur and web application developer Peter Nielsen weighs in to defend web app UIs:

”In the web application world, we put a lot of effort into making our applications as similar to native applications as possible,” says Peter Nielsen, and continues: ”What can make a web app feel clumsy is stuff like animations. But we optimize animations, loading times and so on, so the application runs smoothly and cleanly – including on a smartphone.”

When asked whether he believes that web technology can challenge native technology when it comes to creating great UI, Peter Nielsen responds:

”Absolutely. But it’s very much a question of the individual user case: if a client needs a heavy application with a lot of drag and drop, or a lot of gestures or rendering of heavy 3D elements, for example, it might be more fun to go native, because you’d get a bad user experience in a web application on a smartphone or tablet otherwise. But web apps function just fine on smartphones for things like showing users lists of data, for example Facebook’s web application.”

CSS3 opens up new possibilities for web apps

Animations in web application can be clumsy partly because of the limitations of the chosen JavaScript framework and partly because of limits on how quickly and smoothly JavaScript can update pages. CSS3 makes it possible to design animations and effects that are closer to native graphics, depending on how well the browser exploits the unit’s hardware.

A lot has happened with CSS animation since CSS2. CSS3 transitions brings simple, elegant animations to CSS classes, both in the form of smooth transitions between values and key frames that describe a sequence of effects or movements. The advantage of using CSS3 animation rather than animating with JavaScript is that this allows the browser to use native hardware rendering to produce more fluent animations, while JavaScript libraries can often place limits on how often JavaScript is allowed to run, especially on mobile devices, which can limit how often they can switch colors and locations. With CSS3, it’s now easy to create fluent animations and live in web applications.

Offline is not a problem

Another preconception about the advantages of native applications over web applications is that only native apps work even when users are offline. How can you get a web application to work in a browser with no internet connection? Peter Nielsen explains:

”There are already lots of good solutions for doing offline synchronization which involve working with what’s known as a cache manifest. You save all of your assets in the cache manifest. I’ve used a cache manifest in some web applications, and this means that they work offline. Where cache manifests can get difficult is when the developer needs to update his web app, because cache manifests are really heavy-duty cache storage: if you change the web application, the browser doesn’t pick up on it.”

Ole Gammelgaard asks whether making cache manifests is standard practice in web applications. According to Peter Nielsen, it’s not. He only uses this solution if a client asks for it. Ole Gammelgaard follows up:

”But doesn’t this solution add to the problem of making web applications slow to start up? Given that it has to retrieve this entire cache manifest – and that it has to retrieve all the files again if any changes are made?”

“There are new technologies that solve this problem. For example, at Nordlys, we make Meteor apps. Meteor is a full-stack JavaScript framework that really focusses on speed and which gives the app a really fast feel. Part of how Meteor does this is by packing all of your code into two files, which means that load times are almost non-existent. Another technology we work with is webpack, which can split up your code so that it doesn’t all load at the start, but instead waits until the application needs it. This approach reduces start-up times for web applications even more,” explains Peter Nielsen.

In addition to saving the web application itself offline, there are also open source projects like Hoodie that provide an API solution that hides the complexity of online/offline data by always saving and reading data locally and then automatically synchronizing it with online data when that becomes possible.

A question of user expectations

Ole Gammelgaard explains that offline synchronization has two aspects: On the one hand, there’s the purely technical issue of implementing code for offline sync. And on the other hand, we have user expectations:

”We do lot of work with user expectations when offline synchronization is on the agenda. To take just one example, it might be a to-do list that needs to work on multiple devices: On one device, an item is ticked off, while on another device, it gets deleted. What does the user expect in this situation? We typically review really specific situations with our client to find a solution.”

Native features

Native features are also used as an argument in favor of native apps over web apps. When a user installs an application on her smartphone or tablet, the app lets her use native features like the camera, GPS, camera roll, and so on – something you only have to do once, which gives a sense of an effortless application that is able to engage users. Peter Nielsen explains:

”The biggest problem with implementing native features in a browser is that the web developers still need to optimize for old browsers for pc and Android users. Internet Explorer in particular has lagged behind in the last few years: it’s like nothing works in the older versions of the browser. 

When it comes to hybrid applications for smartphones made in JavaScript, there are technologies that can give the developer plug-ins that enable access to the device’s native functions.”

It’s becoming increasingly common today for browsers to use a plug-in that enables access to the native features of different platforms. For example, you can make video and audio calls with the web application GoToMeetingFree, which uses an API solution called WebRTC, which is short for ‘web real-time-communication’. However, the web application doesn’t work in a smartphone browser. Why can’t smartphones support WebRTC?

”WebRTC is a relatively new web technology, so not many mobile browsers support it yet. But I believe this is on the way,” answers Ole Gammelgaard.

Web technology gives you editorial freedom and early prototypes

One of the areas in which web applications have clear advantages over native apps is in relation to updating code: Users can see updates immediately, which provides graphic and editorial freedom, as well as the freedom to add new functions. With a native application, each update of the app has to be approved by Apple’s App Review team before it’s released in App Store.

Android apps, however, don’t have to be approved by Google before becoming available in Play Store. Peter Nielsen explains about setting up prototypes:

”One of my prejudices in relation to native app development is that it takes longer to set up a prototype with native technology than with web technology. My thinking is that the latter is faster, because you have a lot of JavaScript libraries and open sources projects that can be used for setting up prototypes. While I’ve seen examples of native prototypes being shown to the client with a series of static screendumps, this doesn’t give the client a sense of what happens when the user clicks on a button or changes a view.”

Ole Gammelgaard agrees with Peter Nielsen’s point about developing prototypes, but he adds:

”It’s true that you can set up a prototype quickly using web technology, but in relation to UI, I still think that you’re missing the last ten percent in relation to achieving an application that works well. It’s hard to get that last ten percent using web technology alone. At Shape, we think that if you know that the goal is a native application, you might as well start with native technology and workflow.”

Native apps get new platforms

Ole Gammelgaard describes some of the kinds of projects Shape is involved in and predicts one trend in particular for 2016:

”At Shape, we didn’t just develop mobile applications in 2015. We also developed apps for other devices, for example Apple Watch and Google’s Wearables. What’s totally new is that you can also make applications for Apple TV, and that’s something we’ve also gotten into. So I believe that applications for other devices than smartphones and computers are at trend we’ll be seeing more of.” Ole Gammelgaard adds:

”When Apple launched the first iPhone, they explained that it was a mobile phone with a browser and email that you could have in your pocket. But today, we use our smartphones for so many other things than Apple had ever imagined. I believe that the same thing will happen with the new smart platforms (TVs and watches): some time will pass before the applications that will really change things will get invented.”

No changes in the near future

Right now, web applications are supported by an app for smartphones, and Peter Nielsen has trouble imaging that there will be any changes in this approach in the near future:

”But if the problems around UI get solved, and you can really get users to eel that they’re working in a native app browser on a phone, we’ll have come a long way. However, I don’t think that web applications will outcompete native apps completely, because the feel of native will always be a little nicer. But from a client’s perspective, it’s still a huge advantage not to have to develop for four different platforms (iOS, Android, Windows Phone and web), because that will always be a costly affair.”

Native or web apps for clients

So when do clients need a native application, and when do they need a web application?

”It’s still hard to say, but I believe that a client needs a native application if the application has the characteristics of being the kind of tool you use often,” says Ole Gammelgaard:

”Facebook is a good example, because social media run more trouble-free on a native application, where you get push messages coming in over the course of the day. Another advantage with native apps is that you can open the application, do what you want to do in fifteen seconds and then get out again. So native apps work really well on the go.”

“But it depends on what kind of tool it is,” comments Peter Nielsen. He goes on to explain:

”If it’s a tool with a lot of input fields, for example an accounting program, or a tool where you need to write a lot of text, I personally prefer to use a browser web app on a desktop. If you don’t need an app that’s super performance-heavy, I would always recommend a web app to my client. When all is said and done, I agree with Ole. It’s hard to say, because it always depends on the case, the client and the budget.”

Name: Peter Nielsen
Title: Co-founder of Nordlys (,
advocate of web applications


Education: Self-taught web and app developer

Background: Has been programming web technologies for fifteen years, backend as well as frontend. In 2007, started out as Art Director trainee at an ad agency and web developer; but his passion for code quickly surpassed his interest in design. Three year later, Peter Nielsen set up shop as a freelance web developer, and he’s been an independent contractor ever since. With the exception of the period 2012-15, when a working relationship with a digital bureau developed into a full-time employment contract. But the desire for the independence of the freelance life soon called, and he set off on his own again. 

After six months of freelance work and developing his client portfolio in spring of 2015, he founded Nordlys Studio ApS in partnership with his friend Rasmus Hjulskov.

Right now: Working on a desktop app. A dashboard for visualizing customer and employee metrics.

Nordlys focusses exclusively on modern web app technologies like ReactJS, Meteor.js and React Native.

Name: Ole Gammelgaard,
Title: CTO and Co-founder of Shape (, advocate of native applications

Age: 30

Education: MSc in electrical engineering from the Technical University of Denmark (2010).

Background: In 2009, towards the end of his degree programme, Ole Gammelgard and some friends started Shape. Their ambition: to develop the best mobile applications on the market. Shape employees new graduates of the engineering and computer science programmes at the leading technical and IT universities in Denmark. Today, Shape creates mobile apps and associated backend systems for major companies like Fitness World, Red Bull and Bang & Olufsen.

Right now: doing programming himself on top of his responsibilities as CTO
Even though Shape is a major advocate of native apps and technologies, the company does occasionally use web technologies to solve challenges for its clients.