For me, it's not even javascript anymore. Objective-C and Java rule 2013 since web apps are not as pleasant to use on mobile.
I think this is bad. Not because the technology isn't good, but because small companies (or idealistic organizations, or others with a small budget) will have to implement useful apps for several platforms. Perhaps they cannot afford it (or think it's too much hassle, or don't care).
E.g., say that there is a product made to make life easier for people with a certain disease. Perhaps some users will have to switch device in order to use it. And maybe there are other apps they need which are available only for their old device. (And don't forget that are other platforms than iOS and Android as well, including desktop.)
Web apps (either run on the web, or natively) solves this problem, even though I agree that JavaScript, with it's myriad of ways to shoot yourself in the foot, is not ideal.
Like another commenter pointed out, there are options for compiling to multiple platforms. But it often doesn't seem to happen that way, and perhaps it's not always possible or feasible.
Or with some MVVM, Xamarin and some C# or F#... write once, compile for all mobile platforms. Never having to once touch the nastiness of Obj-C or Java.
Not sure what you mean about the APIs being nasty. Can you elucidate?
Java is well java. I find one of Java's strongest points the extensive set of collections available. Add in Apache Commons and java is easy enough to use.
Sounds like a dumb ass decision.
It's the sort of logic that makes people pick C or C++ when a managed language would have been more appropriate.
Plus Mono does not save you from writing multiple UI code anyway.
Also struggling to verify that claim re. executable size, can you provide a link? Either way, average app size on Android seems to be around 3MB. A typical Xamarin-compiled app is around 4 to 4.5MB.
This is a cross platform implementation of the MVVM patterns, you still need to write the platform specific views.
And to be honest, given my experience on .NET enterprise projects, MVVM brings me back J2EE 1.4 memories.
> Also struggling to verify that claim re. executable size, can you provide a link?
Someone mentioned it to me on a Reddit discussion.
We have the policy to only use vendor supported languages, to minimize support issues and take advantage of performance.
I should add the mobile apps I was involved were games.
I remember Facebook originally used HTML5 to support all platforms. This did work, but they became unsatisfied with the performance and ended up rewriting both the iOS and Android apps in native code.[1] The killer quote:
"I think the biggest mistake we made as a company was betting on HTML5 instead of native," Zuckerberg said...[2]
Granted, this was a different situation. They were using HTML5, and it looks like Xamarin compiles to native code. You mentioned slightly larger executable sizes, so I'm curious about the performance.
1: https://www.facebook.com/notes/facebook-engineering/under-th...
2: http://www.computerworld.com/s/article/9234695/Facebook_debu...
Basically all your UI logic sits within these PCLs. And the only stuff you have to write/design for each platform is the actual screen layouts. Then you just setup the data bindings back to your models.
It's a shame this is news to people on here. It seems like the real innovation that goes on in .NET and Mono land is largely ignored or just swept under the carpet by the hipster community.
The larger executables is because it has to embed the Mono VM, and some base class libraries. I've not really looked into performance versus Davlik; probably because I've not yet encountered any show-stopping performance issues.
Where I feel they should place some of the blame is the backend architecture. Perhaps the app doesn't scale well. Perhaps they should research what the proper amount of data is to send to any given device. Implement more of a lazy approach. They have some very brilliant people working there. I find it hard to believe that HTML5 can be blamed totally for their app's poor performance.