
Web vs. native: let’s concede defeat - robin_reala
http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html
======
fizk
Remember Flash? Narrow the gap, add a bit of Steve Jobs and Boom! The web Won.

Look at a site like YouTube today. All the tooling we've created and all the
progress of the open web platform that has made that site happen is
incredible. If we've just given up 10 years ago, saying to ourselves that the
web should only be for documents, then we would be missing out big time right
now.

It’s not for every site to try and push the envelope. And mimicking native can
often lead to bad results. But to go from that and say that we shouldn’t try.
That’s just sad.

~~~
the8472
> Look at a site like YouTube today.

And yet any media player beats it at its core functionality: video playback.

Often I find myself using youtube-dl to fetch a youtube video and just play it
in a regular media player because it just works better than what browsers have
to offer. There even are addons to export YT playlists to VLC and stream them.

pdfjs is great. but every 3rd scientific paper I read tends to be somewhat
broken (missing diagrams/images) or sometimes fails to render completely.
native readers provide a better experience and better render times.

>And mimicking native can often lead to bad results. But to go from that and
say that we shouldn’t try.

Maybe sometimes it would be better to provide better integration with native
applications?

Native applications and browsers really don't like talking to each other.

~~~
adamc
I think media playback is only part of the core functionality. The other key
piece is discoverability, and on that front, YouTube is far, far better than a
native media player. It also benefits hugely from urls, which allow users to
share what they've found. So, arguably, YouTube's success is more about what
the web does well than about it's media playback -- it just has to be "good
enough" on that front.

~~~
the8472
> It also benefits hugely from urls, which allow users to share what they've
> found.

how about
[http://some.storage.service.tld/path/to/video.mkv](http://some.storage.service.tld/path/to/video.mkv)
or even rtmp://some.streaming.service.tld/path/to/stream ?

For sharing that would be sufficient.

Of course there are some business realities (ads, copyright, paying for
storage) that make direct, free access to videos unlikely. But that's
basically arguing that the web is a superior platform for monetizing things,
not necessarily a superior platform as far as user-experience goes.

> The other key piece is discoverability, and on that front, YouTube is far,
> far better

I'll give you that one.

But then again there are dedicated media-discovery-sites (imdb, last.fm) that
do not have playback as their core functionality, even though they may offer
some playback.

~~~
wpietri
That's certainly not what I want to share. One of the things that good video
sites provide is context. E.g.: Who made this? What else have they done? How
can I find them? Has this been widely seen? What do people say about it?

Raw streaming urls don't get me any of that. URLs aren't just pointers to
bytestreams. From a user sharing perspective, they're humans pointing to a
unique thing. And what they're pointing to is often much more complex than a
single raw file.

~~~
yellowapple
You could easily address those concerns without turning what should be a
simple video into a clusterfsck of Javascript. For example:

    
    
        https://mytube.com/$username/my_first_video.ogg
    

With such a scheme, you immediately know who made it - $username - and (if
this hypothetical mytube.com built a proper website) navigating to
mytube.com/$username would return a list of videos (maybe with some additional
routes for playlists or categories).

Sure, now the user would have to go through the additional work of editing
URLs if they want to access this endpoint manually, but then this article's
points come into play: if your users expect more functionality than what the
World Wide Web does well - delivering content - then a native app is probably
preferable for everyone involved (and, indeed, exists for sites like YouTube).

~~~
nucleardog
URLs are opaque strings to the typical user.

~~~
yellowapple
My point was that the typical user would be better served with a native app
that turns that URL into less-opaque data.

And even with the URL alone, that's still significantly less opaque than
YouTube's current method of
[https://youtube.com/$some_random_gibberish](https://youtube.com/$some_random_gibberish).
At least someone could see something like
[https://mytube.com/j_random_hacker/how_to_computer.mp4](https://mytube.com/j_random_hacker/how_to_computer.mp4)
and guess that "j_random_hacker" is a username and "how_to_computer.mp4" is a
video uploaded by that user.

This isn't much different from, say, reddit, where URLs are actually part of
normal discussion; a redditor will talk about a subreddit called
"/r/mylittlepony" or a user named "/u/Unidan" or somesuch, directly
referencing paths (to https:/reddit.com/r/mylittlepony and
[https://reddit.com/u/Unidan](https://reddit.com/u/Unidan), respectively).
Granted, reddit's userbase is somewhat more tech-savvy on average than, say,
Facebook's or YouTube's, but it shows that URLs are not necessarily opaque to
typical users, and it's certainly not hard to even manually demonstrate such
things to new users.

This also isn't much different from many (most?) news sites, which provide
URLs that resemble the name of the article (with some adjustment to make
everything lowercase, turn spaces into underscores, strip or substitute
special characters, etc.).

~~~
jsprogrammer
> a native app that turns that URL into less-opaque data.

Like a web browser?

~~~
yellowapple
More like any application that interfaces with a JSON-based API. Those API
calls work by talking to a server over HTTP(S) and requesting something from a
URL.

There's no reason why a native app can't do this - in fact, many native apps
for things like YouTube and Pandora and such _already_ do this.

~~~
mrSugar
But how would that serve ads to the eyeballs? You forget that most of modern
webcontent is just packaging fluff for eyeballs to more easily digest the real
content payload - the advertisments.

~~~
yellowapple
That's not my problem. If it were, I'd solve it by embedding ads in the video
stream itself, which is how traditional video broadcasters have done it for
more than half a century. In the audio realm, Pandora _already_ does this with
third-party clients perfectly fine.

------
pavlov
_I feel we’ve gone too far in emulating native apps. Conceding defeat will
force us to rethink the web’s purpose and unique strengths — and that’s long
overdue._

This, a million times. Mobile websites and mobile apps have completely
different strengths. The current trend is to develop them both with the same
HTML-based toolchains and make them as similar as possible, which ends up
being to the detriment of both.

Users don't want mobile apps that are simply a website packaged up behind the
"icon on the homescreen". Those apps lack the essential benefits of native:
fast and seamless access, smart use of local data, integration with device
services like notifications...

There's nothing more annoying to a mobile user than an "app" that takes 10
seconds to start up because it first loads a browser engine, then makes a
hundred HTTP requests to fill up that embedded browser with content. (And if
the 3G network happens to be clogged, the app may end up showing nothing after
20 seconds.)

For developers, Cordova/PhoneGap-style tools are not a panacea either. It's
easy to get an 80% solution done, but then you run into problems with mobile
browser performance, browser differences between devices (even Android devices
with the same base OS can have very different web view browser engines), etc.
With all that, the last 20% of a Cordova app may well take 80% of development
time, and that's rarely been budgeted in.

Shameless plug: my startup Neonto makes a UI design tool that creates usable
iOS and Android code from visual layouts. It's a great way to remove the
friction in creating real native apps: [http://neonto.com](http://neonto.com)

~~~
thekingshorses
I agree with PPK, but sorry to say this: you are just throwing garbage.

> There's nothing more annoying to a mobile user than an "app" that takes 10
> seconds to start up

Try this on your mobile browser [http://hn.premii.com/](http://hn.premii.com/)

Now download this. Android :
[https://play.google.com/store/apps/details?id=com.premii.hn](https://play.google.com/store/apps/details?id=com.premii.hn)
Or iOS: [https://itunes.apple.com/us/app/hacker-news-
yc/id713733435](https://itunes.apple.com/us/app/hacker-news-yc/id713733435)

And play with it. Download top 5 native HN apps, and launch those, and tell me
which one takes 10 seconds on which device.

No doubt that you will have to deal with different version of webkit browsers
(webview) on android. As long as you follow standards and not use latest CSS
rules, you will be fine. And with Android 5.0+, its much much better.

\---

Now try this page on your mobile, and tell me how bad it is. This is few hours
of work (Flipboard style animation), and works on iOS/Android Chrome/WP8:
[http://reddit.premii.com/#/r/news](http://reddit.premii.com/#/r/news)

There are issues with browsers, but performance is not one of the issue.

\----

It takes time on Cordova not because of HTML, but because how each platform
works natively. I am not a native developer.

~~~
pavlov
I don't see the point of comparing HN apps. HN is a website and doesn't do
anything meaningful as an app.

Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in
low-end devices. It's going to take a while until you can build hybrid apps
exclusively for Lollipop.

If you don't think mobile browsers have performance issues, you must use high-
end devices exclusively.

~~~
thekingshorses
What is meaningful app?

Twitter is list of stories with notifications. For me its more like HN app. HN
has list of stories, Twitter has 140 characters tweet. When you click on the
HN story, you get list of comments or article. When you click on the tweet,
you get replies and retweets and so on.

Facebook is a same thing with pictures and videos. Try this
[http://reddit.premii.com/#/r/pics](http://reddit.premii.com/#/r/pics) \-
enable pictures view from top right dropdown and
[http://reddit.premii.com/#/r/gifs](http://reddit.premii.com/#/r/gifs) to try
gify/video

\---

I didn't start with Android 5.x. I started my app with Android 4.x. I don't
think you use low end Android device. Even native apps on Android has lot of
issues related to performance.

On my Nexus 5.0/Android 5.x, Facebook scroll is not smooth when there are
pictures. I only get non-important notifications from my twitter app.

I test my app in first generation of iPad 2 (My iphone 4s broke) and galaxy
s3.

\---

Now show me 5 meaningful 100% native apps (Non-game) that are not developed my
a startup with a huge capital or big company, available on iOS and Android,
and has 4.x star ratings.

~~~
e12e
Well, lets see, I use _Droidlight_ but that's by Motorola LLC, so maybe
_ColorLights_. _ConnectBot_ (ssh client). _Barcode Scanner_ (I'm not actually
sure if this qualifies as 100% native -- but I _think_ it does). _Open
Camera_. _K9_ (email - there are others, with different strength/use cases).
_ChatSecure_.

Now, these are all Android apps, and few (if any) have iOS versions. But they
all have iOS _equivalents_ \-- and I don't think most of them would've been as
good, as non-native apps.

Note the absence of stuff that works well as a _website_ , like facebook or
twitter. For games, I think the choice between native/html should probably be
governed by the answer to:"Is it as much fun as html/webview?". This is a good
yardstick for other "apps" as well.

For eg hn, there's no need for an app, but of course hn is a pretty terrible
web page. There are a number of easy fixes that would make it more usable,
especially on small screens, but the maintainers don't care. And that's fine
-- it's not accidentally bad, it's intentionally bad.

One could make a similar site that didn't break voting, threading,
screenlayout on small screens quite easily. And it should probably be a web
site.

One can make a "web app" to schedule meetings (see doodle.com) -- and one
could _augment_ that with something native[1]. Or one could make native apps
like the ones mentioned above.

 _Could_ one make a web-rtc proxy for ssh and allow logging in to edit
firewall rules via web browser? Absolutely. I'm not sure I'd want that though.
Not as long as web browser security refuses to learn from office macros:
unsigned js code, all or nothing execution etc.

There is some middleground, as google docs demonstrates. Personally I prefer
content creation/editing to be local, possible to do off-line (with sync) --
and I'd like competing apps to be able to easily share data (via eg: the file
system).

Now, that twitter can't be bothered to make a decent web-site isn't really an
argument against web-sites. It's an argument against poor web-sites.

[1] [http://9to5mac.com/2015/05/14/sunrise-meet-
keyboard/](http://9to5mac.com/2015/05/14/sunrise-meet-keyboard/)

------
mozumder
The web works best as a document platform. All the UI tricks that web
developers work on all end up managing something related to just
browsing/reading a document. It's amazing that modern browsers/HTML just don't
have this basic user experience down.

Why is it virtually impossible to read long articles on a web browser? After
25 years, why do web designers need to create their own page transition
mechanics for long-form articles, for example, when the basic purpose of the
web is designed for reading documents? Why weren't multi-page transitions
built in by default?

The same with photo galleries - after 25 years, why isn't there a standard
user experience for viewing photos related to articles? Why are there a
million JQuery photo gallery plugins?

In fact, why do we need to write CSS to create a basic readable document in
the first place? Why doesn't HTML/CSS default to a high-end and legible reader
experience out-of-the-box for basic text? (proper fonts & spacings, limiting
column widths to 8-15 words max, etc..)

The reader-mode that web browsers are building in, that should be the default
standard UX for HTML, and CSS should build upon that. But instead, it's a non-
standard option.

~~~
jasode
>The web works best as a document platform.

This is only true if you constrain the "web" to mean the Tim Berners-Lee
document-centric HTML and its http hyperlinks.

The "web" also means the whole internet stack, TCPIP, DNS routing, etc. In
that case, the web is a foundational tool for _anything_ that connects people
or Internet Of Things. To say the "web works best as a document platform" is
like saying "the electricity grid works best as a lightbulb platform." We've
gotten past the historical motivations of a interconnected electricity and
have done other things with it.

Do some "native" apps do nothing more than what a 100% static HTML could do?
Yes, abuse of a Javascript widget framework does happen. However, the bad
examples don't mean the "web" should be held back by the original visions of
HTML or Hypercard. The Google maps app is not traditional HTML+CSS.

EDIT: The replies misunderstand my position. I'm not trying to redefine the
traditional technical meaning of "web" and make you like it. I'm attempting to
explain that "the web" has evolved and what it now means to the world out
there. (E.g. see non-document usages like Dropbox, google maps, online Sudoku
games, etc.)

~~~
weland
> The car works best as a transportation device.

This is only true if you constrain the "car" to mean the Henry Ford,
transport-centric engine-and-chassis.

The "car" also means the whole transportation stack: pavement, asphalt, road
signaling, etc. In that case, the car is a foundation tool for _anything_ that
transports people or inanimate objects. To say the "car works best as a
transportation device" is like saying "the electricity grid works best as a
lightbulb platform." We've gotten past the historical motivations of a
horseless carriage and have done other things with it.

~~~
jasode
I'm not saying I _like_ for "the web" to be interchangeable with "the
internet".

Instead, I'm pointing out that the _world out there_ without permission from
any savvy HN readers has moved on. The "web" has become the "internet" for
both documents _and applications_.

It's descriptive, not prescriptive. (See my other replies to illustrate how
usage of http has evolved to coexist with corporate firewalls that lock down
ports.)

~~~
weland
> Instead, I'm pointing out that the world out there without permission from
> any savvy HN readers has moved on.

The world has not moved on. Part of the world has dug itself into a
technological hole. Most of the people who work in it have never seen what's
outside it, so they think the solution to all their problems is to keep
digging.

Edit: crap, I sounded so snarky and aggressive. Sorry about that. It's not
something personal -- I obviously got the point that you don't think
everything about that is a good idea.

The point I'm trying to make is that not ever technological move is
necessarily a "good" evolution. Every narrow street in technology was once
thought to be a superhighway that everyone flocked to.

I remember everyone being so bloody enthusiastic about this whole Web 2.0
thing back then (and I was one of them). Then all this data crumbled as people
paid less and less attention to information structure and semantics and
focused on the flashy stuff. Then it turned out a lot of problems were
intractable if you clung tightly to JS, CSS and the web browser.

Yet for some reason, people thought those problems happen just because we
don't cling tightly enough to JS, CSS and web browsers.

Oh -- and twenty years after operating systems that aren't full of memory
leaks, security problems (eh...) and performance clunks became reasonably
accessible to people everywhere, people are trying to promote ditching those
for web browsers. Which, I would estimate, will need another twenty years or
so to stop having memory leaks, dubious security and privacy practices, and
embarrassing performance clunks.

~~~
jasode
>The world has not moved on.

To clarify, I'm not saying "moved on" as an _objective_ measure of superior
technical progress.

The "moved on" is referencing a descriptive (not prescriptive) state of
affairs with how the world now defines "the web". The existence of sliding
around map tiles in maps.google.com, syncing folders in Dropbox, etc is
evidence that the world does not think of "web" the way Tim Berners-Lee
thought of hyperlinked documents in 1993.

~~~
weland
Yes, but whatever that is should not be called "web", just like we call
"cars"... "cars", not "carriages", though they may look like it.

"The web" is defined by a set of traits (hyperlinks etc.). When whatever we're
doing stops having those traits, it's no longer the web. Continuing to call it
"the web" is not some form of philosophical awareness, it's just ignorance.

~~~
jasode
But "computer" used to mean a " _person_ who calculates" and not a " _machine_
that calculates". All of us call modern day devices with CPUs a "computer"
even though it lost the essence of "human". The usage of words evolve.

I 100% agree that ""The web" is defined by a set of traits (hyperlinks etc.)".

I'm also adding that "web" _also_ now includes expanded perceptions by
everyone else beyond "hyperlinks+http" and that enlarged perception is
unavoidable. We could ask the world at large to *not" call it "web" but that's
like asking us to quit calling "machine calculator" a "computer". Sometimes we
invent a new word, but many times we don't.

Yes, a person uses a "web" browser to read a "document" on New York Times. But
they can also use that same browser to play a Sudoku game that's not a
document at all. To the layman, both actions are "surfing the web".

~~~
weland
By the time _electronic_ computers became widespread, very few non-electronic
computers remained -- and few of them were human. The term was easy to
repurpose.

But the World Wide Web is very much here and very present.

> To the layman, both actions are "surfing the web".

To the layman, a server and a computer are the same thing, and yet calling
Apache a computer is incorrect.

~~~
jasode
>The term was easy to repurpose. But the World Wide Web is very much here and
very present.

And educated programmers call various text styles, "fonts" even though
technically, a font is actually a specific size, and specific weight of a
"typeface". The "font" is a subset of "typeface". Even though typefaces still
exist, almost everyone uses the word "font."

And programmers will also call SQL (without CTE) a "programming language" even
though it's not Turing Complete.

Even binary black-&-white-thinking programmers will exercise a lot of leeway
with how words are used.

I want to emphasize that this all started with my response to the " _web is
best as a document platform._ "

I think most of us can substitute "web" to say "http+html is best as a
document platform." That's what TBL meant.

Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as
reality, what does "web" in "web app" really mean? The "http+html" has become
a universal transport mechanism (with some apps even _tunneling_ through http
to do interesting things.). As the years progress, there are more examples of
http becoming a "dumb and dumber" generic transport pipe for things that are
not documents.

Let's say a startup company wants to create a website to crowdsource music
promotions. They want the service to offer programmable access so people can
write open source clients. The presentation slide / whitepaper will not use
the phrase "internet api". Instead it will use "web api". If every corporate
firewall and user' homes computers with Microsoft Firewall had wide open UDP
ports, it's possible for the phrase "internet api" to have more currency than
"web api". But that's not how history has played out.

~~~
weland
> Today... if we have Dropbox/GoogleMaps/Sudoku/etc, with millions of users as
> reality, what does "web" in "web app" really mean? The "http+html" has
> become a universal transport mechanism (with some apps even tunneling
> through http to do interesting things.).

HTTP + HTML does not include "the whole Internet stack, TCP/IP, DNS routing
etc.", as you mentioned above.

~~~
jasode
You're right. 1000x I agree that TBL's http _specification_ and the html
_specification_ is not TCPIP and DNS.

However, that wasn't the level of conversation I was trying to have.

There is _another viewpoint_ of http+html that is _not the specification_.
That viewpoint is the _usage_ of http/html/TheWeb.

For example, the White House is building made of stone. It is not a human. So
how can newspapers say "the White House has signed the Internet Freedom Act
into law." Well, we're not getting anywhere going round and round in circles
insisting that stone buildings have no agency to pick up a pen and sign a
document and that only a human like President Obama can do it. There are
multiple meanings of "White House" and we seem to get along fine with it.

There are also multiple meanings of "web." It's possible for the industry to
invent a totally separate word besides "web" for the abuse/reuse of http+html
as a transport for apps but that didn't happen. If a startup in Silicon Valley
has a goal to release an app that makes use of TCPIP+DNS with the best chance
for wide adoption, they can entertain the idea of using a custom UDP+port
scheme... or they can just piggyback on http. They didn't use http as Tim
Berner-Lee's specified in 1989. It's the out-of-spec _usage_ that's adding new
color to what modern "web" means.

I'm not saying I approve of it or it's technically superior. They didn't ask
TBL's permission for it to evolve that way. Is it anyone's fault?! Too late to
assign blame now. It is what it is. The phenomena I described above exists no
matter what label we give it. It would be awesome if another word besides
"web" described it but it doesn't exist (yet).

If the "White House" can act as a synonym for "human", it's not impossible for
"web" to act as synonym for "whole internet stack." (Again, the synonym
mapping is using the _other_ evolving definition of "web" instead of the
official RFC specifications.)

------
dasil003
I get where he's coming from, but I don't think it gets to the root issue:

Why does everything need to be a "rich experience"? Note I didn't say app-
like, because many apps themselves are straightforward.

If we don't make that distinction then we risk throwing out the baby with the
bathwater. He cites having to build "2 native apps" instead of one website,
but that's only true if you ignore everyone who is not on recent versions of
Android or iOS (certainly you're not going to support iOS < 5, right?).

The web is no-install, ubiquitous and accessible in a way no platform has ever
been and which is impossible for any proprietary platform ever to be, and is
backwards-compatible. Given these strengths, the effort to bring app-like
functionality to the web is well-founded, because difficult though it may be,
the converse of bringing the web's benefits to native apps is just plain
impossible.

If when marketing wants to create these experiences we tell them to go native
we're just shoveling the problem off to the poor native developers. The first
step should be determining the value of said "experience", is it there to
serve the user or is it there win awards?

~~~
Too
The no-install, and especially the sandboxed environment, is an argument that
hasn't been discussed much here yet but which i think is a big factor to take
into account. Sure, device and browser compatibility is nice but really, being
able to open a news site without having to share my contact list, my location
and my photo album is what makes the web a no-brainer.

If native installs could cater more for this scenario it could win some more
ground, especially on windows, there you have no control at all over what goes
into your machine. Android Play store and and Apples App store would also need
to improve on this. They pretends to have support for it but the permission
categories are all to vague, they are either all or nothing, and they have
been abused to the point where nothing can be trusted any more.

~~~
zokier
Java offered no-install sandboxed apps well before the webapp craze. But of
course being based on Java made that attempt quite stillborn.

[http://en.wikipedia.org/wiki/Java_Web_Start](http://en.wikipedia.org/wiki/Java_Web_Start)

~~~
sceutre
Well it still exists and is actually great for distributing Java desktop apps
inside a corporate intranet.

But it never caught on because it was a poor implementation of a dubious idea.
It started up many hundreds of time slower that Flash, required you to context
shift out of the browser, was pretty ugly, and obfuscated the fact it was
getting unrestricted access to your machine behind confusing security dialogs.

I think the underlying programming language was the least of its concerns.

------
UUMMUU
This is probably going to be an unpopular opinion but I think the current push
to make native feelings apps in JS is awesome. Playing with an app like
Untappd and then realizing it's written by (at least originally) 2 people and
still feels fluid is incredible. I've also never heard anyone except
developers complain that it's not app-y enough. True things like games
shouldn't be written in phonegap or react-native but I think to say that we
should completely stop trying to build any native-feeling apps is wrong. I
actively push anyone interested in turning their app idea into a working
prototype use Meteor or React-Native or just straight up phonegap and if they
get traction they can do what facebook did and rewrite.

I know this flies in the face of this article but I just don't think we should
stop trying.

~~~
capkutay
This may not be in line with the author's point, but I agree with you. You
probably don't need to build a super optimized native app to launch your MVP.
Developers should use whatever tools they're comfortable with for getting the
job done. In the event that they get thousands of users and need to scale,
then they can think about hiring people to build native apps.

------
kenjackson
The web already won.

When was the last time someone told you about an app idea and you had any
vision of a Win32 (or WPF) app? The web is the defacto app platform for
desktop today. Sure, there are some legacy and niche apps that are native on
desktop, but mostly everything new is web based on desktop.

Mobile is a different story, but I think its due mostly to the fact that
mobile HW is still changing rapidly. New sensors and other capabilities to tap
into, where a standards web has to catch up. But I think this gap too will go
away as mobile HW matures.

~~~
vezzy-fnord
_When was the last time someone told you about an app idea and you had any
vision of a Win32 (or WPF) app?_

What does a specific widget toolkit have to do with native applications in
general?

 _Sure, there are some legacy and niche apps that are native on desktop_

People still use office suites, raster and vector graphics editors, CAD, 3D
modelers, meshing and texturing tools, media players, P2P clients, text
editors, various format readers and writers, etc. that are largely dominated
by native.

Even most non-HTTP network clients (like IRC and FTP) are still predominantly
used as native apps because of the far superior experience they bring.

~~~
kenjackson
You went on to list a bunch of niche app classes except for two:

1) Office suites --> Largely a legacy app suite... and web use is increasing
for both Office and due to Google Apps.

2) Media Players -- Playing local media is done by native apps, but that is
becoming an increasing niche scenario. I posit that Netflix, Pandora, and
YouTube dominate other media players.

The most important native app that most people use is their web browser. :-)

~~~
vezzy-fnord
I'm sorry to say, but your definitions of "niche" and "legacy" are extremely
heterodox and I can't have much of an argument under these semantic
constraints.

~~~
Joeri
By legacy I suspect it is meant that the category is finalized in its current
form. All major new software will be web-based, and the only desktop software
being made going forwards is the one which was already being made. Office and
photoshop aren't goin anywhere soon, but the competitor that replaces them
will be web-based.

Not that I think it's particularly true. I think the desktop form factor is
going away, but what replaces it is not so much web as it is responsive /
adaptive, and web is a subcategory of that, with mobile being another. Having
a UI which is only usable through keyboard and mouse sitting behind a desk
just doesn't cut it anymore.

------
pjc50
Four points:

a) Tooling: yes, it's still much easier to debug a native app than a pseudo-
native app.

b) "Emulating native leads to bad UX": this section is absolutely right. Stop
hijacking scrolling and building in cruft.

c) "Hassle-free web": absolutely right. You don't need an app for that. Just
give us the information and let us have the basic interaction we want. No, you
shouldn't present your menu as a PDF either.

d) News: this is where I disagree. Users don't go to news sites so much; they
go to aggregators which link them to individual articles (reddit, facebook).
It's hard to deep-link into an app. This is a case of the app existing to
further the commercial needs of the content provider (increase lockin, ads and
tracking) in direct opposition to the wants of the user.

People keep trying to make the "magazine app" happen, and I've seen very
little evidence of it working.

~~~
Margh
> It's hard to deep-link into an app.

Disagree. Case in point: steam://friends
[https://www.iana.org/assignments/uri-
schemes/prov/steam](https://www.iana.org/assignments/uri-schemes/prov/steam)

/s/ steam for news://home or news://business/26-05-2015-oil-prices

The content could (and definitely should) still be html, obviously not
everybody you link to is going to want to install the news app and it should
fall back to opening in a browser, but if you want to wrap a fancy interface
around what should just be text there's your solution.

~~~
pjc50
Which newspaper's app would the newspaper:// URL link to? It's certainly
_possible_ to do this, but it's often done badly. And if the app doesn't
display its URLs, and they're not made available nicely in its "share"
functionality, then the user isn't going to be able to work out how to refer
to the article.

Also from that link: "Security considerations: Unknown, use with care." Great!

(news:// is already taken by Usenet NNTP to refer to articles by ID)

------
virmundi
What about the benefit that the web brings to updating the user's install? I
know that it is technically possible to push a new Java or .NET app out to
users.

I've done it. The one thing it requires is a lot of coordination. Notify the
users to keep their equipment on the network from time X to Y. Notify the
infrastructure team to schedule a push. Have the dev team on standby in case
the push goes bad. Have the software protect itself when inevitably someone's
install is corrupted or skipped.

Compare that to the web. User opens Chrome; they get the new app. No push. No
real notification of any team. Hell, Ops probably doesn't have to be notified
if they automated web app deployment to servers. The whole thing is very easy.
Even if you have the added complexity of a Chrome-app wrapper, still pretty
easy.

Given the ease of deployment and the mitigated risk of data corruption due to
version issues of the app, the web looks pretty good. Given the advancement of
hardware and software, UX can be close to native. If not native, app-y for
lack of a better word.

If it lacks UX for _native_ , don't target native. Target app-y. This is
between native and document. It might become complex to manage local state,
but that shouldn't be a deterrent.

Tangentially related, to the general question: does the user want to have a
link to your product on their desktop? The answer is probably no. They want
easy access to your product, but the link conflates how this occurs with a
sense of permanence. Your app is not the product. Your app is tool to get the
product: information. UX and installation are both just means to the end.

~~~
eloisant
To be honest, Google takes care of all the complexity to have apps updated on
Android. It's even better, because you can do a stage rollout really easily
(i.e. just deploy to 10% of users, then 20%, then 50%, etc.). It's possible to
do on a web app but you'll have to do it manually.

You still have to push the apk and stay alert for the feedback, but you have
to be careful with web apps update too anyway.

I'm not sure about Apple because it appears the auto-update process is not
that smooth and people don't upgrade their app as often as Android users.

~~~
frik
Auto-updates are great except in the rare cases where they aren't at all.
Picking up my phone in the morning to recognize that it lost half its battery
in the night due an extensive auto update and being left in the cold with a
10% battery (instead of 60%) isn't that great.

Beside that I think virmundi above has his points, and I agree with him. App
updates are not instantaneous.

~~~
jpadkins
i think the default setting for new android releases is only update on wifi
and plugged in.

~~~
s73v3r
I looked, and you can tell it to only update when on wifi, but the Play Store
has no setting that I could find to only update when plugged in.

------
nailer
The headline is a little misleading: the article isn't about not using web
technologies in favour of native apps - Instagram, for example, uses HTML5 for
most of it's UI (you used to be able to see the error pages) and has great UX
- but rather a call to stop making 'native app like web sites'.

> Our working assumption has been that all web sites should be app-like, and
> therefore tooled up to the hilt.

I don't think that's true. Some people create horrible scroll jacking
functionality for whatever reason - maybe they thought it was more 'native app
like', maybe they just thought it was clever. But many other web developers
already consider that bad perf is bad perf and aren't willing to put up with
it.

------
z3t4
So the customer/users want a native app!? Fine, I'll just bundle the web app
with Webkit (io.js) and they'll be happy, and I don't have to worry about the
app breaking in new browser versions.

Browser based applications are much easier to distribute and adds a security
layer, so that you do not have to worry as much about trojan/viruses, compared
to installing executables from cr4cksnh4cks.com

The browser is the perfect container. And it also helps a bit that the API's
are super easy to work with. Making even the novice programmer productive and
able to create powerful applications.

One reason why native is bigger on the smart-phone market is that Google,
Apple and Microsoft want to completely control their ecosystem and lock people
in. What I can not understand though, is why Google does it, as the majority
of their income still comes from the word wide web. They have however made
major advances on that front lately, to there is still hope.

As the virtualization technology advances, the gap between running on bare
metal and in a container continuously decreases. So there will be little
incentive running native/bare metal in the future.

We have a long way to go though. If you want to build something that make full
use of the hardware, you still should go native. But I hope that changes in
the future.

~~~
wvenable
> And it also helps a bit that the API's are super easy to work with.

Not in the least, you have to be comfortable in a half-dozen technologies at
least to make a half-decent web application. You want performance, animations,
etc then you better be an expert. And even then, your perfect container is a
limited container.

By comparison, building a native app is much simpler. The complication comes
in with cross-platform applications.

~~~
drew-y
I disagree. I'm still a fairly new developer and I've tried developing both
native and web apps. I found that there are thousands of great well documented
frameworks that make developing web high performance web apps easy. Meteorjs
for example took me about a weekend to learn, has a huge community with lots
of prebuilt packages, and countless tutorials that make implementing smooth
animation incredibly easy. Before Meteorjs I used Angularjs and found mostly
the same thing. I'm sure it's similar with React or even just standalone
Javascript Html and CSS3.

~~~
mattdeboard
> I found that there are thousands of great well documented frameworks

thousands, absolutely. great and/or well-documented? Unlikely

------
onion2k
Unless you're making something that needs _really_ good performance (3D gaming
for example) building a hybrid app wins every time. Something based on Cordova
(eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the
performance of a native app, with about 1/2 of the development time because
it's all built with web technology. 90% is easily good enough for most
applications. Cordova wraps a uiWebView in some boilerplate to make a web app
_effectively_ native to give you the 'icon on the homescreen' advantages
(selling the app, in-app purchases, access to most phone APIs) with all the
benefits of building for the web (easy development, lots of developers, etc).

~~~
frou_dh
Is a "win" for the developer necessarily a win for the users? Whose experience
takes precedence?

~~~
wolf550e
If cost of developing app is halved, many more apps will be built. The choice
is often not between "expensive native app" and "cheap hybrid app", it's
between "why is it so expensive? but I can afford this (hybrid app)" and "no
way that's too expensive (native app)".

~~~
dottrap
In theory, this might be true. In practice, I find that it is just an excuse
to cut corners and ignore the problems.

I recently had to help somebody with their public library and a particularly
magazine publisher for digital issues. They require a web app to read the
issues. They were trying to use their Mac, but the site refused to load. The
public library staff had no clue why it didn't work ("well, it works for us",
and their attempts to contact the publisher was your stereotypical tech
support horror story.) Long story short, their website doesn't work on all
browsers. They implicitly know that it doesn't work in Safari because they
apparently wrote a native app just for iOS. However, they have no native app
for Mac and never bothered to fix their website.

------
shawnreilly
It does not matter what platform you choose (web or mobile), bad developers
develop bad software. For every horribly designed, slow, bloated website you
find, you can likely find a similar horribly designed, slow, bloated native
app. I'm sure you've heard of garbage in garbage out. I view development as a
craft and like most crafts, not everyone has the same level of skill. This
does not reflect on the platform people choose. It reflects on the people
themselves, their time investment, work ethic, priorities, approach,
methodologies, etc. Like with most crafts, there is usually more than one way
to accomplish something; some more eloquent than others. At a very basic
level, both web and native apps share many commonalities; some sort of UI
being rendered and interactions with data via API calls. As long as you can
reach your goal, does it really matter how you got there? How about this; the
debate is ridiculous. They both rock (or suck depending on your perspective).

~~~
robmcm
> bad developers develop bad software

I whish this phrase would die and be replaced by bad "teams" produce bad
software. I have worked on some projects with fantastic developers, but awful
or no UX, or a misguided vision, rushed to market etc etc.

I have also worked on projects with awful awful code base but the end product
is actually alright (so long as it doesn’t need any maintenance).

Perhaps we should flip it on it's head and say, "good technology doesn't
guarantee good software".

------
downandout
If we "concede defeat" of the mobile web, then we wind up with only content
and functionality that has been approved and can be killed on a whim by Apple
and Google. Wars have been fought over freedom of expression, and now we have
voluntarily given two companies and the governments they answer to the power
to crush anything they don't like, based upon cryptic and arbitrary
guidelines. That is a truly scary world.

Like many things, native is perfect in theory but in practice comes with
massive drawbacks. A happy medium may indeed exist, but "conceding defeat" of
the mobile web isn't going to get us any closer to it.

------
Navarr
> Native apps talk directly to the operating system, while web apps talk to
> the browser, which talks to the OS. Thus there’s an extra layer web apps
> have to pass, and that makes them slightly slower and coarser than native
> apps. This problem is unsolvable.

But what if the browser __is __the OS?

I agree with the point though that we shouldn't be trying to emulate native to
the T with web applications, that we shouldn't be stuffing them full of
JavaScript. I think the Google IO 2015 web app [1] is a good example of what
can be done on the web _right now_ with minimal overhead.

1: [https://events.google.com/io2015/](https://events.google.com/io2015/)

~~~
EliRivers
_But what if the browser is the OS?_

Then the user has chosen, for whatever good reasons, to run a pretty limited
OS, and in doing so has chosen not to be able to take advantage of all the
things that having a much less limited OS would offer.

~~~
Navarr
> "run a pretty limited OS"

This is only true right now and only if browsers were not working to make more
low level stuff available. There is very little limiting about being in a
browser these days. Drivers, perhaps. Kernel stuff, perhaps.

But as far as a game is concerned? Or an email application? Or anything in the
context of this discussion? Not too much limiting them.

~~~
EliRivers
_This is only true right now_

It will always be true forever, or at least for as long as a web browser is a
program run within an actual operating system.

It's not a competition. Pick the right tools for the job. If the job is
getting your eMail or playing a relatively simple game, and a web browser
abstracting as an OS can support your needs, knock yourself out.

If the job is something a bit bigger than that, use a more powerful OS.

~~~
netfire
Take a look at what's currently available in desktop web browsers: maps,
document and spreadsheet editing, highly interactive charts, video
conferencing etc. (things previously thought impossible/impractical for a web
browser to do) If you need huge amounts of data to even run your application,
the argument to go native makes some sense, but the browser (even on mobile)
isn't as inherently limited as the article describes.

Lets not try to limit the web, but try to make it better and then let the
users decide which they would prefer to use.

~~~
EliRivers
_I 'm_ not limiting the web. _You 're_ not limiting the web. The web _has
limits_. Actual, hard physical limitations (along with confidentiality and
privacy limits); limits that something running entirely locally, directly with
your actual operating system simply suffers, and will always suffer, to a
much, much, much lower degree. Your opinion (and my opinion) is meaningless
when confronted with actual, physical reality.

Right tool for the job. That's all.

~~~
netfire
Besides having to transfer data to run the application in the browser, what
limitations are inherit in a web-based application? (I acknowledged the data
transfer limitation in my previous comment).

Browsers (especially mobile browsers) are unnecessarily limiting what can be
done on the web. Adding additional permissions could enable browsers access to
more system resources and components, especially on mobile.

Could you provide some examples of applications that don't require a lot of
data that couldn't be run in a web-based environment, because of physical (and
not current browser or software) limitations?

~~~
Navarr
Doesn't even necessarily have to transfer data with web workers, service
workers, caching, etc.

Google IO 2015, I believe, stores it's data so that when you load it up it
loads from a cache that it's service worker will reload once you have it open.
Allowing it to work offline and removing the cost of transfer at the
beginning.

I _believe_ , not 100% on that.

------
dfield
The author is correct that modern web applications are hacks all the way down.
It's crazy sometimes. But it fucking works!

Look at Google Docs, which has changed the way teams collaborate. Look at
Unity which recently ported their player to the browser. Look at the Autodesk
123D suite.

With technologies like WebGL and Emscripten, we're just starting to see the
tip of the "native on web" iceberg. And it's awesome. I know because I'm
helping build the iceberg... :)

~~~
fixermark
And yet Google Docs on a mobile device is a native app, not a web site. The
website experience is significantly degraded relative to the native app.

It's awesome on the desktop though, but there are frustratingly good reasons
that Google couldn't just run that code on phones and expect it to be anything
other than a terrible experience.

~~~
MBCook
> It's awesome on the desktop though

Not in my experience. I've never had a native app pop-up a dialog saying "You
can't use that menu to copy and paste, you have to use the keyboard shortcut."
Instead, the standard platform way of doing things _just works_. Then there is
the fact that Google Docs just refuses to open certain docs in certain
browsers.

It's impressive for something on the web, but it's not better than a native
app by any stretch.

------
thomasfoster96
Perhaps what we really should be thinking is that 90% of applications can, in
theory, be made using either web standards, native or a mix of both.

Unfortunately lots of websites and web apps are not very well developed. They
serve bloated HTML that hasn't been minified, let alone compressed. The page
is unresponsive or blank until a dozen JavaScript files have been loaded.
Hardly anything is cached. jQuery is loaded to do select a single element and
animate it when CSS would have done.

Most well written, architectured and developed web[site|app]s will not be too
different in UX for end users than a native app. Sure, you can't write a great
60 fps first person shooter game for the web, but there's nothing saying you
shouldn't be able to create an RSS reader or photo sharing app or social
network or anything else with either the web or native.

~~~
castell
> Sure, you can't write a great 60 fps first person shooter game for the web

you can, you know WebGL is hardware accelerated and there is Asm.js - even the
Unreal game engine runs in Firefox and Chrome.

~~~
thomasfoster96
I doubt you'd get a very good, highly detailed game running at 60fps with
WebGL and asm.js today. Nothing comparable to what you'd get running well on a
console. Maybe in another couple of years, but not today, and by then we might
have non-web platforms doing 4K 60fps with ease.

But a lot of games do run quite well using WebGL. Just not the jaw-droppingly
realistic ones.

------
dgreensp
Telling mobile devs not to use web tech is an example of where this argument
(request? demand?) falls down. There are a lot of advantages to using web tech
(cross-platform, easier to develop, easier to push updates), and the result is
not necessarily worse; it may be better. CSS is a very expressive and powerful
layout language, for all its rough edges. Apple uses WebViews in their own
apps (like the mobile App Store app).

The rough edges of web tech will only get smoother over time.

~~~
gedrap
>>> There are a lot of advantages to using web tech (cross-platform, easier to
develop, easier to push updates)

Yeah. This shouldn't be overlooked. In some cases (solo founder, bootstrapped,
etc) a hybrid app might be a great choice for v1.0. Sure, it won't be fast on
the phone... But it probably will be pretty fast to develop and release on
multiple platforms. Especially if you don't have experience in iOS/Android dev
but plenty of background in Web. Sure, if it gets traction you should rewrite
it in mobile at some point. But as a prototype, I am totally cool with
hybrids.

I'd guess these are not the cases that the OP meant, but still I wouldn't say
that the web lost. It has fair share of use cases.

~~~
dgreensp
I think quite a wide variety of app devs might find it more important to be
able to, say, develop an app faster than have a snappy start-up time,
especially if there's no fundamental limitation at play but just limitations
of the current tools!

I trust app devs to choose the best tools for the job.

------
sixQuarks
If native won, then why didn't "native" desktop software win? Everything on
desktop has moved to SAAS and on the web.

We're being way too short-sighted here. In 5-10 years, I don't think
smartphones will be the primary way we get information anymore. Yes, we will
have mobile, but it might be mobile VR, with an infinite canvas.

I think the reason native works well on mobile today is simply because there
isn't much room to work with. Once the viewports start getting larger again,
the web will take over.

~~~
JoeAltmaier
Disagree. Currently I'm running Audacity, Sococo (network conferencing tool;
soon to be a web app), NetMon, Outlook, WeatherEye and a few services. Also
have 3 browser tabs open.

So from here it looks like native apps are winning. Especially since I despise
two of the three web apps (TeamCity, Jira) for being laggy, buggy and very
slow.

~~~
sixQuarks
OK, but are you a mainstream consumer? No, you're a developer and have
specific needs that are solved better with native desktop software.

~~~
JoeAltmaier
True, but ALL the web apps I use are laggy, slow and annoying. Its unlikely
that developers have the only bad web apps.

------
sytelus
Web APIs are in essence becoming an abstraction layer between OS and
applications. It's not just about browser anymore. Browser is just one of the
host for these APIs. In next decade or so, we should have all the power built
in to standards that eliminates pretty much any advantage that native
application can possibly have - even for heavy duty 3D gaming and offline
video editing scenarios. Web APIs will and should become the standard way of
developing apps across platforms. There is neither a theoretical reason that
this is impossible or any other viable alternative agreeable among OS
providers.

There is nothing to concede or regret about. It's just how things evolve. Get
over it.

~~~
the8472
> Web APIs are in essence becoming an abstraction layer between OS and
> applications.

Terrible ones at that. In native applications you can bypass abstraction
layers when you need it. In a browser you are restricted to a almost comically
crippled version of what any native APIs provide.

Look at the <canvas> API. It's fairly modern, and yet I can't even turn off
premultiplied colors, which I would need for doing even semi-decent image
processing.

server sockets? udp? no dice.

even the most primitive file management? with the file API i can open
individal files now. But can I grant a website access to some cordoned-off
subtree of the filesystem? No. Which in turn gives rise to "store everything
in the cloud" mentality, because there are no alternatives.

~~~
TazeTSchnitzel
> yet I can't even turn off premultiplied colors

What are those? If you're talking about alpha, that can be bypassed.

> server sockets? udp? no dice.

The web platform doesn't allow protocols which bypass its security model,
sure. But you do have other ways to communicate, WebSocket (over TCP) and
WebRTC (over UDP).

> But can I grant a website access to some cordoned-off subtree of the
> filesystem?

Not yet, but you do have your own filesystem.

~~~
the8472
> But you do have other ways to communicate, WebSocket (over TCP) and WebRTC
> (over UDP).

which brings us back to the crippled versions of the native APIs.

~~~
TazeTSchnitzel
Well, there are some security restrictions, yes. But for most web applications
they are not an issue.

------
piyush_soni
The article, when talking about the simple 'Technical' reason why web can't
beat the 'native' falls flat. When most people talk about 'Web', they just
mean 'Browser' \- and a browser _is_ native. The extra layer, yes, the
rendering engine/JS framework - how are they very different from JVM and XAML
in theory? Both add an extra layer. Are Android apps not native according to
the author because it adds a layer too?

------
meesterdude
I'm a web developer with a side project. I don't have the
time/energy/knowledge/bandwidth to implement native apps for IOS and android.
But I CAN make it work well enough in a mobile browser.

And lets not forget: developing for android is hard. You have a variety of
models, with varying versions of android, running on different carriers; i've
read some horror stories, and no thanks.

I'm quite quite happy developing for the web and keeping it on the web. I
don't have to answer to any gate keeper or ask for permission for a new
release. I don't have to share 30% of my profits, or be careful about
implementing native functionality.

They just need a browser that can render HTML/JS/CSS. That browser will only
get more optimized over the years, the network will only get faster, and the
technologies to optimize the web for mobile will only increase.

I say more web, not less.

------
orthecreedence
I agree that if you have the resources to build something on native, go right
ahead. But as someone who has very limited time to work on a passion project
([https://turtl.it](https://turtl.it)), I will be damned if I split up my
efforts writing different apps for iOS, Android, and desktop. Thanks to things
like Cordova, node-webkit, and various other tools, I can write my
interface/logic once and run it everywhere (with a bit of wrapping).

No, it will not be perfect. Yes a native app would perform better. But I don't
think my users (who continually ask me for a mobile app) are really going to
care _that much_ if the page transitions jump a tiny bit. And once Safari
pulls its head out of its ass and supports AES-GCM in its WebCrypto
implementation, I can do fully-native crypto in my app, and the largest
performance hit goes away.

HTML5 is the poor person's write once, run everywhere. Although not perfect,
it continually strives to be better. It enables someone like me, who can only
work nights and weekends, to build something useful and usable for a lot of
people in a minimal amount of time. If people don't like Turtl mobile because
it doesn't have seamless transitions, they can use Evernote instead and have
their plaintext data leaked all over the web.

------
castell
This article feels dated. If he wrote it in 2011, I would agree with him.

Web apps don't try to recreate the native UI anymore - something that used to
be the case some years ago in the iOS1-6 era. Nowadays the UI of Android 5+,
iOS 7+ and WinPhone7+ look very simple and Web-alike.

Simply avoid bloated outdated big JS libraries and use a minifier to shrink
the JS and CSS files.

I thought the trend reversed as many little commerce switched from offering a
Android/iOS app to a mobile-friendly website. This may not be a global trend.

quirksmode.org used to be great resource in the IE6 era. Nowadays
[http://caniuse.com](http://caniuse.com) and Mozilla's MDN have replaced it
completely for me as it offers up-to-date information.

~~~
TazeTSchnitzel
Don't just use a minifier: use something that can eliminate dead code, like
Google's Closure Compiler in advanced mode. Don't ship 10MB to the client if
you only need 1MB!

------
wwwtyro
One point I've not seen mentioned yet is that the web is a fantastic
distribution platform. Given the option, I'd much prefer to have written my
molecule rendering project[1] on a native platform, but I'd get only a
fraction of the users I get when deploying to the web. The activation barrier
for native apps is just so much higher because of the download/install/launch
process.

For now, the URL click is king, and it's hard to beat easy when you want
people to use what you've made.

[1] [http://wwwtyro.github.io/speck/](http://wwwtyro.github.io/speck/)

------
codingdave
I really don't know anyone who carries on these kinds of arguments. In my
experience, we code for the web most of the time, because it works and is
usable by most people on most devices. Once in a while, we have a compelling
reason not to. When that reason comes along, we code a native app.

It isn't a competition between platforms, and we aren't trying to make them
look and act the same. We just pick the platform that offers the simplest
workable solution.

Maybe I just run in a more pragmatic crowd...

------
bcg1
I think that a title of 'Browser vs. Native' instead of 'Web vs. Native' might
be more accurate, since the web is so much more than just a UI... most 'apps'
I think are just web apps with a 'native' GUI, not disconnected applications
in and of themselves.

PPK ignores the original reason that the browser won so long ago though... it
is the universal GUI for the Internet. We've had access to 'native' extensions
for web apps for a long time (Java applets, Flash, Silverlight, ActiveX, etc,
etc), yet these things are all but dead. Eventually the Apple vs. Android war
will probably go nuclear, and users will demand that things 'just work' too.
If its time to revisit this conversation, then fine... but there is nothing
new under the sun.

------
datashovel
This post leads me to believe the author probably assumes there will always
only be a handful of native platforms. I think, if we're lucky, the ecosystem
will be far more diverse.

In the future I envision, noone in their right mind would ever think native is
the way to go.

~~~
pdpi
Answer me this: What is the point of a plethora of platforms, if nobody in
their right mind develops native?

~~~
datashovel
It seems we have different assumptions we're basing our arguments on.

I get the impression that the huge diversity of linux distros is enabled
primarily by the fact that more and more development these days is web and not
native.

~~~
pdpi
You're missing my point. There's no purpose in having a huge diversity of
linux distros, if they're just glorified browser shells.

~~~
datashovel
I'm guessing they all (the linux distros), in one way or another, add value
given each project's mission statement. Or at least they believe they are.
Otherwise they probably wouldn't be doing it.

And I don't think we'd have to fear the OS will become a "glorified browser
shell" if it wasn't the primary "app development platform".

Right now native app development is feasible. You have pretty much 3 platforms
you really need to worry about developing for in order to have access to the
largest amount of market share for the least amount of effort. Imagine even
one more player enters the market and gains any respectable amount of market
share.

Instantly every mobile app development team's efforts need to grow or every
developer on each team's responsibilities grow linearly with the total number
of platforms they need to develop for. From an operational standpoint it's not
sound economics to make business decisions based on approaches that don't
scale well.

------
amelius
> Is it the web’s purpose to emulate native by inserting yet more features?

Certainly not. In my opinion, the problem with the web is that it has become
too complicated. In an effort to make the web simpler for the ordinary user,
the web has actually become a more complicated place for the (advanced)
developer.

HTML, CSS and javascript have grown so complicated that they lack certain
desirable properties, such as verifiable security, flexibility. For instance,
a developer has no choice of programming language, but has to resort to
javascript; we are stuck with the cooperative multitasking of the 80s
(webworkers support only message-passing, no shared state); also, the
developer has no choice of render engine, and to make matters worse, the
developer has to write code that is compatible with about five different
platforms (desktop/phone/tablet). And of course, the fact that those platforms
are not identical is also due to the fact that the web is too complicated.

I'm hoping that in the future, we can make the web more simple and elegant for
the developer. We need simpler primitives, not the complicated and restrictive
building blocks that we have seen thus far.

~~~
to3m
Lack of support for shared state is no disadvantage! When you write
multithreaded programs in a language such as C++ or C#, you try to impose on
yourself the same restriction, in the interests of making your life easier...

(I haven't used web workers, so maybe they're in fact awful to use. But from
what I've read, it looks like the right decisions were made, pretty much.)

~~~
amelius
Why be so protective? Perhaps somebody invents some programming tool that
makes it easy to reason about shared state. This is exactly the kind of mind-
set that makes it difficult to develop for the web.

Also, shared _immutable_ state is a useful (often perhaps even essential)
property for building efficient code in a multithreaded environment, even when
using the message-passing style.

~~~
to3m
Tastes differ. I don't have any problem with erring on the side of
overprotectiveness when it comes to multithreaded programming.

------
joeblau
I just had this discussion a few weeks ago and it wasn't even about mobile
applications; It was about mobile application _testing_ frameworks. We were
deciding between a hybrid approach to testing (Appium) vs native
(UIAutomation). I don't think these types of debates are going to end soon
because most of the decision makers in large companies have grown up with and
love the web. For the most part, I've only seen the web get faster and better
since the mid 90's, but that was limited to the platform of a computer.

The theoretical maximum benefit of writing a program once that runs everywhere
(watch, phone, phablet, tablet, laptop, desktop, tv) and is always up to date
(computing is done in the cloud) is extremely enticing but has serious
performance implications. What you always end up with is a developer friendly
framework that contains cases for each platform and in most cases, doesn't
have all of the features each individual developer needs (Bootstrap, Appium,
Node.js, React, Angular, etc...).

I want the web to win, but in most cases the DOM was not built and designed
for the direction that native applications are going.

------
jorangreef
Browsers need to move from tens of fine-grained permission requests, to "Do
you want to install this web app and give it full access to your computer?".

And from there, they need to stop building abstractions such as WebSocket,
IndexedDB etc. and start exposing raw OS capabilities such as UDP, TCP and FS.
Basically packaging node.js would do the trick here.

Also see Tim Berners-Lee in "Installing web apps":

"If I can't give power to apps, then the web app platform cannot compete with
native apps."

[https://lists.w3.org/Archives/Public/public-
webapps/2012JanM...](https://lists.w3.org/Archives/Public/public-
webapps/2012JanMar/0464.html)

He asks for something fine-grained but the main point is to expose the real
power of a machine to an app if the user so wishes. That's not possible today
with browsers.

Browsers need to stop controlling innovation, and push core services out to
the edges and let innovation happen there. Stop drafting specs for WebRTC etc.
and give UDP etc. back to the people.

If the browsers don't do it, maybe someone will make a new kind of browser
that will with something like Electron.

------
Zigurd
There are several reasons mobile devices made it so that Web runtime and Web
apps would not be the consensus app environment:

1\. Web apps are no longer the answer to breaking Windows hegemony on apps.

2\. The Web is a mouse UI. That may seem like a small thing, but look at how
much trouble Microsoft has had turning Windows into a touch UI.

3\. Mobile devices are the end of overlapping windows. The Desktop Metaphor
was a cute idea, but it isn't appropriate for mobile devices. Web browsers,
and Web apps, are made for resizeable windows.

4\. The Web is great for simple interaction with dynamic content. Which is
another way of saying "The Web is a big, linked, interactive e-reader." You
can stretch it to try to do other things, but it isn't a comfortable stretch.

5\. Pure canvas apps... ... ... </crickets>

6\. No one development idiom. Nor two. Nor five. This is much less of a
consensus than Android or iOS. IOS developers will be making a language
transition, and Android developers will probably incorporate a dependency
injection idiom into nearly all Android coding once a consensus is reached on
what flavor of DI is favored, but that's about it for uncertainty.

------
pbreit
I mostly agree but the one category that does NOT need to be native is pure
(text-heavy) content (i.e., news sites). In fact, it's beneficial to be web in
order to support easy linking, distribution and discovery.

Also, while I agree with the "home page" question, the author makes no mention
of the other important criteria: are notifications important?

------
netfire
Here's the problem: native apps require downloading, updating and take up more
space on the device. I think the mobile web could be much more than it is now,
but mobile web browsers seem be improving at a very slow pace. One of the main
reasons for that is that the creators of the mobile operating systems benefit
more from an app store environment, where they can take a cut of the sales of
an app, so they have little motivation to improve the browsing experience.

There's no reason that mobile browsers couldn't expose more internal access to
components or controls (and UI options) that are currently only available to
native apps.

Do we really want to be restricted to a environment where if we want to
release an update to our app, we have to submit the update to the third party
for approval? (which can take days) and where users have to download your app
to try it out?

We shouldn't concede defeat. We should demand more from mobile web browsers.

------
janl
I’d love to take this discussion offline with a number key people. We have the
Web Technology Fest in Berlin ([http://wwwtf.berlin](http://wwwtf.berlin)
formerly [http://jsfest.berlin)in](http://jsfest.berlin\)in) September
(leading up to JSConf EU & CSSconf EU) and last year we’ve already held and
Extensible Web Summit ([http://lanyrd.com/2014/extwebsummit-
berlin/](http://lanyrd.com/2014/extwebsummit-berlin/)) among dozens of other
events. Here’s a rough draft for what I envision, but I’d need your help to
shape this, so it’s going to be useful:
[https://github.com/janl/wwwtf.berlin/issues/3](https://github.com/janl/wwwtf.berlin/issues/3)

Thanks! <3

------
forgotAgain
The post forgets a lot of the history of why web apps were originally
welcomed: they allowed a choice of platform. Going native undeniably gives a
better user experience. However there is a trade off in developing for a
single platform that cross platform tooling cannot yet remove sufficiently.

------
gwu78
As most nerds know, internet messages or "email", and later Usenet, preceded
the www by a number of years.

The original issue was opening different types of files from within an
internet message.

No matter how browser-centric today's computer users have become (thanks to
marketing) the past remains close to the surface. As far as I can tell, the
original solutions were never replaced; they were just ignored in favor of
"middleware" (for lack of a better term) like Adobe Flash.

In fact today's developers probably are very familar with the original
solutions, though they might not recognize them as as such. I wonder how many
could tell you where the Content-Type: header actually originated from?

What is MIME?

What is mime.types?

What is a mailcap file?

My browser of choice still has full MIME support so I can configure it to
launch other, dedicated programs ("native apps"), based on file extension.

For example, in theory I could launch ffmpeg or a video player (mplayer, vlc,
etc.) from "within the browser" to transcode or play video. I imagine all the
major video-serving websites used or still use ffmpeg in some capacity, not to
mention any "web browser" that attempts to play video itself.

Now the truth is I actually do not use MIME anymore. I prefer to download
video first to my own localhost server using my own scripts and a program like
tnftp, and then play it on any device I choose, with whatever "app" I choose.
I like my video as a file that I can manipulate, not a pseudo "broadcast".

As a side benefit perhaps, I have observed that with few exceptions I never
see any preroll advertising when I download video to a file and then play it.

The only time I have seen such advertising is when using a "modern" browser to
"stream" (or progressively download) video.

Not sure what this means if it means anything but I am happy to avoid the
advertising.

------
archagon
It's clear that the web has outgrown its original intent. Instead of just
being a simple substrate for linked documents, many (if not most) websites are
now trying to emulate applications, platforms, and services using the poor,
ill-suited DOM.

But I don't think the solution is to give up. Native apps are great, but
there's a vast gulf between the binary running on your device and the server
you got it from. Downloading and updating take forever. Connecting to other
apps is barely possible. Everything is horribly siloed. The brilliance of the
web is that it allows people to quickly connect to computers anywhere in the
world and get at whatever stuff they might want to serve; native apps will
never have that level of flexibility, barring some horrible proprietary
ecosystem.

Unfortunately, the web was designed primarily with content in mind, not
presentation. The only way servers can provide interesting and slick user
experiences is to hack up the content presentation system, which is as silly
as using spreadsheet scripting to build enterprise software.

So I think the best approach would be to revisit the design of the web.
Instead of having the web be strictly document-centric, I think there should
be a higher level above that, through which HTML, CSS, the DOM, and everything
else are implemented. A sandboxed, scriptable, low-level canvas that only
gives you the bare essentials, allowing you to create native-quality
experiences without having to piggyback on the DOM or reinvent the universe
via canvas or WebGL. A "Vulkan" equivalent for web software. Not making a
document? Feel free to not use HTML — or only embed it in the parts of your
web-app that actually present content.

It should be possible for a user to go to facebook.com and immediately
retrieve an equivalent to the Facebook app in their browser — smooth
scrolling, gestures, and everything. (Or whatever the future equivalent of a
browser might be.) But if a user navigates to a simple blog, it should still
appear as it does in the web today, because this new web would be a superset
of today's web.

We've been interacting with other computers through a seriously constrained
pipeline this past decade. Instead of bowing our heads and conceding defeat,
why not blow it wide open?

~~~
TazeTSchnitzel
What layer can you realistically have below the DOM? If you get rid of it, how
can you realistically avoid reimplementing everything? I don't think this
makes sense.

~~~
archagon
I think UIKit (and possibly Android, which I haven't worked with) has the
right idea: nested, texture-backed views that can render their own content.

You might argue that canvas and WebGL nodes in the DOM already serve this
role, but I disagree. In their current form, these nodes exist inside the
document-based world of the web rather than containing it, an inversion of
what I see as the proper hierarchy. This arrangement poses a number of
problems for designing rich apps, including very poor performance related to
content reflow. Some companies[1] are trying to fix this by manually doing all
their rendering inside canvas and re-implementing HTML and CSS along the way.
Unfortunately, this is a ton of work and results in a web experience that is
non-standard in many ways, including for things like accessibility and text
selection. The fact that this actually _does_ work to significantly improve
the user experience, however, points to the fact that something needs to
drastically change for the web to remain healthy, useful, and relevant.

My understanding is that the DOM is already implemented as a series of
texture-backed views in many browsers. That would still remain the same —
nobody would have to reimplement this functionality. I just think it would be
a great idea for us to be able to use those same texture-backed views for
custom UI unrelated to HTML and CSS, and to separate the rendering concerns of
text and document flow from the design of user interfaces.

[1]:
[https://news.ycombinator.com/item?id=9029159](https://news.ycombinator.com/item?id=9029159)

~~~
TazeTSchnitzel
Beyond views you need a way to layout them. Would you not be simply
reinventing the DOM?

~~~
archagon
In my experience, HTML-style layout is just horrible for app UI. It's really
much better suited for text. On iOS, you can either use autolayout
(constraint-based layout) or alternatively perform layout manually, in code,
for that purpose.

------
fixermark
I wonder how many of the issues listed in this article could be addressed if
my HTML-based web technologies allowed for a real concept of an "app?"

Right now, we're very much faking it. Every time you go to a website, you're
downloading a document that unpacks into code and data in your client. Caching
aside (because the cache timeouts are never long enough), you have to do that
dance every time you visit. The performance hurdle ppk describes is less about
having to go through the DOM to get to your elbow (though that's true) than it
is about never being able to precompute and locally cache view logic. That's a
performance hurdle that can't be crossed.

In contrast, native apps divide everything quite clearly into "code" and
"data." The code is the app you download from the store; it can auto-update,
but it isn't trying to pull in a new copy of itself from scratch every time
you use it. It can also be pre-optimized for your architecture. The data is
only what is needed for the app to present it appropriately to you.

I'd be willing to wager that if a real standard for downloadable client-side
cached web apps ever caught on, ironed out the optimization issues, and stuck,
quite a few of the performance issues of web vs. native could actually be
addressed.

(Of course, we'd still have to deal with the DOM really being the wrong
language for a lot of high-interactivity use cases, unfortunately).

------
lewisl9029
Rehashing part of my comment from a different article:

I don't see why any reasonable developer would choose building the same app on
multiple platforms over building it once on a standardized platform and having
it just work everywhere.

That is, of course, if the standardized platform had all the capabilities and
great UX of the proprietary platforms. This is where the web often falls
short, and the companies behind proprietary platforms have some very sweet
incentives to keep it that way, i.e. developer lock-in and maintaining
complete control over the platform's direction.

Despite all the impediments, I still firmly believe an open platform will
triumph eventually, because developers love efficiency, and the current
landscape of wasting work on rebuilding for proprietary platforms is anything
but efficient.

In fact, the web is already capable of competing with native in terms of
general UX, not yet quite enough to match or surpass it, but definitely within
striking distance. Just take a look at some of the apps made with Ionic:
[http://showcase.ionicframework.com/](http://showcase.ionicframework.com/)

Additional tip for for Android Cordova development: bundling an external
WebView like Crosswalk makes quite a bit of difference for <5.0, both in terms
of performance and in terms of not having to worry about legacy WebView quirks
for older phones.

~~~
s73v3r
"I don't see why any reasonable developer would choose building the same app
on multiple platforms over building it once on a standardized platform and
having it just work everywhere."

Because it provides a better experience for the user, and because it allows
for access to hardware native features.

~~~
lewisl9029
Yes, but that's a side effect of native _already having_ better UX and more
capabilities.

"That is, of course, if the standardized platform had all the capabilities and
great UX of the proprietary platforms. This is where the web often falls
short, and the companies behind proprietary platforms have some very sweet
incentives to keep it that way, i.e. developer lock-in and maintaining
complete control over the platform's direction."

Given the choice of a standardized platform that offers the same UX and
features, would anyone still choose to develop for proprietary platforms?

That ideal standardized platform doesn't exist right now, but the web is
getting closer and closer to being that platform. It doesn't make sense to
give up all the progress we've made so far and resign to native when the web
is already almost there.

------
anthony_romeo
I've always felt that (with respect to desktop work specifically), the reason
we're in the web-app world we are today was in part due to the stagnation of
window management in the 90's - 00's Windows era. Tabbed browsing for web
browsers was created pretty much to overcome having a gluttonous and unusable
taskbar after opening just a few applications. From then on, I feel users were
primed to want an alternative, which web apps ultimately gave.

Further, to talk about the speed hit associated with web apps, laptops and
desktops are _still_ primarily sold with old-school hard disk drives instead
of solid state (unless you pay a big premium, which most people don't want to
do). Frankly, opening a native application on an older machine (and for most
users, one which hasn't been defragmented even once) was an awful waste of
time. But Google Docs? Heck, you didn't even need to be on the same computer
to access those files. Not to mention trying to update these apps being a
massive chore on these slow machines. Heck, most people didn't ever update
their browsers until Mozilla and Google imposed it upon users.

While I'd like a world where the browser is not an abstraction layer for an
OS, I do recognize that these web apps exist for a reason.

------
bovermyer
The author's argument that news sites should go native and (presumably) forgo
web ignores the fact that the web is highly shareable and discoverable, where
native apps are a walled garden. Ignoring news sites' need to generate revenue
for a moment, the ability for a user to search the web for a particular topic
and discover a relevant news article from three years ago is a built-in
advantage for the web. You can't duplicate that on a native app.

------
jpswade
The best argument I've ever seen is that it's ridiculous to think that there
will be an app for every business, website and device.

Instead, I see a future, like we're starting to see with devices such as the
Synology NAS where the interface is a website served on the device.

Things like the ESP8266 make it possible to add Wifi capability to pretty much
any device.

The future isn't about an app store nor about search, it's about discovery.

------
krick
I pretty much agree with the post, even more — I like to agree with it. But
there's a problem.

The problem is there's no stuff like "web/native app": there's a bunch of
functionality that solves user's problem to greater or lesser extent. Although
there are needs which are technically complex, usually what the user can ask
for is pretty simple. Clean UI, button here, button there, some lights and
pop-up notifications, a couple of graphics, which actually represent something
pretty trivial internally. Sometimes the data needs to be pushed to or
retrieved from some centralized storage or it needs to talk to some other
"service". "Browser" is absolutely awful and pointless invention, but
unfortunately we have accepted it somehow and learned to satisfy the needs of
typical customer using it. HTML might be stupid and CSS might be inconsistent,
but it's actually pretty easy to make the UI user wants with that and a
handful of js code.

As a bonus, it will work on Linux, on Windows, on Mac, your Android phone and
even some not-a-real-OS which happens to have a capable browser.

And what we have on the desktop? I don't know a single good UI framework for
Linux ("good" in a sense it would make it easy to achieve what I want).
There's somewhat usable WPF for Windows, which still doesn't really allow to
implement anything user could wish for as easily, as I'd do with HTML.
Somewhat usable, but pretty verbose is Android UI framework. I don't know what
happens on Mac. And, yeah, none would be compatible between different
platforma (except Qt, maybe, which is overly complicated by itself).

So there isn't much choice between "web and native". The "native" is currently
pretty much non-existent.

~~~
zokier
Have you checked QML? It is kinda mix of "native" and "web".

~~~
krick
Very superficially. I haven't completely understood how much better it is than
the standard layout, but I doubt that it can be comparable with what we have
today in a browser. I mean all the libraries, no need to compile anything,
writing components in a general-purpose high-level language… Even making Qt
friends with Python isn't as effortless as it could have been.

And it isn't the real thing anyway: in order to be a good platform for
building GUI apps all that functionality should be directly provided by the DE
in the first place (like it is in Android, for example). You cannot play with
representation the same way in (say) xfce, as you can in the browser console,
moving containers and changing colors as you like.

------
wtbob
I prefer the experience of native mobile apps (and native desktop clients,
too!), but I prefer the privacy and sandboxability of pure-HTML apps. If a
site is going to add so much JavaScript that it's unusable without
whitelisting it all, then I _almost_ might as well just use a native app.

If Android had ever-so-slightly better permissions, then the clear answer
would be to stick with native apps, period.

------
Thiz
Html is for documents served thru http.

What we need is a language to build apps natively and serve them securely thru
the browser using an app:// protocol.

Working with html to build apps is a nightmare. Google, Apple and Mozilla
should take the best from android and ios and work on something universal and
truly disrupting. No, not java. No, not obj-c. Perhaps swift, go, nim or
something better. Remember the hobbyists.

~~~
Thiz
Forgot to add. Let's use an emulator and not a browser to serve apps thru the
app:// protocol. We don't need bookmarks, toolbars, addressbars, etc. We just
need a surface and an app store, just like a mobil os, with the triangle,
square and circle as universal UI for navigation.

Best of both worlds.

------
nickpsecurity
About time they see it! I've been pushing native, Internet apps over web since
the beginning. The reason: native apps can be faster, leaner, more flexible,
more portable, and more secure. Most things I can do to boost one of these
metrics in a native app I _can 't_ do in a web app. Let's put this in
perspective: my 1998, 200Mhz P2, 64MB RAM machine's native apps did more than
modern web apps and with fewer problems. And could connect to people and use
presentation layers... just like the web!

One writer argued the reason the Web took off was a standard, usable
presentation format (HTML) combined with easy distribution (hyperlinks) and
instant updates (connect for freshest version). This spread across both users
and platforms. Its continual improvements gave it new features. To this day,
the standardization and easy distribution makes it easier to push content to
most users via a web browser.

Yet, even big Web companies such as Facebook are switching to Internet-style
apps for mobile and Internal use. That's saying something. I guess they don't
want around 500 bytes of HTTP overhead to send 1 byte of data. The best
solution is a portable platform that solves the presentation, linking, and
updating issues that web did. There's a number of older vendors and startups
doing this. Hopefully we'll see more take-up and network effects on that side
of things.

Note: Anyone still thinking the Web was the best route to go, but wanting
native advantages, should Google Tannenbaum's Globe distributed toolkit that
supplemented Amoeba distributed OS. They even ported the Web to run on top of
it and side-by-side with its applications. Compare work like that to the web
of the same time period and you'll see why Web is inherently inferior due to
bad (or misappropriated) design. It always will be to a comparable, native
product.

------
pornel
To me the worst side-effect of naively chasing "native" is permission prompts.

The web platform wants to have powerful features that are dangerous and/or
easy to abuse, but haven't found a good way to allow them safely.

The "solution" we've settled for is to _blame the user_ for clicking "OK" on
permission prompts that have unclear consequences to non-technical users.

~~~
Brakenshire
That's exactly the same as iOS native permissions, isn't it?

~~~
pornel
Similar, but the key difference is that Apple can kick the worst abusers out
of the walled garden.

The Free Web can't do that (and I strongly prefer it to remain Free with low
barrier to entry), so it needs a better approach, or needs to give up on
having dangerous features available.

------
tim333
>I think we web developers should advise news sites, and in fact any site that
prioritises features over performance, to go native

As a user, I have no interest in that. On the front screen of my phone I have
the 'google news' icon which is a link to a web page with links other news web
pages. Why would I want 20 siloed apps for the various news sites I visit
occasionally?

------
hypertexthero
Two problems with native applications:

1\. The systems and hardware they run on are usually controlled by one
company.

2\. There's no View Source.

Where would we be if 'native' applications had won over the '[worst is
better][1]' approach of the web? What do you do if you lose your phone and the
only way to get information is through an app that was installed on it?

[Alex Martelli][2]:

> Our culture’s default assumption is that everybody should always be striving
> for perfection – settling for anything less is seen as a regrettable
> compromise. This is wrong in most software development situations: focus
> instead on keeping the software simple, just “good enough”, launch it early,
> and iteratively improve, enhance, and re-factor it. This is how software
> success is achieved!

Good enough is usually good enough and can be accomplished through a web
browser if your design is good and not compromised by 'business decisions'.

There is a place for native apps. Communication applications such as Whatsapp
are a good example. Applications whose main purpose is to provide information,
such as websites, are not.

Finally, lets not forget that the internet is not a thing, [it's an
agreement][3].

[1]:
[http://hypertexthero.com/logbook/2013/07/europython-2013-not...](http://hypertexthero.com/logbook/2013/07/europython-2013-notes/#goodenough)

[2]: [https://ep2013.europython.eu/conference/talks/good-enough-
is...](https://ep2013.europython.eu/conference/talks/good-enough-is-good-
enough)

[3]: [http://worldofends.com/](http://worldofends.com/)

------
carsongross
I broadly agree that trying to completely mimic native apps with the web is
unlikely to yield great results, and the author points out some of the obvious
strengths of web applications (in an update he mentions URLs, which he missed
initially.
[https://www.youtube.com/watch?v=i28UEoLXVFQ](https://www.youtube.com/watch?v=i28UEoLXVFQ)).

I think he underestimates the web, though. In particular, there is one aspect
that he fails to mention and that I view as one of the best aspects of web
development: the stateless request-response-replace-UI model of remote
application development. This model is incredibly simple for developers to
understand and work with, and eliminates a whole slew of complex problems
found in traditional client-server development.

(I would note that these problems are being reintroduced with client-side web
technologies like Angular and de-reintroduced by technologies like
intercooler.js.)

------
RRRA
Giving up on the Web, is:

1) blind to all the progress we've made closing the gap with all the other
platforms

2) Irresponsible to the future by basically saying "let's drop the only open
and common platform we have and let's embrace the corporate fragmented world,
let's relive the 80s all over again just because of some short term
performance issue!"

------
methehack
Doesn't it depend a lot on what you're trying to do? Seems impossible to
generalize to me.

The win is huge if you have a web app that works well as a mobile app and does
so on the same code base. And that does happen, it just doesn't happen every
time -- but I don't think anyone ever said it was supposed to.

------
leecarraher
honestly, thought the defeat was in the other direction. Although I am a
stubborn native app loving, cloud denier, i fear more and more that I am in
the minority. Everything new is web based. It is true that there are
perfomance hits, communication bottlenecks and added complexity to developing
on the web, but i think the biggest hurdles are slightly less obvious.
Security requirements are exacerbated and the size of development units have
grown intractably large. More speed requires better direct HW access but every
time the web wants more, the blackhats push back and take even more. What
happens when facebook advances react, google remodels appengine, AWS
changes... Nothing is static, making the "who broke what" question sometimes
impossible to answer.

------
bcheung
I strongly disagree. Why wouldn't we want to continue making progress on the
web? Where would we be today if cavemen decided spears are good enough so
let's just stop there.

I think the web should continue innovating and that trying to compete with
native apps is a worthy goal.

The web is the most compatible and universal format. There is a lot of benefit
to having a universal development platform. With Node.js the web has been
brought server-side as well. There is a huge convenience factor to being able
to use 1 platform for browser, server, and mobile.

I don't like being locked into a vendor or being uncertain if this platform
will be around 5-10 years later. Having the web around as an app platform
creates certainty that encourages commitment from companies.

------
smhg
This discussion should be about discovery and openness. Not about
functional/technological differences between 2 platforms. Those will evolve.

\- URL's are a great starting point for interactions (see The Physical Web).

\- App stores (in their current shape?) just can't be the future.

------
mromanuk
> Technically, it’s simple. The web cannot emulate native perfectly, and it
> never will. Native apps talk directly to the operating system, while web
> apps talk to the browser, which talks to the OS. Thus there’s an extra layer
> web apps have to pass, and that makes them slightly slower and coarser than
> native apps. This problem is unsolvable.

Really weak argument, it reminds me of High level languages will never replace
ASM... Windows 95 will not replace DOS...

Software is composed by abstractions, doesn't matter how much levels of it,
better computers allow it.

Thinking that hardware<->OS is better than hardware<->OS<->browser is an
oversimplification.

~~~
rimantas
Except in this case we are not developing high level languages, we are trying
to patch poor ASM. I see the height of the web in the early 2000s, when web
standards, accessibility, clean markup meant something. Now it is just a pile
of frameworks (as someone twitted: JS frameworks are standards fanfiction)
thrown together. And not even for apps, for a simple text page :( I will
repeat Tantek's definition: if it is not curlable, it is not web.

------
LunaSea
Native apps are by definition less portable than web based ones.

As a developper I look at native app development the same way I saw the web in
the early 00's. Different platforms, screen sizes, versions, programming
languages, paradigms ...etc.

~~~
cjslep
> Native apps are by definition less portable than web based ones.

I don't believe it is that clear cut. I think you are ignoring the fact that
native developers have frameworks of their own. Using Boost, GTK+, or Qt gives
various layers-of-thickness over the OS so the native code is portable. Some,
like Qt, also cover mobile operating systems as well as desktop ones. These
frameworks are not young either; so while websites had browser-specific-
detection-code (thanks to IE), native apps were already running cross-platform
by leveraging frameworks of their own.

~~~
LunaSea
I haven't seen anyone use Boost, GTK+ or Qt cross mobile / desktop.

~~~
pjmlp
Dropbox at CppCon 2014,

"Practical Cross-Platform Mobile C++ Development"

[https://www.youtube.com/watch?v=ZcBtF-
JWJhM](https://www.youtube.com/watch?v=ZcBtF-JWJhM)

MuseScore

[http://showroom.qt.io/musescore/](http://showroom.qt.io/musescore/)

Qt show room has many others -
[http://showroom.qt.io/](http://showroom.qt.io/)

------
blisterpeanuts
Currently, best practices are web apps for light user interaction, native apps
for heavy user interaction or complex graphical presentation, and hybrids
(native app that is essentially a container for a webview) for best-of-both.

My money is on hybrids for the near term. A native app with a webview gives
you a lot of local control but still leverages the server power and advantages
of centralized web apps. The Youtube examples mentioned in these comments are
a parallel of this approach (I doubt they use webkit, probably just access the
streaming protocol, but effectively similar).

I'd love to hear some comments/opinions on these thoughts!

~~~
frik
I see it the same as you.

I don't have the same opinion as the author of the article. His arguments read
like the article is from 3-4 years ago when the old iOS UI was still hip and
Web Apps tried to recreate it with slow JS libraries.

------
bobajeff
Yeah, this is kind of what I've been thinking:

Let data be data. Let features be features. And let user interfaces be user
interface. So many websites mess this up in order to deliver a quick working
site that only works on the desktop and sometimes only Windows. And now we
have sites making seperate ghetto mobile versions or mobile apps missing
features. We still have data that can't be accessed through URL with text that
can't be selected or shown without JavaScript loaded.

Unless you are doing something more complicated than content devilery (ie
games or utility apps) there is no reason to override fundamental features of
the web.

------
sclaxton
This post is right, but only because web technology is currently a second-
class citizen on almost every native environment. If you were to expose system
API's directly to the JS layer à la FirefoxOS, then I'm pretty sure you could
recreate most "native" apps on web based platform with minimal / narrowing
performance hits. Booting to browser technology can only get better with
projects like ChromeOS and FirefoxOS pushing the envelope, so why not push for
a unified application runtime in the web across devices? Sure, html wasn't
made for rich applications, but html5 was...

------
thegoodlab
It's all relative. At any moment in time there are going to be "native," fat
client, devices that are running more powerful applications than that can be
run on a thin client, "web," model. There is always going to be a transition
to move those applications to a thin model, for scaleability reasons, and when
that happens there is going to be some new software that requires the fat
client model again.

Either way, it's about figuring out which model works for the problem you're
trying to solve. If you advocate for one, you're missing opportunities in the
other.

------
whoisthemachine
To a certain extent, I think this is true. Many mobile sites still need to be
more engaging, but they need to do it by taking advantage of their strengths -
server side rendering, a nice easy way to stylize (think CSS is bad? try
styling your application in Android's framework, or WPF for that matter) -
rather than going the route of the "SPA". Once a web app tries to look and
feel like a native app, other things out of the web app developer's hands are
going to make his app always look inferior. In fact, it may be some of those
strengths I listed earlier.

~~~
pjmlp
> try styling your application in Android's framework, or WPF for that matter

I will take any of those over CSS, thank you very much.

~~~
whoisthemachine
Hmm what advantages do those have that makes you prefer them over CSS? I work
in both of those daily and they're usually just an exercise in frustration.

~~~
pjmlp
They make more sense to my developer mind without designer background, don't
suffer from CSS global namespace, inheritance side effects and browser
specific behaviors.

~~~
whoisthemachine
Huh I also have a "developer" mind, and very few people would call me a
designer, and those that do should re-think what a designer is.

However, from my observations over the years, the cost of "browser specific"
behaviors is equal to or less than the cost of learning entirely new styling
paradigms every time someone puts out a new UI framework. CSS also has the
benefit that over time browser specific behaviors fade away as standards take
shape, which is inherently not the case with UI frameworks.

As far as the namespace goes - I guess, but there is nothing to stop you from
coming up with your own namespacing scheme using nested CSS classes.

~~~
pjmlp
> As far as the namespace goes - I guess, but there is nothing to stop you
> from coming up with your own namespacing scheme using nested CSS classes.

This doesn't work when you are just yet another developer on the team.

------
gjvc
those who do not learn from history are condemned to repeat it. watching the
mother of all demos once a year is a sobering reminder of that.

[https://www.youtube.com/watch?v=yJDv-
zdhzMY](https://www.youtube.com/watch?v=yJDv-zdhzMY)

some better-than-most discussion here:

[http://arstechnica.com/the-multiverse/2015/04/from-the-
vault...](http://arstechnica.com/the-multiverse/2015/04/from-the-vault-
watching-and-re-watching-the-mother-of-all-demos/)

------
click170
As a user, my policy is simple. Unless there is functionality in the app _that
I want to use_ that requires direct OS access, the app doesn't get installed,
period.

I care about my privacy and I won't install your app just to get a slightly
snappier experience or because you didn't want to make a web version.

There's way to many "apps" that don't deserve to be anything more than a
website and I take a hard line when it cones to my privacy.

Ask yourself if this can be done in a website. If the answer is yes, then why
aren't you?

------
brudgers
Sure it's just me anecdotally, but I don't care about native apps versus web
apps. I care about where the ship takes me not the arrangement of its deck
chairs. I'll use the command line...or the address/search box...if it gets me
what I want. Good user interaction and great functionality subsume widget
chrome and when it comes to native versus web experience please feel free to
do something else on my behalf whenever it means doing more of the things I
care about and less time bikeshedding.

~~~
kozak
There's a big market for ships with nice deck chair arrangements.

~~~
brudgers
Yes, of course and too many lifeboats might scare the passengers. That's why
one can find work in the deck chair arranging industry, attend deck chair
arranging conferences, and engage in debates over whether it is best to
arrange deck chairs using tabs or spaces.

Yet somehow, users manage to navigate the web despite Apple's app store
gatekeepers not setting policy. And really the debate about emulating native
exists because of app store policy, not because the native standards are
inherently better than what someone might invent left to their own
devices...or even that they are necessarily better than the command line.

------
MidoAssran
Interesting points you bring up. A point to consider is that many companies,
even surprisingly many of the Fortune 500s, have very dedicated IT teams to
support a web infrastructure, and so choose to make their applications using
web frameworks to emulate native. I give you that it's not ideal, but when
looking at the bigger picture, it just makes sense to use web rather than to
force them to spend months getting ready for native support; so there might be
a place for each use case.

------
Zigurd
What's appalling is how many of the mobile app-related comments here are about
cross-platform panaceas.

Just don't. Well, OK, if you have an enterprise shop full of C# coders, you
should evaluate Xamarin.

But unless that's your story, and unless your tool is as well-engineered and
well-funded as Xamarin, trying to get one code-base across Android and iOS is
going end in pain and regret.

It's back to a future of multiple platforms with fairly strong differentiation
in features and toolchains. Deal with it.

------
AnonJ
This argument is really rough. Many programmers surely will only want the
content, but websites are interacting with the whole world, and they have
business models which cater to the general public. If they only exist to serve
simple, static contents then the companies running them might add well just
shut up shop. Why even bother spending expenses maintaining such stuffs if
they don't appeal to the general public and easily call them to actions
anyways.

------
mangeletti
I think web technologies are a bit like AI and VR; they catch up in waves to
meet demand, but they don't simply replace everything all at once.

IMHO, the reason for this is that once web technologies almost catch up to
native, native buckles down and fights back (e.g., Swift), and as long as
native can keep developers happy, it will always own serious market share,
since it is closer to the metal (faster) and necessarily has access to more
APIs (more features).

------
orthoganol
So, the OP is adverse to the JavaScript single page app fad, because in his
opinion it is overly complicated to try to get a web app to behave like a
native app, and instead should embrace its "weby-ness"? Is he just thinking
about developers who have to use the tools he does not like, or the consumer
experience side of it too?

~~~
KaiserPro
Single page apps are in my experience a massive faff.

They may look good, but they tend to break things like back/forwards have text
that can't be copied and pasted.

Some have embedded video, which eats everything.

~~~
aliakhtar
> they tend to break things like back/forwards

That's not a requirement for building a single page app, there have been ways
of emulating history in spas for a while now.

> have text that can't be copied and pasted

What do you mean? SI'm not aware of any sites whose text 'can't' be copied
unless they disabled right clicking.

------
markbnj
The web only works for mobile when you have a responsive design, which again
for most people means adopting one or more frameworks. News stories should be
perfect content for a mobile web presentation, and yet we have Flipboard. The
app is free and the service is sub-based, so business model wasn't the issue.

------
oldpond
Remember when the browser was actually a thin client? Now it's got everything
but the kitchen sink in it. It's funny how we just assume anything new will be
in the browser. Innovation is happening at the native client now. Do one
thing, and do it well. Talk to my server.

------
eighthave
Great article, I'd just like to point out that URLs by no means only work on
the web. Android has deep, native support for URLs in apps, and are frequently
used for inter-app communications that have nothing to do with the web.
Another OS could easily add such support for URLs.

------
minusSeven
Once upon a time I would choose native over web anytime. But my experience in
native has got worse over time. Now I don't even feel like it. I don't want to
install 2 dozen apps when I can simply go to that website directly. Native if
anything has been a failure.

------
superuser2
If we do this, then we need to pick a platform. There is enormous replication
of effort in creating "native" experiences for all of OSX, Windows, Linux,
iOS, and Android, probably worse than what we spend on replicating native
tooling in the browser.

------
piluyas
I read this post just in time!... now I'm am sure, the future is create a new
PornHub for android, and other in xCode for Iphone, and for nokia, another
one, and what about Blackberry, sounds very portable! is a remarkable idea!

------
javiramos
I consider Onshape to be a big win for web:
[https://www.onshape.com/](https://www.onshape.com/)

It is a full-fledged CAD design software (think Solidworks) that runs on the
web.

------
snarfy
We already did concede and invented asm.js. Unreal Engine runs in my browser.

------
kuma4
Web has some advantages and remains important. But HTML/CSS/JavaScript will
decline in the future. They are limited compared to native app technologies.
Web will be used mostly as a JSON API.

------
cbd1984
This page is so narrow, and the text so small, it's unreadable.

------
feld
Fastmail's mobile webapp is a webapp done right. It feels like a native app
that is a natural extension of the full-featured website -- but it isn't
native.

And it's blazing fast.

------
shiggerino
The biggest problem with this HTML app craze is that the tooling is abysmal.
People still debug JavaScript by looking at trace output, are you fucking
kidding me‽

------
hypertexthero
[Lets not]([https://en.wikipedia.org/wiki/Wabi-
sabi](https://en.wikipedia.org/wiki/Wabi-sabi)).

------
drinchev
But what should the author explain to Chromebook users? They can only have web
applications on their desktop as an icon.

Actually I think they're doing pretty good with that.

~~~
pjmlp
I never saw anyone with one in Germany, besides computer stores trying to get
rid of them with massive discounts and still they gather dust.

~~~
stuartmemo
Amazon's best selling laptops - [http://www.amazon.com/Best-Sellers-Computers-
Accessories-Lap...](http://www.amazon.com/Best-Sellers-Computers-Accessories-
Laptop/zgbs/pc/565108)

~~~
pjmlp
On the US market.

Additionally how many of those laptops are actually running ChromeOS, instead
of being replaced by a proper Linux distribution?

~~~
stuartmemo
Ok, here's the UK market - [http://www.amazon.co.uk/Best-Sellers-Computers-
Accessories-L...](http://www.amazon.co.uk/Best-Sellers-Computers-Accessories-
Laptops/zgbs/computers/429886031)

~~~
pjmlp
3rd place in Top 20. Still you haven't answered how many of those are
effectively running ChromeOS.

Looking at Germany, which was was I mentioned on my post, the scenario doesn't
look like that anyway.

------
nly
It's HTML and CSS holding 'web apps' back. It's like we're all trying to
sharpen our pencils with spoons.

I think the future of remote web-like apps lies in something like QML[0]. A
completely native UI with full access to the desktop widget suite can be
downloaded in QML in a few kilobytes. Stick a browser like loader on the front
of it, and provide a decent (seamless) asynchronous RPC, and you've got
yourself a replacement.

[0]
[http://doc.qt.io/qt-5/qmlapplications.html](http://doc.qt.io/qt-5/qmlapplications.html)

~~~
VLM
Spawn off a rdesktop or VNC session back to a cloud based server. Skip all the
intermediate interference that just slows down and complicates things, and
turn the web into a dumb graphics terminal. You can either intentionally use
the correct tool for the job, or painfully slowly buggily reinvent it if NIH
is a requirement.

------
BadassFractal
I use the web in big part because I want to avoid the week (or sometime two-
three week) long gauntlet of going through the Apple submission process.

------
mathattack
How much of this is due to the # of native technologies that need to be
developed for?

In Mobile there are 2. Web wins over 20 competitors, but just 2?

------
kogus
I think this is a false choice. To a large extent, the web __is __native, and
the browser is the operating system.

------
pinaceae
as long as you use a markup language plus styling language built for documents
to somehow emulate app interfaces, the web will lose against native.

the www is great for content. wikipedia. awesome.

but it just sucks for apps. the constraints it puts on UI and hacks needed to
get around them is staggering. let's center something on the screen with CSS.

------
perseusprime
Isn't a browser a one size fits all container that was never destined to last?

~~~
netfire
Couldn't you say the same about the operating system in general? That is, that
apps are limited to the the container provided by the APIs given by the
operating system? The browser is only limited by the restrictions given to it
by the operating system. There's no reason a browser can't run frame-less
graphics-intensive apps with something like WebGL or why it couldn't have
access to more of the operating system and hardware or function more like an
app.

The main workflow of a web browser (urls and browser history), don't seem any
more restricting than having to use an app store to download an app or using
the home screen to launch an app. (I would argue that they are, in fact, less
restricting). The restrictions are a factor of the operating system, not a
inherit restriction of a web-based workflow.

~~~
perseusprime
Wouldn't they then become emulators of app runtimes?

~~~
netfire
In a way, but there are advantages to running an application in a web-based
platform:

\- Distribution is easier and doesn't require approval from a third party
(such as app stores), providing less of a barrier to entry and more freedom to
create what you want to.

\- It can be easier to develop and you may not have to provide support for
multiple versions of your app (because you can easily ensure that everyone is
running the latest codebase).

\- Common components/libraries that would be used across different
applications can be part of the browser itself or cached for one app and re-
used for other applications, instead of having to be packaged into a
downloadable runtime application.

\- Depending on your application, creating a cross-platform product may be
easier and require less development and have built-in functionality like copy-
paste and other functionality provided by the browser (history, bookmarking,
etc).

\- The user and other people have more power to use your application in more
flexible ways (due to browser plugins), and the content can be crawled and
made searchable/discoverable by a variety of companies.

\- The hyper-linking built into the web offers easy, cross-site (and
application) integration that may be difficult to accomplish in a native app.
In fact, you may be limited to a certain application provided by the operating
system (like a particular map provider on mobile)

------
EGreg
I disagree. Especially for startups.

I will take "the Web" to mean, essentially, that the rendering of the front-
end is done in a browser. Then, what you have to do (I learned this the hard
way) is stick to things that get rendered well in browsers on all the
platforms you plan to target (which usually includes Android, and that means
no fancy scrolling). Develop your aesthetic around that. You can put out
native versions later, when you have the budget to support all the platforms.

Now, this has several advantages. One is if you want your app to become
popular. If your app involves inviting friends in any way, realize the friends
don't have the app, and the invitation will probably happen via
SMS/email/facebook/twitter. When that link is clicked it takes the friend TO
THE WEB. Yes you can have the friend look at an app in the store, download it,
launch it, confirm their phone number again, and then finally engage with
whatever they were invited to. Or you could have a WEB EXPERIENCE ready for
them and create an account with 0 steps!

And since you've already coded this web experience, why not wrap it in
Cordova/PhoneGap and add bridges to the underlying OS APIs via plugins. This
keeps separation of concerns and actually maintains much better than many
native apps. And you'll also instantly have access to many cool components
like Mobiscroll, which have been tested and work everywhere. Compare that to
downloading some native lib for iPhone, like Layer, only to realize it doesn't
work on other platforms like the web, and you have to wait or roll your own.

So now you've got a unified codebase which renders in a browser, you can wrap
it in MacGap and other wrappers, hire specialized developers on each platform
and pay them to maintain ONLY the part they need to. Not the interface, not
the server interaction, backend etc. Which all has a standard and RICH
environment to build in, including localStorage, local database, sockets, even
WebRTC for peer to peer time topologies! All that stuff is good enough in 99%
of the cases to build an app.

Well I'm a little biased. My company has been building a plaform for years to
make apps successful and viral, a sort of open source alternative to Facebook
(which just shut off app access to people's list of friends, something that
was the biggest selling point at the very beginnng and the reason you
shouldn't build your business on someone else's centralized platform). The
idea was to have a standard platform finally to power SOCIAL apps, that was
all well designed and take care of everything for you, so you can focus on
write your app, not getting cordova, user signup invites and privacy /
security right etc. It also supports a growing ecosystem of reusable widgets
and plugins that you can just plop onto a page, like chatrooms or docs. I
thought it would be done in a year but it's been four years and we're still at
0.8!

[http://platform.qbix.com](http://platform.qbix.com)

------
hlfcoding
This coming from a guy whose website hadn't been made responsive.

------
xtx23
so...concede defeat 'cause some engineers using the tech wrong or like the
tech to be used certain? Who's to say how the web is supposed to be?

Some comments above mention about loading 100+ assets for a Phonegap app...why
would you load 100+ remotely when you are building a phonegap app?

Every tech comes with a trade-off, at the level of dev-cost vs. runtime-
efficiency. It also depends on what kind of existing code base and developer
team you have to build the new product. A typical right or wrong clickbait
like this one is not even worth the lengthy discussion bordering on random
mass venting.

------
ajkjk
Things native apps do well:

\- Run offline

\- Access large files stored locally

\- Start from the command line or from clicking buttons on your desktop

\- Use graphics cards and other peripherals

\- Run quickly

\- Tune performance to your platform

\- Come pre-installed on your system

\- Exist for all time

\- .. and don't require servers and money to host them

\- Security is pretty easy to solve

\- Coded in pretty much any language

\- Interop with other native software

\- Run in windows or fullscreen

\- Easily convince people that they ought to be purchased

\- Obfuscate their functionality from users [important for, say, video games]

\- Handle large amounts of data without network bandwidth constraints

\- Standardized UX, so it's less easy to screw up.

\- .. and when you do get an app running, you get a lot more UX for free
[well, depending on what you're doing]

Things webapps do well (and sometimes get for free) that native apps do
really, really badly:

\- Save data across multiple systems

\- Allow you to login anywhere

\- Get off the ground with a UI + basic functionality in O(1) lines of code.

\- Receive updates from their maintainer

\- Run multiple instances at once with a single click

\- Are completely sandboxed from other apps (app freezes? just refresh the
page)

\- And are sandboxed enough that you can pretty much trust them (barring
tricking you into downloading viruses / exploits, etc, you don't have much to
fear from a website,, at least compared to running untrusted executables)

\- Live in easily manageable tabs

\- Are easily augmented using scripts (Greasemonkey, etc) or simple scripting
(JS in the URL bar) or plugins (browser extensions, etc)

\- Are globally namespaced and addressable and bookmarkable. Every webapp runs
in the same container so other programs can manage them in a uniform way: via
bookmarks, hyperlinks, etc.

\- Support an intuitive format for entry points into the internals of an the
application, via URLs. Compare to: save files for a video game.

\- Must forcibly reveal their source code (except for Flash & similar plugins)
to the client, so it's hard to deceive [technically savvy] users.

\- .. and are largely open source by default (except for Flash & similar
plugins)

\- .. which means anyone, even someone who's never coded in their life, can
learn to peek under the covers and see how things work.

\- Use global identities (logging in with Google/FB/Twitter/etc) and sometimes
global configurations (Google cloud sync, etc)

\- Elegantly support collaboration (send someone a Google Doc link and you're
done)

\- Standardized ways of handling authentication and security \- Default
implementations for hotkeys, linking, text editing, scrollbars, image
insertion, etc.

\- Default implementations for caching of resources, shared libraries, and
asynchronous messaging [sort-of] \- I'm sure there's lots more.

It seems to me that web browsers accidentally solved a very general problem
with a very specific solution.

\--

The problem: how do I run software that's dynamically loaded over the Internet
with minimal barriers to my users?

(Well, initially, it was 'how do I display text from the Internet to users',
but we've moved passed that.)

The solution: I'll build an application that interprets a single programming
language (Javascript) with a single standard UI language (HTTP+CSS) and
supports a global namespace of all other apps (DNS,etc) and allows data to be
encoded in resource identifiers (URLS) and maintains state across sites and
across sessions (cookies), and I'll call it a Web Browser.

This relatively arbitrary solution got a lot of things for free, but it left
us with a lot of implicit constraints that divided the line between web and
native applications. Ever since then everyone has been trying to break back
out: adding tabs, isolating tab processes, supporting extensions, embedding
Java, embedding Flash, supporting SVG and Canvas and WebGL, etc. We're still
largely trapped in the interpreted-Javascript world.. but Dart gets points for
trying, and alternative languages/paradigms (stronger-typed variants like
TypeScript, from different programming paradigms like React, and from entirely
different languages (asm.js, GWT..)), are gaining traction. Meanwhile, AWS
S3/Lambda/etc, Dropbox-based storage, Google cloud sync'd settings, or global
credentials via Twitter/FB/Google/Etc.. these are all reducing the amount of
work you have to do to build and maintain a simple app in a website.

I wish I could use Dropbox or Google Docs as my 'filesystem', if that made
sense, or use the local filesystem as my filesystem, if that made sense
instead; I wish I could use local keyfiles or global accounts at will, or
build low-level compiled libraries and mix them with deployed, interpreted
website code at will. I also wish my window manager and my tab manager were
the same application, and my Omni-bar searched my desktop and the entire
internet, and my stickynotes were synchronized on any computer I log in to.
And I also wish I could write a native (but sandboxed, except for the
permissions I grant it) application with a UI that interops with my OS and
other programs by simply writing 10 lines of code and then saving the file
with a .html extension. Basically, I don't particularly want to write native
apps; I just want to casually slide back and forth over the line between
native and web.

------
jebblue
jQuery Mobile and done.

------
jlebrech
web byte code

------
landmark2
rant of the day

------
hmans
Ok

