Want gestures? You'll have to look towards things like iScroll and hammer.js, which work "sometimes". Add that to framework issues, and momentum based scrolling that you will have to implement yourself numerous times... Oh boy. Basically, things that come out of the box on native will have to be manually implemented by yourself, and none of these solutions will even come close to native experiences.
Add this to the fact that phonegap documentation is all over the place, and all you will get are senseless headaches. Save yourself the frustration of hacking the web into a mobile device and go native all the way. You will thank your self later.
I'm arguing that if myself, as a no-design-talent, been using PG since 0.8 guy can recognize the benefits of switching my workflow to this, it is at least worth a look.
[0] Android WebViews seem to improve steadily, while always lagging a bit behind the real browser. iOS WebViews were crappy for a long time, particularly because Apple kept Nitro for themselves while third-party hybrid apps used a way slower JS engine. But iOS 8 apparently made massive strides here, and WebViews are right on par with mobile Safari (Nitro, WebGL, etc). Or so they say; I haven't tried it out yet.
I think the community agrees. Collectively they've started hundreds of thousands of apps this year and are installing our SDK at a rapidly growing rate. One of the benefits they see is a small learning curve, much closer parity with their existing web code, ability to have designers or non JS hackers contribute, and access to tons of existing resources for Angular development.
(1) The web standards that you speak of are currently as much a standard as what we are doing at Famo.us. Web Components, as they exist today and as is being promoted by/using Angular/Polymer/Material, is merely an idea in the guise of a standard. Google is the only one really promoting it as such and they got a lot of flak early this year from the Safari and Opera teams over their intent to ship the feature half baked and without consensus support from the other browser makers [0]. Until at least two major browser makers fully implement something and properly document it, it's not a web standard.
(2) There is no requirement to know about 3D development unless you plan on incorporating 3D effects into your app. All the 2D math/development we know and love today is merely an elevation view into a 3D world. You can use famo.us using all your 2D experience without ever really needing to understand 3D math/development. Furthermore, many of the interfaces widgets already available in famous and being created by the famo.us community are sufficiently high-level that the API should be enough to manipulate/modify that widget without any 3D knowledge. Only if you want to be a creator of 3D widgets or design higher order 3D compositions do you have to learn 3D development. Most developers will use famo.us the same way they use the web today (at least for now). i.e. 2D with occasional "Z-index" manipulations. Eventually some will explore what they can do with 3D since it's available [1]. Famo.us always leaves that option open unlike pretty much all other frameworks.
(3) I don't think the community agrees on anything just yet. If you look at the numbers, there are a lot of ideas out there with varying degrees of traction. Things could really not be more fragmented. It's going to be a long time before any framework is declared a winner in this area (if any). Even if a framework is ahead today, history is littered with frameworks that have fallen out of favor like prototype.js, script.aculo.us, YUI and MooTools. Any real student of computing history will be wise to remember Brooks: "No silver bullet"[2]
My suggestion to the OP is to install both and try them out to see how they are different.
disclaimer: I work at famo.us
[0] http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.h...
[1] http://alistapart.com/article/the-z-axis-designing-for-the-f...
[2] http://faculty.salisbury.edu/~xswang/research/papers/serelat...
Again, its native UI support is lacking (ie Keyboard, Input Textfield interactions) but otherwise the framework is opensource, solid, and compiles to native from HaXe (based on a similar structure as Actionscript 3) including to Windows, Mac, iOS, Android, Flash, HTML5+WebGL and more.
They also have a great list of apps developed with their platform at http://www.openfl.org/showcase/
Edit: Links
Been looking around but it goes from "learn to code' straight to 'map technology' to 'map access api' which combines to be pretty darn hard.
Cheers
This kind of step-by-step start to finish guide is exactly the kind of resource I find the most useful when I want to learn new things..
3. don't see [New App] button 5. Broken URL (missing ".git") 6. "App must be less than 20 MB" (I'm on the Free Plan, I assume like most)
Ideally you would support more platforms and not have to make any distinction in the JavaScript and could have a single code path. Right now I pay Pushwhoosh a hefty fee per month for exactly that.
I hate working with closed source stuff that I can't bug fix and improve myself. Just the current state as evidenced by this guide is so far behind commercial offerings it would take months just to get it even comparable.
(un)Fortunately, I've wasted the hours of getting the payload/etc support working pretty seamlessly, so handling incoming Push's is all done in one place: https://github.com/nicholasareed/internal_app/blob/master/sr...
