I dabbled w/ Cordova and friends before, and did some work to wrap webapps in thin native shells earlier on, but there was always a very strict separation between the "sandboxed" webapp and the native code, if any.

Webapps can and do work just fine for CRUD applications, but right now, I'm of the opinion that if you want to really leverage the hardware APIs or the native ecosystem, you're better off learning the native platform, because you get no syntax mismatch friction on Stack Overflow etc, compared to Xamarin / React Native / Ambly / whatever

Also, this opinion might be unpopular among the js devs who like lightweight text editors (disclaimer: I'm one), but the heavy IDEs for Java/ObjC/Swift are actually immensely useful once you get familiar w/ their features. The static typing provided by those languages helps a lot in large refactors, in API discoverability/autocompletion and in reasoning about the codebase in general.

Personally, I see little to no disadvantage with using these particular types of tools, especially if it means you can use languages like Scala, C#, and F# instead of Objective-C and Java.

Are there complex apps built using phonegap/swift/cordova? What are the limitations? I know Facebook tried with a 'web app' approach and reverted back to native solution. But that was years ago.

    > This not a big deal when pushing layout around a webpage, 
    > but it can be crippling for app development as the app 
    > grows in complexity and you crave native-quality 
    > interactions 

I realize people really like the theoretical write-once behavior that you get for simple apps when using a javascript platform, but I've been waiting for years for web-based interactions to provide native quality - and I begin to suspect we'll never get there.

If you want native-quality interactions, the only solution is a native application and not common tooling via a javascript layer that runs atop the already not-as-performant-for-UI browser level. This makes your life harder as a developer, but gives your users the best possible experience for their platform.

Alternatively, if you're willing to give your users a good-but-less-than-native-quality experience, that's the niche filled by those tools.

My hacker news app is a hybrid app. Available on iOS/Android/Windows/Mac and web, and I harldy see any one compalining about not being native.

There are some legit issues and peole think only way to fix is go native. Only reason I have not fixed those issues because I don’t have time, or I don’t use that functinality.

1. I get an error message "Unable to load xxxx" at times (forgot the exact message) and the app closes.

2. If I switch between article/comments it always reloads

3. At times clicking on the comments icon doesn't work when you are in article mode.

4. I can't long press on links in comments to share it to browser/pocket etc

Compared to reddit apps like Relay, the HN app does feel much more basic.

Honestly I used to believe this, but not after the release of the iPhone 5 and 6. Though there is no perceptible difference, it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions, so most apps just use the default web technology which include things like a built-in 300ms delay, no response to clicking a link, etc.

Which is already done for you in Ionic -- including disabling the 300ms delay.

However, what's even sadder to me is the fact this continues to be true despite the fact that, believe it or not, the web has been the platform where most of the innovation in UI development paradigms has been taking place in the past few years. And I don't just mean in terms of the sheer number of new things coming out.

The web community pioneered UI development paradigms involving functional programming techniques and immutable data, and have brought its benefits to other platforms (through projects like React Native). I personally would never want to go back to the old way of building UIs. And I suspect I'll feel the same way about client-centric data fetching when I get to try out Relay/GraphQL, Falcor, Om Next, etc in production.

I really want Firefox OS to be successful for this exact reason. I don't want to have to make compromises between the best experience for my users and the best experience for myself as a developer. With a platform that makes web the native UI technology, we shouldn't have to make this compromise in theory, but Firefox OS's execution thus far has left much to be desired.

As someone with lots of native UI experience, that has to occasionally support web projects, the web is just plain clunky and playing catch up with the RAD tooling we enjoy since the mid-90 on native platforms.

https://github.com/gaearon/babel-plugin-react-transform/

http://gaearon.github.io/react-hot-loader/

https://github.com/bhauman/lein-figwheel

https://zeroturnaround.com/software/jrebel-for-android/

It's a pretty amazing technical feat that this works at all, but I have a hard time imagining this would work well in practice for changes to anything other than maybe method bodies and templates though. Java's style of object orientation generally means there's plenty of tight-coupling between application state and operations on the application state, which would probably make life very difficult for any hot-reload implementation.

But regardless, it does exist and apparently works well for a lot of people. It looks like I was just ignorant when it comes to native tooling.

Only one way to find out tho :) Trying it out for oneself.

I believe I used something similar called fam in the 90's but that may have only been on SGI.

These new hot reload implementation allows your app to be reloaded with your new changes without affecting the state of the application, and is not practical unless your application has been developed with a focus on functional techniques and careful management of application state.

This probably doesn't sound like a significant difference, but in practice, it is a huge boost to productivity, especially in a non-trivial app where reloading the entire app and then reproducing the app state manually with every file change can become quite tedious.

  * CHANGE-CLASS (change the class of an object to a different class),
  * update-instance-for-different-class (updating the object after a class change, one can provide methods which will be lazily called when needed),
  * update-instance-for-redefined-class (updating the object after redefining a class, one can provide methods which will be lazily called when needed),
  * LOAD (load source or machine code),
  * EVAL (eval expressions)
  * COMPILE (compile code in memory to memory), ...

Hey cool, I can change these classes live!

Let's solve this tricky problem by changing the class at runtime. Cool, it works, now on to the next problem.

2 years later...

What's causing this super-weird bug? It's like the code isn't doing what it says at all.

1 week of debugging and head-banging later...

Oooh, something got screwed up in that runtime class change code. Fixed.

2 years later, repeat...

In the types of apps I think we're talking about, typically most state is in the database and not much is going on in the client.

Or designing GUIs WYSIWYG with Delphi, XAML with Blend, the UNIX 4GL in the 90?

Tooling for web development has probably been heavily inspired by the tooling available for CL and Smalltalk, but I don't think it's fair to say it's still playing catch up. The tooling ecosystem for the web has long since caught up to the best native ever had to offer, and is now advancing the state of the art faster than any other tooling ecosystem out there today.

Along with other things such as the app manifest, Chrome on Android is leading the pack in terms of making the mobile web feel native. Previously this title belonged to iOS Safari, unfortunately Apple dropped the ball a long time ago.

I've been a long time Firefox user and I'm using Firefox on Android as well. But I do think they could do a better job, I mean I'm all for Firefox OS and what that means for Mozilla, but I feel their Android effort is subpar and that's a shame, given that Android is the modern Windows and there's plenty of room for Firefox on it. I mean right now Firefox is the only app I have that wasn't updated for the material design guidelines and they didn't even try to fake it. And that would be OK, but I've been waiting for things to get fixed ever since forever, like the Add to Homescreen functionality which is completely broken.

But anyway, people that bemoan web interfaces are usually ignorant of present day web interfaces that people use.

You can't name an email client that's more usable than GMail's web interface. And surprisingly FastMail on a mobile browser is almost as usable as native GMail, being all web. Facebook and Google Maps are 2 other example of having awesome mobile web interfaces. Of course, people focus on shiny rather than utility. But I don't care how usable or shiny your iMessenger or your FaceTime is, because I don't own an iOS device, not anymore. And your native app might be great, but if it doesn't have a web presence, I personally don't care much about it because I change devices often.

I won't use the full client because it eats my battery, and they separated the messenger interface requiring yet another app with battery eating features.

React Native and NativeScript seem to have all the upside of Cordova (transference of web dev skills to native platforms) with none of the downsides (lag in new OS feature implementation, webview wrapped apps), I wonder if Cordova's days of relevance are numbered.

http://blog.ionic.io/built-with-ionic-sworkit/

I did a pet project using the vibration feature and it worked pretty well, but haven't tried on an iphone.

I can't speak for pushing the limits of the hardware though.

I have ran into some roadblocks that required stepping into native development to fix up issues with Cordova Plugins (specifically for background operation), but I suspect that won't be necessary for a large majority of apps out there.

Personally, I find the Hosted Web App spec a very promising alternative to Cordova for app development with web technologies. You simply use the open web APIs (notifications, geolocation, camera, etc) for features that would normally require messing with plugins in Cordova, and they would just work.

https://developer.mozilla.org/en-US/Marketplace/Options/Host...

It's such a shame that the biggest players (Android and iOS) probably have no plans to support it natively since it would greatly reduce developer lock-in. In the meantime, the ManifoldJS project can provide Cordova-based polyfills for your Hosted Web App, but then you'd have to resort to messing with plugins all over again for the only two mobile platforms that really matter...

http://manifoldjs.com/

Different cross-platform tools have different approaches, but as a concrete example take Corona SDK. You need no native platform knowledge and your app runs inside the Corona runtime, which makes some difficult things easy but some easy things -- third-party SDK integration, install source tracking -- difficult. And if the creator of the cross-platform environment has chosen not to support certain things, you're out of luck (and you're probably always going to be lagging even for things that are supported). On the other hand, you have only a single codebase to maintain and single-click builds for a lot of platforms.

As for Cordova, we spent some time testing if the performance was sufficient when building an early version of Recent News (https://recent.io -- v1.0 just released three days ago!). We concluded it was not. Boot times were slow, the UI felt very non-native, and overall performance didn't meet our requirements. Now that was a while ago and Cordova may have improved, and hardware performance certainly has improved, so maybe it's a better option today.

There's the rub. If you don't know anything about the native platform then you "don't know what you don't know". The NativeScript demo shows how to pull in a native ObjC function (a string related method I think), but if you start with no background in the native libraries how would you even know when you could be leveraging a native library function instead of trying to recreate a sub-optimal approximation in JS. But if you have the foundation and know the native platform, why jump ship to JS at all? And then I'm right back where I started :)

I'm a (native) Android and JS developer. The primary reason I'm excited about React Native is that I don't have to go through the tedious compile-install cycle for every little UI change. React Native will make prototyping/iterating on Android as easy as it is on the web. However my reasoning assumes that there will be almost no friction in terms of creating complex views in React Native. I'm curious to see if that pans out.

No, that's the beauty of it. All you need to do is shake your phone and tap the "Reload JS" option. Those JS files are served by some sort of a server that starts up on your dev machine when you first deploy the app. See https://facebook.github.io/react-native/docs/tutorial.html#d... (search for "reload js").

After you write/run a lot of tests to make sure the app does what it's supposed to (there's paid services for this kind of testing too) http://googletesting.blogspot.ca/2013/08/how-google-team-tes...

This React abstraction can use Chrome Developer Tools for debugging though, that's pretty awesome.

But if your app is more advanced like a drawing app you should not use these cross platform stuff.