loading...

Native or browser based applications?

martin profile image Martin Beentjes ・2 min read

A lot of applications used today are based upon a browser based technology like Electron. Spotify transitioned from a native application to a browser based application. Spotify did this based upon there Microservice culture.

I have been wondering today about the need of this type of software. Do we prefer a browser based desktop application instead of a native application? If we look at Atom and Sublime Text for example. Atom is an Electron app where Sublime Text is native.

When opening big files in Atom, you really see how slow it can be. Yes it seems they are working on the speed. But Sublime Text does read big files a bit quicker.

Regarding the size of an Electron application vs a native applications, I just cloned the electron-boilerplate repository. Then I used electron-packager to build it into an executable. That thing is 125MB. That is HUGE for just a sort of Hello World application.

So far, native is winning in my opinion regarding the performance and size. Let's look at some other points.

As Electron is a browser based stack, we can working in programming language for the web. That is a plus, many web developer now can work on Desktop applications as well. So then I can make cross platform applications with just one language stack.

If I want to make a native application, I probably go with something like C++. I think that is the best option to go native and cross platform. But C++ is a language which is very hard to master. Yet, the Hello World application is not 125MB.

Then, when I would actually work on an application in C++, I need a GUI framework. That is not that big of a deal. But what I want to make a nice fancy material design GUI? Good luck with that.

So, if I take a look it is hard to decide what is better. I wanted to start this discussion, what do you prefer? Or would you leave a Desktop application a side?

Posted on by:

martin profile

Martin Beentjes

@martin

Martin is an enthusiastic software engineer building and operating microservices in the JVM stack using Kotlin. Currently working for Albert Heijn in the role of DevOps engineer.

Discussion

pic
Editor guide
 

These days, with all the excellent web frameworks out there, I don't know why you'd build native. The only argument I've heard is performance, but that is surely only an edge case?

Building native means you have to worry about target platforms, and in most places, this is a moving target with people installing all sort of crap on their desktops, and results in DLL hell.

 

Common argument around mobile.

There are so many web-frameworks out there that let you get a product out quickly, for both platforms, with little learning curve. Which is great.. I agree.

But native is a better experience. Native provides more control over behaviors, custom fits & finishes (and to repeat what you said about performance).

Here's my take:
Both have their audiences, but I will always choose native. In my experience, web-frameworks allow you to get up and running and get the bulk of the app coded in less time, which is overall great. But it fails dramatically at debugging and fit & finishes. With mobile, you also have a lot of pain when implementing a web app with the OS's hardware, Bluetooth, or Camera.. etc.

The argument will always end with "it depends on the company and the product your building". We might build a form-based app in web, but our beacon-tracking app will always be native.

End rant. :P