I don't think "web apps" are as problematic today than they were several years ago. I don't say this because I hope web apps will be the future of app development, but because together with a few other devs we have built such an app at the company I work for. I think the result is a success but unfortunately I didn’t have enough time to write about our experience yet. I hope I will have the time to so anytime soon.
Yes the development costs are super important, especially for small companies / startups. As important is the performance of your app(s) and also super important is the usability of such an app. If the development costs are much higher than building native apps besides your website, then you failed. If your app is slow and unresponsive then you failed. If your users dislike the app because it is not smooth like a native app and feels sluggish then you failed.
But does this mean that building mobile web apps is impossible, I don’t think so. We did several things that helped us to keep the costs as low as possible and for sure much lower than if we would have written server, apps and client code using different languages / frameworks and libraries.
Our server side code, the code of our web apps as well as (obviously) our client (browser) code are written in javascript. We have used typescript to write all our code, this allowed us to use the latest ES6 features and gave us features like strict typing. The ES6 features we have most used are promises and classes. Typescript compiles our ES6 code into ES5 UMD modules. We choosed Visual Studio as IDE as it compiles typescript on the fly, which allowed as to quickly test new code almost in real time. We also used the node js tools for visual studio which allowed us to use the node js debugger from within our IDE. Setting breakpoints (typescript creates Javascript to TypeScript source maps), reading stack traces or watching variables was a piece of cake.
We have built an isomorphic website first. Our server side got built on top of express js (node js). All our modules and libraries are UMD modules, which means that more than 95% of the code we wrote is the same that we use on the server and in the client. We have built a server views renderer using Backbone and domino. Our collections and models are the same on the server and in the client, the only difference are the adapters we wrote to make ajax or server side requests. We use the same router on the server and in the client, which means the first page that gets served is always built on the server but the next pages are built in the client. This also means that crawlers can harvest our pages but for users we only retrieve the data needed to build the pages from server and do all other work in the client, which makes the pages load very quickly. We also had to write a cache library once, the only difference again are their adapters, the server adapter of our caching library saves objects into redis while our client adapter saves them in IndexedDB. A lot of things needed to built the pages get cached too, so each template, each translation and so on only needs to get fetched once by the client and can be reused until we publish an updated version of the item.
Our web apps are built using phonegap. Again 95% of the code of our apps is the same as the code that is being used by the client (browsers). Obviously we had to write clean and powerful code to ensure that our apps come as close as possible to the speed that people expect from a native app. We had to track every minor memory leak, especially those that occur when binding events to ensure that our apps use a minimum of memory. This was not only important for the web apps but also for the node js code. A memory leak is something you really don’t want to have when writing a nodejs app ;).
I think what helped us to keep the costs low, was that we used the same language and therefore resulting code for the client, server and apps. But this did not only allow us to work quickly, it will also allow us to add new features quickly in the future. If we now write a new feature, as soon as we release it, it will be available to users that use our website as well as users that are using our Android / iOS apps either on their phone or tablet. The same is true for bugs, if we find a bug in the client and fix it, it will be fixed for all our platforms.
The other big advantage was that all the know-how we had but especially the one we acquired during the time we needed to build our project did benefit all our platforms. We didn’t have to optimize our Java code for Android our Objective-C or Swift code for iOS and our PHP, Ruby or .Net code for the server. We just needed to optimize our Javascript code. We reduced the amount of platform / language specific problems to a minimum. It is really great when all your devs use (speak) the same language ;).