
Web Developers, Don’t Be Lazy And Learn A Native Mobile Language - dirkdk
http://blog.mobtest.com/2012/12/web-developers-dont-be-lazy-and-learn-a-native-mobile-language/
======
Silhouette
There's an old Chinese proverb: "A man who says it cannot be done should not
interrupt the man who is doing it."

That's the feeling I get from opinion pieces like this. I've developed web-
based user interfaces for several projects in recent years, some of them with
a strong mobile focus. I'm still waiting for all these demons to come and bite
us, where our paying customers don't find the experience satisfactory and run
away to the competitors who are going to beat us by having a highly polished
native app instead.

Sure, there are occasional irritations with mobile browsers. Many of them,
perhaps even the majority I've come across, are actually by design because
Apple actively chose not to make their browser work like everyone else's...
again. But do we spend as much effort getting our web apps to run effectively
across all the major platforms (including Windows) as we'd have to spend
writing a native UI on every platform we want to support? Not even close.

And native apps still have the same horrible downsides as ever: the app store
approval lottery, Apple wanting a huge cut of any money you make, yada yada.

If I were running Facebook, where for practical purposes the budget and
developer time required to develop a mobile app on every platform were
negligible, sure, maybe it's worth it for a more polished experience. (Maybe.)
But for more modest projects, where resources are finite and we don't
magically have developers on tap who speak a different "native" language for
each platform, I can spend the time and money once to build the web app and
then the same again refining it or I can spend the time and money twice just
to get the basics done without any polish. I don't understand how anyone who
has actually done this can be in any doubt about which gets better results.

------
greenyoda
It's not laziness, it's an economic decision. Learning a development
environment like iOS or Android takes quite a bit of time and effort
(especially if it's not your day job). If you believe that by the time you
become proficient, HTML-5 will have improved enough to significantly decrease
the demand for native apps, then you should spend your time learning something
more valuable.

Also, lots of people have already learned native app development, and it's
increasingly becoming a commodity skill that, at least for simple apps, can be
outsourced to the lowest bidder. Developers might believe that learning skills
that are not as easily outsourced, such as data analysis, might be a better
investment.

Finally, learning a fast-changing environment like mobile apps is a much
bigger investment than just learning a mobile language. It's a large, ongoing
effort to stay current with the new features in every new release of the
platform. So please let's not call people lazy just because they're not
jumping on our favorite bandwagon.

------
mistercow
Not doing native development isn't about laziness. It's about freedom and
flexibility. As much as is possible, you should strive to minimize your
dependence on any single company (at least until you have some clout), and
having a code base that is locked to a closed platform breaks that principle.

And look, what I'm saying here isn't ideologically motivated. It comes from
hard experience. If I had a dollar for every time I sat on a blanket with two
corners held by a single company, and then got that blanket yanked out from
under me, well... I'd have three dollars.

------
darrencauthon
"Native technology allows for excellent apps, whereas HTML5 apps will be at
best just OK"

Sometimes "just OK" is what people want, and what meets the needs of the
business.

The truth is -- building a mobile web app can be fast and can fill an
iPhone/Android/Blackberry/Windows phone with the content and interactivity the
business and users need and want. It can also be much cheaper. Different
businesses have different values, and whatever works best to achieve those
values is best.

Calling devs lazy for not learning native mobile languages seems like a cheap
way to get clicks. New Year's Resolution: Stop clicking on them.

------
chrisringrose
It's lazy to give up and devote all your energies on yet another company's
proprietary platform. Instead of constantly writing articles like this, how
about we focus on the obstacles web apps face, and fix them.

Sure, if both a web app and native app are programmed optimally, the native
app will run slightly faster. But a program written in machine code will
always be faster still. There will come a point when the speed disadvantage is
outweighed by all the benefits of web apps - and that time is near.

The biggest issues with web apps are:

\- _Development._ Creating web apps requires writing code in at least 3
different languages, including server code, client code, and markup code. Try
making an iOS paint app that saves your drawing to the cloud. Then try doing
it as a web app. If you think this is easy, believe me, Objective C is a
_drrreeeam._

\- _Discovery._ The App Store/Google Play are the best ways to discover new
apps. There exists no such popular and lively platform for web app discovery,
review, and sales.

\- _Browser and OS Dependency._ Mobile browsers don't all allow access to the
camera, easy installation to the home screen, and all the access to APIs a
full-featured app should have.

So let us be constructive from now on, and focus on fixing these issues,
instead of giving up and locking ourselves into reliance on yet another
company (Flash, iOS, Android, etc).

------
jefflinwood
Some of the impetus towards cross platform HTML5 development was probably
because the state of Android app design in the 2.x era was so bad. You could
basically get away with using an iOS-look-alike web toolkit on Android in a
WebView, and it was "good enough".

With Ice Cream Sandwich, the new Holo look and feel actually has a real design
language that is markedly different from an iOS app.

As to Windows Phone - there is such a strong design for Windows Phone apps
that those jQuery Mobile apps in their app store look really out of place.
Microsoft's working on some CSS that will make jQuery Mobile apps look more
native, but it's still missing some of the key Windows Phone UI like panorama.

From developing HTML5 and native mobile apps for iOS and Android, and from
follow ups on some mobile application strategy consults, HTML5 mobile apps
just don't deliver a good user experience, especially if the app does anything
other than content consumption.

------
javis
Mobile OS developers, don't be lazy and give me a way of embedding HTML5 into
an app that doesn't completely ruin the whole experience.

Seriously, a web app will be running beautifully in Mobile Safari, but when I
put the same code into a WebView, it all goes to shit.

~~~
dirkdk
Yep, running a web site in an hybrid iOS app will slow down your app, as the
Nitro Javascript engine is not available. That has been the case for a while,
because of security reasons, and won't go away any time soon

------
gruseom
Is there a good reason not to believe that mobile will eventually swing to
HTML, for the same reasons that desktop apps yielded to web apps?

~~~
Silhouette
In general, I don't think desktop apps _have_ yielded to web apps.

Web apps have worked well for projects that are essentially simple front-ends
to a database or simple content distribution systems, which admittedly
represents a very significant part of the software industry. These tools
inherently require some sort of client-server system, so there's no
architectural overhead there that you weren't going to have anyway. Also, with
web apps you get cross-platform portability very cheaply, and you get zero-
effort deployment instead of trying to deal with installation/upgrades of
software on say Windows where the plot was lost long ago and no-one has ever
restored sanity.

However, when you come to doing anything that requires non-trivial
interactions or non-trivial processing, web apps are often still _decades_
behind the state of the art for mature desktop applications. No-one does
serious graphics work, or mathematical modelling/simulation, or FPS gaming in
web apps today. I suspect we never will, because we'll develop (rediscover?)
how to build such applications with a specialised thin client and/or how to
push out and maintain software with a native thick client more effectively
long before we bastardise a text mark-up language and its friends well enough
to write serious software as web apps in general.

~~~
gruseom
Of course you're right that some domains (e.g. graphics) are harder than
others, but you might be overstating your case. Surely Gmail requires "non-
trivial interactions". And why not mathematical modelling/simulation? — you
can access a lot more computational power on servers. And how often does one
hear of a startup making new desktop software?

I like your point that we might figure out how to get desktop deployment right
sooner than how to adapt the web to do all these things. But nearly all the
innovation has been pointing in the other direction. Also, such a deployment
technology would face formidable institutional barriers.

~~~
Silhouette
_Surely Gmail requires "non-trivial interactions"._

Yes and no. GMail is arguably one of the most successful and mature web apps
out there, but at the end of the day you're still just reading mail, clicking
a few places to change how information is presented, and typing a bunch of
text. None of this requires a lot of real-time assistance as you navigate the
information, context-sensitive UI, or task-specific controls beyond regular
menu/toolbar/icon kinds of things, for example.

 _And why not mathematical modelling/simulation? — you can access a lot more
computational power on servers._

Well, I think that point is debatable if you're doing serious modelling more
than occasionally. The kind of processing power required makes it cheaper to
buy your own high-end systems than to use commodity cloud-provided facilities
very quickly, and for the same reason I suspect it would be difficult to offer
such services economically in SaaS form.

Also, real time graphic visualisations in web apps are still far slower and
less sophisticated than what you can achieve natively with modern graphics
cards, at least for now. If you're watching a couple of pretty graphics in an
analytics tool, that doesn't matter. Even some basic 3D work is starting to
get interesting with technologies like WebGL arriving. But for real-time
rendering and navigation of global weather patterns or the design of a cruise
ship? I don't see that being done remotely any time soon.

 _And how often does one hear of a startup making new desktop software?_

I'm not sure how often one hears about start-ups doing something is a very
useful metric, really. The culture on HN is particularly biased towards that
field, but in reality there are millions of programmers out there working on
desktop software. New bespoke desktop applications are being written for
businesses all the time, and likewise tools, toys, games and more are written
by small software shops for individuals all the time.

 _But nearly all the innovation has been pointing in the other direction._

Really? I'd say the mobile "app store" model and the Linux "distribution"
model have both been very successful at getting native software deployed onto
users' systems, too.

It's just a shame that we still have horrible deployment practices and
dependency management on most desktop platforms, much of it due to the
stagnation of desktop OS architectures and the continued use of strategies
that were originally designed to cope with limited resources but that have
been obsolete for years now.

~~~
gruseom
I think you underestimate how much is going on in an app like Gmail, and also
the extent to which people have figured out how to do things like "real-time
assistance as you navigate the information, context-sensitive UI, [and] task-
specific controls" in the browser. Those problems are mostly solved. Some
things, like rich text editing, still suck.

 _I'm not sure how often one hears about start-ups doing something is a very
useful metric, really._

Startups aren't what drives tech innovation in markets? That seems at odds
with history. Millions of programmers may be doing as you say, but that's
mostly legacy. Are they creating fundamentally new things? What is the most
recent desktop app that you could call innovative, apart from pushing the
envelope on graphics?

 _I'd say the mobile "app store" model and the Linux "distribution" model have
both been very successful at getting native software deployed onto users'
systems, too._

I guess Apple have integrated desktop deployment into their App Store (rather
to my annoyance actually) and MS are about to do the same, or try to. Perhaps
the habits people have acquired around downloading and installing mobile apps
will end by triggering a renaissance in desktop applications. But I won't
believe that I until I see major new applications being built this way.

~~~
Silhouette
_I think you underestimate how much is going on in an app like Gmail_

I've no doubt they do all kinds of clever things behind the scenes, from
detecting things like malware and spam to all the analysis Google do for their
own purposes.

Still, relatively speaking, I don't think the front end for an e-mail client
is very complicated. And there's nothing wrong with that, because it doesn't
need to be: its job is to manipulate a small amount of data (from the user's
point of view, with a simple structure, which doesn't change very much and
doesn't have a lot of dependencies.

This is all true of most major web apps, as far as I can see.

 _..."real-time assistance as you navigate the information, context-sensitive
UI, [and] task-specific controls" in the browser. Those problems are mostly
solved._

Don't you think "mostly solved" is overstating the case a little? Even web
apps whose UIs we might call mature or advanced today rarely offer more than
what desktop WIMP UIs were doing 10 or even 20 years ago. As you mentioned,
even common operations like editing formatted text are often still below par.
Truly task-specific UIs, the equivalent of say a three-way diff/merge tool or
a space flight simulator game on the desktop, seem to be extremely rare in web
apps.

 _Startups aren't what drives tech innovation in markets?_

Start-ups can certainly drive innovation, though obviously this particular
forum has a built-in bias and I think a lot of posters here tend to overrate
the importance of any one start-up or of start-ups generally.

However, I don't think whether or not _we've heard of start-ups_ means very
much. It's a big world, and most of us will only ever see a tiny fraction of
it. Lots of the innovation happens in small businesses that help larger
businesses or other non-consumer fields like academic research or government
departments behind the scenes. These things don't tend to be very visible to
the general public, and probably won't get you on the front page of HN or
written up on TechCrunch. Plenty of these projects involve developing desktop
apps.

 _What is the most recent desktop app that you could call innovative, apart
from pushing the envelope on graphics?_

I can't give personal examples from my own work unfortunately, so instead let
me ask you this: have you been to a movie lately? Did you notice all the CGI
special effects? Not the robots and zombies and futuristic home automation,
the _other_ ones. The answer is probably "not even close", because the
programs the SFX wizards use to create those effects are now so powerful that
the results really do go unnoticed a lot of the time, as they should. These
things are done with a vast array of bespoke software that is evolving all the
time, some of it off-the-shelf but a significant chunk built in-house for
major projects. And they're not building web apps. (Most of the time. ;-))

 _Perhaps the habits people have acquired around downloading and installing
mobile apps will end by triggering a renaissance in desktop applications. But
I won't believe that I until I see major new applications being built this
way._

I tend to agree. I fear that ship has now sailed, but it would be nice to
think that the groups behind the significant desktop platforms could still
come up with a sane way to install and update applications.

It's crazy that in 2012 (just...) we still rely on each application's
installer/uninstaller/package manager/update process to copy files into
basically arbitrary locations, some of which may be shared with other
software, set up hidden details like registry entries, even hack around global
system configuration or perform dark magic for product activation/DRM
purposes. And then we expect to install more than two things and have them
play nicely together, and then uninstall in some arbitrary order and still
have them play nice together.

Here's hoping 2013 will bring something better!

------
hunvreus
One of the obvious reasons some teams may not go for native is that they don't
have the resources to commit to maintaining two applications.

Having 2 teams, contracting an external agency or finding a developer versed
in both platforms are all pricey options. If your product is not the mobile
apps themselves (obviously), HTML5 or Titanium can get you there without
stretching your resources.

------
eddieroger
I tend to agree. Even a properly optimized, Simonized and Vulcanized app needs
to be run through a browser layer, which inherently slows things down.
Javascript bridges to native functionality are messy and can fail. And for
what? Writing one code base? How much client-side logic are you really doing
that you don't want to replicate?

Any mobile app I write that requires server logic is basically just a view, so
it needs to accept and manipulate JSON. Interface Builder gets you an
interface in minutes (of course, you can spend time tweaking it), and there
are dozens of networking libraries that consume a service and spit out native
objects (if that's your thing). At the risk of speaking in absolutes, you will
never get a better experience than a native, first-class one. Ask Facebook -
it didn't work out so well for them.

------
timburks
Vishal Gurbuxani gave us the marketing perspective on this last month in Napa:
<http://www.slideshare.net/vgurbuxani/app-retreat-2012>

One major problem: HTML5 is fragmented across platforms and is missing
important ingredients needed by app businesses. In the end, it's just another
platform, and not a very good one if a good user experience is something that
you hope to deliver.

Read Vishal's slides for more, or come ask him about them at his session at
Renaissance: <http://renaissance.io/speakers/vishal_gurbuxani>

------
mos2
What about Ruby Motion for iOS? Its commercial ($200 a license) but offers
native objective-c compiled from ruby and is based on the open source mac ruby
project.

This seems smart as you only have to learn the cocoa framework and you learn a
little bit of objective-c. Whats nice if you want to go native and or optimize
by writing straight objective-c you are halfway there.

Everything else I have looked at is basically a web browser attempting to be a
full app.

I would love to hear if anyone has written an iOS app that is on the app store
with it and what there experience has been.

~~~
gte910h
> as you only have to learn the cocoa framework

This is the hard part. The objective C part isn't.

------
idont
This reminds me when (Adobe) Flash evangelists were requesting us to join
their "better experience" ecosystem... (10 years ago?)

------
andybak
Mobile OS developers, don’t be lazy, give me a half decent language that
doesn't make my eyes bleed.

~~~
jspthrowaway2
Fine, I'll bite.

Assuming you're belittling Objective-C, let's not forget that Objective-C is
simply C with Smalltalk bolted on. I'm having a hard time imagining a plane of
reality in which either is not "half decent". Objective-C is, in my opinion,
much better than C++ to accomplish the same task (they have semi-equivalent
aims, though implemented very, _very_ differently).

I learned Objective-C and iOS (then called iPhone OS) from scratch to write a
quite-complex app once. The app has been in the store for two years now. Like
you, initially, I balked at the brackets; everybody does. Eventually, I was
actually pleased that my C experience carried over so well, and it was a
pleasant experience in the end. As you do, I wrote two to throw away until I
mastered the platform, and I didn't mind it at all.

Assuming your object _user_ has an _update_ method which takes a _name_
argument and you want to store the result of calling _update_ somewhere,
here's Python vs. Objective-C (the Smalltalk-influenced terminology is
different, but the concepts are the same):

    
    
        save_result(user.update(name="Larry"))
    
        saveResult([user updateWithName:"Larry"]);
    

I don't find one much more horrible than the other.

~~~
eropple
It's not just the brackets, though they're ugly and provide stops for the eyes
where none should be; you have NSReallyReallyLongNames all over the place (
_encouraged_ by XCode, to the point of automatically doing it for your own
classes, because namespaces are apparently too modern), required parameter
names, and other silliness that makes Java look restrained. And while we're at
it, its interop with an actual, fairly standardized _modern_ (note: this means
"not C") language that people use (so C++, for those keeping track at home) is
not very good, and while you might find Objective-C superior _nobody else uses
it_ so C++ is probably going to be involved somewhere, be it Windows or
Android.

Objective-C is tolerable, sure, but I'd rather write C++ - and that is no
compliment to C++. (But, as a side note, I give Apple all the credit in the
world for having a _fantastic_ C++ environment on its own. XCode has its
stupid spots, but it doesn't get in clang's way.)

~~~
jspthrowaway2
I actually _vastly_ prefer a language without namespaces, and the naming
conventions are not due to the absence of namespaces. You're talking about the
NextStep API (the "NS") and the conventions that were born from that -- there
is no mandate nor impetus (and, I don't recall Xcode automatically doing it
for me) that you use that convention yourself. They just carried it through
for the other APIs, like UIKit being "UI" (UIViewController, etc).

My User object was called, unsurprisingly, "User". [[User alloc] init].

As for interop with C++, Objective-C++ exists and is used for apps in the
store. (Hint: 3D games that are ports.)

~~~
eropple
XCode has a setting in a new project to prepend to all class names. The
necessity of that sort of feature indicates a failure of linguistic design (by
which I mean the necessity of clearing up symbol pollution--there is also an
argument for their use for explicitness, which I reject because the world has
shown us its obvious failure).

Even just aesthetically--vomiting out half-line identifiers every time I have
to refer to a class is, for me, painful and stupid and makes me hate reading
what I've written. One of the worst feelings in the world is looking at code
you've written and hating even looking at it, and for me there are only three
languages I've spent time with where that's the case for reasons beyond me
fucking up: Java, Scala--for reasons entirely unrelated to its Java heritage,
it makes its own mistakes--and Objective-C.

As for Objective-C++, it's useful in a limited capacity but often requires
unscrewing your object model in pretty stupid ways just to provide inputs that
the Objective-C side won't barf on. It's an "ehh" hack with painful edge
cases.

~~~
jspthrowaway2
I shouldn't have bitten. This is like arguing over why a Phillips screwdriver
is better than a flathead with someone who particularly and angrily hates
Phillips screwdrivers because he doesn't like their appearance. They're tools,
bud.

I'm pulling my rip cord on this discussion based on your tone, the nearly
guaranteed futility, and the complete lack of any realizable benefit in my own
life of carrying on. Good evening.

~~~
andybak
Your screwdriver analogy doesn't really apply. Language choice has
ramifications beyond 'appearance' and you know it. I'm afraid I don't believe
that you really don't care about your choice of tools.

~~~
jspthrowaway2
With every passing moment I regret replying to this thread more and more. You
completely missed how my analogy works, actually, since you think I'm limiting
the problem domain to appearance (I'm not; I'm characterizing someone ELSE'S
displeasure).

I wish the privilege to delete didn't disappear after a time, so I could wash
my hands of this thread and forget that I ever spent more than ten minutes on
it.

------
dmotz
I think this argument, ad hominem aside, loses a bit of validity with every
subsequent smartphone/tablet generation. Every advance in CPUs and JavaScript
interpreters blurs the line more if we're looking at a hybrid app developed by
a competent team.

As to where I'm coming from in this argument, yes, I currently develop mobile
apps using web technologies. [1]

And yes, I completely agree that the majority of web view/hybrid apps I've
encountered have had poor user experiences. But the field of hybrid apps is
new and everyone can recall the poor user experiences of desktop web apps in
their nascent era.

As with the age of MapQuest, the sample size of hybrid apps is still small and
thus well-designed and well-coded apps are scarce. Aesthetics give probably
the biggest impression of mobile software quality, and you can either choose
to stick to stock SDK UI, or implement your own visual language. The former is
safe and is the default for native development. Hybrid apps almost always fail
when trying to mimic it completely and users are (at least subconsciously)
repelled by the uncanny valley these apps may land in. The latter option of
introducing a unique UI is exceedingly difficult to pull off, hybrid or
native, but is a route of convenience for hybrid developers, but again, they
usually fail to create something a user can feel comfortable with.

In short, if you're serious about your app's reception, it is more difficult
to pull off the user experience using web technologies, contrary to the
article's assertion. Hybrid app developers cannot rely on native UI elements
and this is why they tend to be received so poorly.

So why have I chosen the hybrid approach? Mainly because I'm a futurist and I
see the immense value in having an open lingua franca for app development over
fractured proprietary environments. The cross platform benefits appeal to me
less, and at the time of this writing, I consider iOS to be ahead of the other
platforms in fidelity of rendering web content (Android 4 is catching up). I
fully admit this benefit is half-baked at the moment, but I don't need any
pundit predictions to know it will improve by bounds in the next few years.

JS isn't a silver bullet, but it's undeniably exploding at the moment,
especially in terms of flexibility (browser, server, mobile). You could invest
your time in mastering a proprietary platform's SDK, but besides only focusing
on non-portable knowledge, you could also find yourself with a dying
marketshare for your chosen platform. I definitely don't mean to discredit
native languages by any means, I just want to convey how I came to conclude
that hybrid is a safe investment in mastering. Many apps, whether simple CRUD
apps, or thin front ends for REST APIs, have no specific need for native code.
Even Microsoft --seen among the symbols of proprietary control -- are
embracing the HTML5 stack for apps. The benefit of being able to reuse the
libraries and APIs [2] when bringing an app to another platform shouldn't be
underestimated, nor the potential growth of mobile-oriented common knowledge
in a common language.

Is it really difficult to believe that in a few years phones will be running
WebGL-powered 3D games with advanced shader effects, on par with native games?
Not really, considering how rapidly we're approaching that point on the
desktop. It's even easier when you consider the hybrid app bottleneck is
usually DOM painting, not JS execution, and WebGL would potentially use the
mobile device's GPU. This problem is almost solved already with intelligent
DOM manipulation and CSS3 transforms, (or potentially other approaches [3]).

Writing a quality hybrid app at the moment is very hard. Web views have less
memory available, execution is slower, and simple DOM rendering is expensive
and slow unless all optimized properly. Furthermore, aesthetics are harder to
pull off when working outside SDK UI sets. But hybrid apps are a relatively
new field and have enormous potential. I don't it's very mature yet, but
neither was the web itself for a very long time. I think having a common, open
set of tools is worth defending from accusations like this one or the red
herrings thrown around regarding HTML5's role in the Facebook app. This is
definitely the more forward-thinking bet.

[1] - <http://chaincalapp.com>

[2] - specifically HTML5 device APIs as well as <http://phonegap.com>

[3] - <http://famo.us>

