Performance and access to the internal SDK seem to be what ultimately kill this approach. Seems like this happens at the beginning of every product cycle.
So we've got this decent platform, we build up HTML apps that end up kludgy compared to IOS or Android native, so you do a 180 and release the official SDK and everyone migrates over; or your product never reaches mass adoption and dies.
Also, ChromeOS and FirefoxOS are browser's so of course they have a vested interest in making their apps in HTML / JS.
> So we've got this decent platform, we build up HTML apps that end up kludgy compared to IOS or Android native
People say this all the time, and it makes me wonder if I'm living on a different planet than them. I can see some places where native is better:
* A camera app, or a guitar tuner... something that requires access to special APIs. Making that in HTML would be a kludge.
* An app that's targeted at tech people, who want to feel like they're living in the future, and who need to have have fancy transitions and animations and subtle 3d effects.
But in my experience, the vast majority of apps do NOT require those things. Most apps are just buttons and pages and pictures and videos, and for that kind of stuff, I honestly don't see what the advantage of native is over HTML.
Maybe it's because I am an interaction designer. In my experience, the interaction design in most apps, native or HTML, is seriously lacking. It seems like almost no one actually tests their product with actual people. And it seems like very few developers are actually willing to build the dozens of prototypes that are required to iterate through a design in order to get something that actually works well.
And so we end up with all of these native apps that are supposedly "not kludgy" because they have native widgets and 3d animations, but actually are extremely kludgy in that everything you do in them is a pain in the ass.
But again, I hear people ring the native app bell over and over again like it's some major design issue. So maybe I'm just living in a different world.
> Most apps are just buttons and pages and pictures and videos, and for that kind of stuff, I honestly don't see what the advantage of native is over HTML.
This is true for very simple apps. But native platforms have developed UI conventions that should be followed for non-trivial apps, and modularity capabilities that should be exploited. Taking Android as the example:
Fragment is the way Android apps scale between small and large displays, and how such apps are modularized.
ActionBar is how commands for fragments are added to "global" UI elements as the Fragment objects appear.
The Share action is how data is moved in the highest-level, user-directed way; Intent and startActivityForResult is how apps borrow UI and capabilities from each other; bound service RPCs is how apps can call each other's APIs. You can't do that with Web apps.
Android arguably has a more powerful feature set for modularity and inter-app cooperation that has been held back from achieving its potential fro users because too many apps started with a Web app or an iOS implementation. Android also has UI conventions that are sophisticated and good-looking and that users will increasingly value apps for adhering to.
Thanks for this! I haven't used Android in probably 3 years so I'm less aware of those things. On iOS the apps seem to be more self contained.
The issue of conventions does seem to be the crux of it. They can be powerful, although sometimes people seem to rely on conventions because they can't be bothered to figure out an actual powerful, simple, learnable, comprehensible interface for their application.
A lot of "non-trivial" apps could be made trivial through good design. In the absence of that, yes: if your users have to jump through hoops they better be the conventional hoops.
So in that sense my point remains. But I have no idea what proportion of apps fall into the "could be designed down into something more intuitive" va "is inherently very complex and must rely heavily on conventions" categories.
I should boot up my old Android with the new OS and familiarize myself with the new hotness. When I used it last the conventions like the back button and menus and such we're so randomly applied you couldn't really rely on them anyway.
It's funny, I can't see a world where native isn't better.
The performance is still affected even for simple apps and even if the CPU can handle that degradation, the battery won't. If the application does something, it will take more CPU time and this is bad in ANY way. Why wasting theses CPU cycles? Only because you are "more productive"?
Second argument, security. Inject JAVA into a live app, not impossible, but hard. Inject HTML, easily done... When will we start to see XSS on our applications? HTML5 is literally an eval on every single text field...
Third argument, HTML5 is fantastic? Then use it, nothing stop you. There's multiple way to do it currently, the JS api on Android is complete, you can do anything you want. If the platform doesn't support HTML5, then you can start an open-source project or even a commercial project that will allow it. If we start from the HTML5, you won't be able to go native from that point, you directly block possibilities only because you prefer HTML5.
Facebook tried the HTML5 for their apps, the performance was awful and it wasn't a complex app at all.
By many reports Facebook's native app is still pretty flawed so maybe they just suck.
Your battery argument only holds if the 'html overhead' is a major part of power usage and there is no evidence it will be (screen on time, radio usage etc., native calls will probably dwarf drawing the UI).
Your security argument also strikes me as weak. 'Wrapped' HTML apps presumably benefit much the same security infrastructure as native apps. Once your app is vulnerable to injection it's pretty much game over no matter what your choice of language.
The Facebook app is perfectly fine, I have no problem with it.
I have plenty of games that eat more battery than anything on my phone.
Except that like I said in HTML every single text you show is literally an eval call. There's still ton of XSS on website, it's a common security threat, the same will be possible on an HTML5 application (they will even have access to your phone functionality).
>>But in my experience, the vast majority of apps do NOT require those things.
If you are making a service like Cherry (On-Demand Car Wash) then you need to maximize the responsiveness of the app. HTML still can't do this although HTML->Native could. On the other hand many people want to write new functionality.
HTML is restrictive and results in a subpar product. You get easier development, but its not time saved if you need to redo all your work.
Frankly, if your requirements fit into HTML the your app probably sucks! :-)
How do you feel about native vs HTML5 for applications that need to do a lot of timing? From my perspective setInterval and setTimeout seem pretty kludgy.
Also, I'm really interested in what you mean by "the dozens of prototypes that are required..." If you're talking about building several prototypes of the same feature to compare and contrast, would you mind sharing the tools/workflows you use for this?
No, I'm talking about a wide range of prototypes, from paper prototypes to experience prototypes to barely-functional HTML prototypes that only test one small aspect of your app, to small native apps that you throw away that let you test various aspects of your design that need to be mocked up more fully.
Finally, towards the very end you might do a few variations within your fully realized native app, but that kind of prototyping is extraordinarily expensive and 90% of your design questions should be answered by that point.
The output of a good design process should include dozens of vastly different looking prototypes, in totally different mediums, each of which helped answer key design questions.
A good introduction to this's stuff is Rogers, Preece and Sharp's "Interaction Design". My personal favorite for diving into the breadth of design techniques is Brenda Laurel's "Design Research".
If you wrap the callbacks in promises or observables, they become a very elegant and side-effect-free model. Reactive programming is starting to get traction, now that it's more well known and being adopted by mainstream libraries.
I would argue it is gaining steam due to the money being poured into it. Probably also possible now that resources are particularly "free" on platforms. It isn't like most of these techniques were invented this past year.
I can't help but feel that this will turn out the same way as how HTML5 is used on mobile phones for native apps right now, where your app ends up not looking native to any of the devices, despite the benefit of one code base for the app.
Of course it will! This is Cordova, the same Cordova as used on BB10, Android, and iOS. This is less webapps and more html stuffed into a native app.
This should not be mistaken for something akin to FirefoxOS. Full disclosure: I've dabbled in systems programming on both Cordova (for BB10), and Gecko. Cordova is but a crude approximation to a proper web environment. Long live Gecko!
Who needs portability when you run fast and have achieved critical mass? Firefox OS, Chrome OS, and Ubuntu are all linux with tiny market share. I don't see many benefits for Apple.
You can use JetBrain's AppCode if you dislike (despise) Xcode :) It's written in Java, but at least it doesn't crash every couple of days (possibly corrupting(!) .xcodeproject files).
And the Modern ObjC (with ARC, @properties, blocks, new @literals, awesome and useful clang errors, etc.) is much, much better than it was around iPhone OS 3.0! The signal/noise ratio of a typical iOS app is now maybe twice that of an app written in the bad old days.
Yeah, I think the story was posted here recently. They signed somebody but can't say who it is yet, just that they're "big". There were some hints that the appeal had to do with Android being a big deception built around the "open" concept.
Put it this way -- it runs on just as many good cellphones as firefox os and you can use it to write desktop apps that will potentially work on mobile. I imagine that at some point a dominant HTML5 wrapper for OS level functionality will become ubiquitous, doesn't really matter whose it is.
I'm not sure what your point is or how it relates to my questions. Why would anyone use Ubuntu's SDK instead of Firefox's or a cross-platform HTML5 SDK?
Million is probably immodest too. Whoops, i think apple and samsung sold a million phones just then. Oh that's silly, it takes them a day or two to sell a million phones.
So we've got this decent platform, we build up HTML apps that end up kludgy compared to IOS or Android native, so you do a 180 and release the official SDK and everyone migrates over; or your product never reaches mass adoption and dies.
Also, ChromeOS and FirefoxOS are browser's so of course they have a vested interest in making their apps in HTML / JS.