Recently we were tasked with creating a cross platform native application and chose to go with javascript due to our experience. I think Ember is by far the best client side framework available right now, which is why we use it for web application development. Trying Ember with Cordova, however, left much to be desired. After playing around with React Native script and NativeScript, I was really blown away.
NativeScript and React Native bypass webviews by integrating directly with native UI components. The approach works really well and seems like the best of both worlds as well as the way forward. For good reason, React and Angular are both embracing this approach for mobile development, with Angular using a custom NativeScript renderer. (1)
Is there any interest in the Ember community of embracing this approach to mobile development? How difficult would it be to build a custom renderer in Ember for NativeScript?
Not yet. With glimmer, especially glimmer 2, a native ui layer would be possible, but I’ve yet to see any perf gain going native. Good code is good code, bad code is bad code. The main issue right now is that JS is missing many ui elements that native SDKs provide, so I’ve been working on adding these elements.
flexi: better layouts, component cacheing
smoke-and-mirrors: large scale occlusion, better list/grid/scroll management
ember-radar: better position tracking
ember-async-image: smarter image loading and teardown (soon with ember-radar integration)
skyrocket: threaded ember
ember-peek: peek ahead/behind support for route transitions (requires ember-radar to release)
ember-hammertime: touch-action polyfill (a better fastclick)
ember-gestures: gesture based interaction for your app
ember-capture-eventing (stalled, awaiting RFC): a 10000x faster event model for Ember, reducing event overhead and making gestures, touch etc. competitively fast
hammerJS: (we’ll be adding a capture based mode, to interop ember-gestures with ember-capture-eventing nicely)
liquid-fire-tweenlite: gsap backed animation support
There’s also glimmer2 coming which will provide a great boost to perf, various pieces of the ecosystem make great perf strides on an almost weekly basis.
A lot of perf issues come down to avoidable ED bottlenecks, bad jQuery code, and bad data flow patterns. Generally speaking if you proactively keep ahead of those 3 things in your app, you’ll have a great mobile experience. Especially on iOS, but even on Android.
On the Cordova side, on iOS hopefully you went with wkWebView, it’s not the default, and it’s hugely faster than uiWebView which is the default. On Android, hopefully you were going with Crosswalk, also hugely faster, not the default, and makes better standards available.
In short, what I’m saying is, building ember apps that compete head on with native is doable without native SDKs, it’s just going to be a little while longer.
@jthoburn I can’t help but think this is the wrong approach. I suppose if all of these enhancements were bundled all together into an ember addon that made the process more seamless, it could theoretically be a pleasant experience, but I’m hesitant to endorse it. We still have to fight with the laundry list of mobile webkit bugs on iOS that still haven’t been fixed though, which add various quirks to the whole process. Have the mobile webkit quirks and issues all been fixed in wkWebView?
I do believe there is a reason the other major players in the client side javascript space are investing heavily into native UIs. As we added animations and css effects, we saw performance dramatically deteriorate compared to the same effects with React Native. Would it require significantly more effort to integrate a NativeScript renderer as opposed to combining various hacks to try to get webkit to behave like a native UI?
iOS mobile webViews are not the constraint, you can build native quality apps for iOS with Ember fairly easily. It’s Android ChromeViews that are the problem.
I would like to second the need of a “native” Ember implementation for mobile development.
It’s not only that you have access to more device features, not even the perf issue.
IMHO it’s just a DX (developer experience) thing and, above all, also a framework adoption issue.
Ember is a fantastic framework, we all know it.
But new developers, not knowing it, prefer to adopt Angular or React “just because” they do provide native mobile solutions.
That said, it seemed that the discussion at Ember support for NativeScript apps · Issue #122 · NativeScript/NativeScript · GitHub
has be reopened. If anyone is interested, please, comment and help.
ember-paper + smoke and mirror + ember-cordova give you near-native experience.
Ember-corodova includes crosswalk which uses chorme’s blink as webview which drastically speed up webview performance with no noticable difference to native apps.
unfortunately intel pull the plug of crosswalk webview , now it needs contributors to maintain it. but currently it uses chrome 53 as webview so it is fast enough
I agree. DX is not ember-cordova’s strongest point. Framework adoption will suffer, if not already, due to the fact that all competitors offer a path to native without jumping through hoops. Also, no matter how well written an app is, the difference in performance can be felt.