By Gavin Bridgeman
What platform should I build my next-generation engineering application (app) on–web (HTML & JavaScript) or native (C++)? This is a question I hear over and over from development managers looking to their next-generation applications.
The web versus native question is an interesting one—but maybe developers are asking themselves the wrong question. Maybe the answer to “what development path should I take?” matters less than the answer to “what do I want my app to do?”
To provide a little context around this matter, it is helpful to take a quick look back at how web and native have evolved in recent years and what the current landscape looks like.
Web Apps Emerge
From a technology perspective, one of the most exciting developments of the last five years was the emergence of the browser as a viable platform for delivering engineering applications. While the Web 2.0 movement revolutionized the software industry in the early 2000s, the engineering community was left on the sidelines due to the lack of 3D support in the browser.
Then along came the Khronos Group, who proposed making OpenGL available in JavaScript. They called it WebGL, and Google jumped on board and made WebGL part of its Chrome browser. Apple, Firefox, and Microsoft followed suit, and suddenly it was Game On. Advanced 3D apps could be built for the browser using OpenGL, which was—and still is—the most pervasive 3D API in the engineering world.
Best of all, web apps allowed developers to essentially develop for one platform—the web browser—and know that their application was going to work on any device, providing a “write once, run anywhere” benefit.
Couldn’t be better, right? And, full-featured engineering web apps remain a rarity. Why?
Native Stays Strong
There are several reasons why web-apps didn’t sweep the engineering software realm.
For starters, at the same time that OpenGL developments were occurring, the mobile world was exploding. People were using their phones/tablets in a professional context, and these devices came with powerful CPUs and GPUs, which were comparable to desktops from the not too distant past.
Although mobile devices included WebGL-powered browsers, the approach for application delivery was native apps delivered through app Stores, such as the Apple App Store or the Google Play Store. And these native apps, which were now available via a few taps on a screen, provided something web apps couldn’t—performance. Building an application on top of a browser abstracts you from the hardware, which ultimately limits the tools you can use to maximize performance.
If there’s one thing that we’ve seen in the engineering software market, it’s that customers are very focused on the fundamentals—things like performance—so it’s no wonder that these customers would gravitate towards native apps.
Better yet, users don’t even need a desktop machine to tap into that high-performance experience, as heavy-duty tablets like the iPad Pro and Google Pixel C have come to market. As these types of devices become even more capable—and even more prevalent—over the next two to three years, it’s easy to imagine that increasing numbers of developers will choose to build native applications and go onto the mobile app platform.
Another key reason why native apps are popular—even as web apps have become a viable option—is that the leap to a native app is much easier than the leap to the browser. You can still use C++ and have an architecture that mirrors your desktop app. Web apps, on the other hand, require you to use HTML and JavaScript and completely rethink your application in a client-server paradigm.
An Attractive Proposition
All of these points make native development on mobile an attractive proposition. Historically, the major downside of this approach was that you needed to build for two separate operating systems—three if you count Windows, each with their own programming language. But even on this front, things are becoming easier—the Microsoft integration of Xamarin into Visual Studio offers a lot of promise for simplifying development by providing a unified development environment across iOS and Android.
Another point in favor of native, since apps on mobile are written in C++, you can leverage much of the core technology you developed for the desktop. This is no small matter for organizations that have large investments in C++ code that they have been refining for years.
As big companies look at developing their next generations of software and seek to bring their legacy code into the current time, they might just “leapfrog” over web apps and go straight to building a powerful native application, much the way developing countries “leapfrogged” over the cost of landline infrastructure by going straight to cellphone towers.
Asking Questions, Finding Answers
So, what do these various developments with web and native mean for today’s developers?
While web apps remain a viable option, native apps have—to a large degree—chipped away at the advantages they once enjoyed while providing performance advantages that are all their own. On top of this, the distinction between web and native is not as clear-cut as it used to be, thanks to the emergence of a third, hybrid class of apps that we might call “connected applications,” web apps that store data locally, native apps that connect to data in the cloud, and so on.
With this in mind, let’s get back to the question of what platform the next generation of engineering applications will be built on. This issue needs to be looked at from a different perspective. The main question is not if you should be developing for a browser or an app store.
Instead, take a step back and ask yourself what you want your apps to do, and what data they need to connect to. How can you make your data more accessible, and how can you build useful functionality around it that is tailored to the device and the context that data is used in? In short, what does getting your data and IP up in the cloud mean to you and your customers, and how can you best work with it?
If you look at Microsoft with Office360 or Adobe with the Creative Cloud, this is exactly what they are doing. And if you look a little closer to home, you can see this is just what Autodesk is doing with their Forge platform.
Once you answer these larger questions—and only then—you can start answering the question of whether your app should be native or web. My guess is that for best results, you will most likely need both. SW
Gavin Bridgeman is VP of products at Tech Soft 3D.
Feb2017, Software Magazine
