
Why a veteran web developer finally turned to OS-native apps - jonny_eh
http://gigaom.com/2013/06/01/going-native-why-a-veteran-web-developer-finally-turned-to-os-native-apps/
======
ilaksh
The primary advantage of a web platform for webby, desktop and mobile
applications is to be able to write one set of code that works on all devices.

It seems strange to me that so many young developers don't seem to comprehend
why that is a big advantage.

I want to code in CoffeeScript and use nice simple APIs.

I'm sorry but Objective-C is outdated and overly complex. The only reason
people accept and even learn to love it is because if you are an Apple person
you have to. You have no choice in the matter. Its like people in North Korea
have to love their Dear Father Leader or something.

I'm sure the Android Java libraries are much better than before, but they are
still based on what I consider to be a dated type of development. The
framework APIs are inferior and constantly specifying types is unnecessary.

To me CoffeeScript with Node.js modules are the state of the art in terms of
language design, dependency management, and API design.

~~~
mmahemoff
Actually, I think the case for web gets even more compelling with Meteor,
where you can really share components across both sides of the wire.

As I alluded to at the end, the web case makes a lot of sense for companies
with unique services who want to roll out across platforms. e.g. If you're a
corporate insurance broker, you have a few hundred users who just want some
conveniences from native apps, that's a good case for HTML5.

Another example I saw recently is an agency making "viral" apps. Just one-time
apps for short contests and so on, and they can do a great job with HTML5.

Deep-level integration though needs native, whether you like Obj-C or not.

~~~
ilaksh
Yes Meteor is very amazing. Of course they have another HTML5 thing in WebRTC
that when it becomes well supported (actually fairly soon in Firefox and
Chrome) has peer-to-peer data capabilities that for many applications
supersede server-based models. Of course, I know that for some applications,
that won't be workable, and there are problems to solve, but I believe that
most of the problems with synchronization and data ownership have reasonable
solutions in peer environments.

I am still hoping that PhoneGap/Cordova will work out ok for my next 'native'
app. Have you found that it isn't adequate?

~~~
mmahemoff
I'm the OP, so yes, I found it inadequate :). For a podcast app, even using
PhoneGap (rather than browser-based web app) would lead to several issues:

* Hard or impossible to do rich, interactive widgets, notifications, and lock-screen in HTML5

* Unclear path for downloading and saving large files. (Might be possible, but again would need native bridges or native code; forget about Ajax and offline HTML5 storage.)

* Mediocre UI. If you work hard at it, you can build a reasonable UI, but one of the feedbacks we got from reviews and reporters is how they like the way we implemented Android's Holo look-and-feel. A lot of people feel an emotional attachment to their OS and appreciate apps that fit within the guidelines.

------
peterhunt
Discoverability and system integration are huge problems, sure, but Cordova
mostly addresses these concerns.

The reason everyone always cites for going native is "performance", but, tbh,
it seems like most web projects don't pay attention to the same level of
detail as native apps because the web is so much faster to prototype. I bet if
devs spent the same amount of time working on perf and loading states on the
web as they did on native, the performance argument would have much less
impact.

~~~
jjtheblunt
There are entire types of things not possible in web apps, such as true
threading with a dedicated processor, accessing OpenGL accelerator support
with custom shaders, getting at purposeful hardware support in general, whose
reason for existence was cumulative need over more apps for more years than
JavaScript and doms have existed.

~~~
Lerc
The great big bullet point features (like OpenGL) are getting added. It's the
small, subtle features that are being neglected.

The test case that I'd like to see is someone replacing notepad.exe with a
webapp in such a way that an end user cannot tell that a change has been done.
It's the Turing test of usability. Web Apps can do an excellent editor, but
the finer details like (associate *.txt, save, save-as etc.) are still a
problem.

------
mwcampbell
I understand that attempting to write once, run everywhere doesn't make for a
good user experience. For the best experience, it will probably always be
necessary to develop a different front-end for each platform.

However, what does one do for logic that belongs on the user's 'device (i.e.
client-side) and will be the same on all platforms? Especially considering
that one of the targeted platforms may well be the Web.

One solution is to use the Xamarin suite for native targets, and something
like Script# or JSIL for the Web. Of course, Script# and JSIL can only support
a subset of .NET functionality, e.g. no shared-memory threads and therefore no
blocking APIs (unless one of these compilers can transform code into
continuation-passing style). Another possible solution is Haxe, which can
compile to JS, Java, and C++ among others. The trouble with both of these
solution is that when working on the Web version of the app, one has to know
both the Web stack and the other language.

It seems to me that the best solution is to write all platform-independent
client code in JavaScript, minimizing the use of browser APIs for that code
(e.g. only XHR and setTimeout). Then, for the native mobile versions of the
app, integrate a JS engine (note: not a web view), find or write stand-alone
implementations of XHR and whatever other APIs one needs, then write the
front-end in the native language for that platform.

Any thoughts on this? For native mobile apps, are we stuck rewriting
_everything_ in ObjC and Java, and maybe also writing a JS version for the
web?

~~~
chrisdevereux
In case you missed it, this made it onto the front page a while ago:
[http://www.steamclock.com/blog/2013/05/apple-objective-c-
jav...](http://www.steamclock.com/blog/2013/05/apple-objective-c-javascript-
bridge/)

So there are some signs that you might (eventually) get what you want.

It will be interesting to see if anything related gets announced next week at
WWDC.

------
joshbetz
The idea that you have to be a "native person" or a "web person" is
ridiculous. Let's just use the tools that make the most sense for the project
at hand.

~~~
mmahemoff
The idea that you have to be a "law person" or a "medicine person" is
ridiculous. Let's just use the tools that make the most sense for the project
at hand.

~~~
rimantas
Uhm what? If you are law person you deal with law, if you are medicine person
you deal with diseases. How does this apply to the situation where you deal
with apps, only done using different tools?

~~~
mmahemoff
It's all specialisation and one human mind can only do so many things. The web
side alone is vast now. It's a common conversation in the web community about
how a new developer is supposed to pick everything up.

I agree if you're a company, you can't afford to turn your nose at one or the
other. But there's few unicorns who can build excellent apps in all of web,
Android, and iOS. And despite a lot of software mythology, I don't believe
most programmers can just learn a platform in a few days, not to be seriously
capable at it.

~~~
randomdata
I actually thought you were being serious in your previous post. Humans cannot
specialize in everything, but we can do _a lot_ more than just one thing.

~~~
wallflower
In my experience, people who claim to do both iOS and Android development well
vastly overestimate their abilities. At the highest levels, writing an iOS or
Android app is like being a game developer and pushing the platform to its
limits (in a non-hacky way). To attack the problem of smooth scrolling, ~60fps
on a list (especially one doing async fetches and/or database and/or complex
cell layouts) requires different experience and knowledge on each platform. To
build a beautiful app (not an average app) on either platform, requires almost
a craftsman-level touch and level of care. To attack the problem of data
synchronization... don't go there (just use Parse)

------
paul9290
We're currently making a HTML5 web app that works in Chrome and iOS Safari.

It's an audio app (SpeakerBlast) where you sync the same audio across devices;
used to amplify audio amongst friends or throughout your IP devices for
gatherings, flash mobs & playing audio throughout your home!

We feel it's easier for to tell your friends to go to this link to join in
then, "Hey download this app so we can all play audio in sync."

No doubt that the current market says native apps, but this will change within
two to three years. Web technologies are catching up in regards to what can be
achieved via Android (specifically Chrome) and Apple mobile web browsers.

~~~
peterhunt
Absolutely. URLs are the #1 feature of the web that native apps are lacking.

The second being metadata and search engine indexability of the content.

~~~
mmahemoff
It's not entirely true that native apps can't deal with URLs. On Android, they
can handle them well with intents and on iOS, they can at least open URLs of a
certain protocol.

The main issue is that the receiving user probably doesn't have the actually
app. That's the benefit of web presence from a sharing/virality perspective.

------
thekingshorses
I wrote this HN mobile client in less than 3 weekends. it works on Android,
iOS and wp8. Also works on all desktop browsers. It took less than 2 weekends,
but new chrome on android is a big pain in the ass. Had to rewrite part of it
to make it work on latest android chrome.

<http://hn.premii.com>

Also, available on android app store.
<https://play.google.com/store/apps/details?id=com.premii.hn>

It's not easy, but I think you can write very good mobile web app using HTML5
that works on all major platforms.

Just don't use any frameworks/libraries. They are quite slow on mobile
devices.

~~~
AdamTReineke
I'm on Windows Phone 8 and that is beautiful, thank you! Very nice work. How
are you getting the articles in your UI?

Also, is there no meta tag to designate a WP8 tile image when pinned to the
start screen?

~~~
thekingshorses
I have favicon, and tile for windows 8 and neither works for wp8. I googled it
but couldn't find anything regarding wp8 website tile.

------
_k
It all depends on what kind of app you're building. Lots of people are telling
me most apps are crap and they say they use no more than 5 - 10 apps : Mail,
Maps, Messages, Camera, Twitter, Music and the browser. If you're building a
podcast app, then you should absolutely build a native app.

------
aphelion
For me, the big gap between native and web is in UI. Performance is a solvable
issue with either Javascript-native bridges or just devices getting faster.
Even ignoring the Android/iOS "look", I've yet to come across an HTML5-based
framework that can be used to build a complicated user interface with the same
usability as native development. Cordova's great for what it is, but it's
still a tool designed to wrap web app in a thin native shell, not a framework
designed from the ground up to create a strong mobile UI/UX

~~~
gridmaths
You can build any UI with SVG [ so your app = svg + javascript ]

------
zenbowman
The web is very good for some things - its primary role is that of a giant
online encyplopedia that is constantly updated and transformed. It enables
digital collaboration.

This is in fact very close to Vannevar Bush's idea of the memex.

But we are trying too hard to make it good at something that we already have a
good solution for. People forget how much software runs natively, from medical
devices, to airplane and missile control, to celestial navigation and radio
astronomy.

Theres no good reason to webify many of these areas. Ultimately its not the
web vs native. The web is a way for me to write better native software,
through the practice of digital collaboration. It makes possible a new way of
thinking.

------
rayhano
However the web is a great way to start/test user response to a product. For
start-ups with minimal resources and wanting to build the way they know how
(using web technologies), there are now great integrations with 'native'
mobile features, like the camera and music controls.

For a great example, check out the web version of the article's featured app
<http://player.FM>

~~~
mmahemoff
Yes, absolutely. The article's main purpose is to make the native argument,
but there are still many benefits of the web approach, and fast iteration is
one of them.

And not just because of the store submission process (which only takes a few
hours in Android's case anyway). HTML5 has such a rich set of resources, as
well as great desktop browser environments, that it can be a super-fast way to
get projects going. Thanks to Backbone, Angular, etc, and in the future Web
Components, it's easier to scale the architecture too.

Notice all of these benefits are centered around developer experience. User
experience is the biggest gap right now.

~~~
hcarvalhoalves
> Notice all of these benefits are centered around developer experience. User
> experience is the biggest gap right now.

From all the benefits of web technologies, "developer experience" is the worst
one.

Developing (good) UIs using web technologies is an exercise in masochism. It's
forever piling hacks and finding new frameworks to bend a browser to do what
you need (a broken model). Then, worry about cross-compatibility.

Someone proficient in XCode is likely ten times more efficient and produces a
more polished result with much less pain.

~~~
pjmlp
I have been doing mostly web during the early dot com days (1999-2001),
returning to it around 2008.

With every project the conviction that the web cannot move away from the wild
west development style grows on me.

------
RRRA
So embrace and extends tactics of closed platforms attracts people not willing
to wait for the standard process to work its way to the same results, slowing
it down in the process and jeopardizing the future of the open web?

~~~
protomyth
The web has been around for over two decades. In less than two decades since
the Altair 8800, we were programming on NeXTSTEP / OpenStep, Mac OS, and
Window 95. There is no current IDE for the web or web standard that can do
what we did in 1995 much less 2013. That's why developers are using iOS /
Android native apps. Open doesn't matter if I cannot ship what I want and get
the user experience I want. It is actually easier to hit all the mobile
platforms than do a web app of equivalent functionality. Add to that all the
capabilities native apps have over web apps (hey look, sensors) and you get
the desire. This doesn't even count the assurances graphic designers have
going native.

Perhaps, it really is time to look at something past the web for app
development and let the [edit] web [edit] go back to displaying documents.

------
dirkdk
One should be able to compile a web app into a downloadable package, with
capabilities to run the app completely offline. Until that web will always be
second best to fully native. Performance is getting close enough though.

~~~
lukifer
Cordova works excellently for adding offline use to web apps, until the day
that such features are successfully baked into web standards and operating
systems.

"The ultimate purpose of PhoneGap is to cease to exist."

[http://phonegap.com/2012/05/09/phonegap-beliefs-goals-and-
ph...](http://phonegap.com/2012/05/09/phonegap-beliefs-goals-and-philosophy/)

------
ninetenel
I'm a fan of the statement made at the end of this article .. which to me
boils down to that

A mobile web presence is very important and shouldn't be ignored but if you're
going to distribute something as a native app it's silly to build it entirely
in a WebView

also it's wise to never forget that technology changes so fast neither of
these current platforms will be the same in 2-3 years .. so really just pick
something and go

