Web vs. native: let’s concede defeat

http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html

by robin_reala • 11 years ago

605 505 11 years ago

hmans• 11 years ago

nailer• 11 years ago

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.

datashovel6• 11 years ago

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.

pdpi2• 11 years ago

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

jevgeni2• 11 years ago

This was just quick and brutal. :D

datashovel6• 11 years ago

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.

swah• 11 years ago

Well, the cross platform support will get really good ;)

ubernostrum• 11 years ago

This post leads me to believe the author probably assumes there will always only be a handful of native platforms.

No offense, but I'd trust PPK's beliefs about the mobile ecosystem more than any random HN user.

datashovel6• 11 years ago

None taken. It's probably not worth arguing who is right or wrong since none of us can reasonably assume we know what the future will be, but I will say that in general (1) diversity in ecosystems is good. (2) Monopolies are bad. Given only these two basic assumptions I think it's obvious that there should / will be a push for more diversity in mobile, and thus a larger number of platforms to develop for.

This can only lead to one result which is for developers to want a unifying platform on which to develop. I would argue that this exists, and is improving. It's called the web and web browsers enable this unifying platform.

onion2k5• 11 years ago

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).

mahouse• 11 years ago

Seeing you saying good things about Cordova makes me think you have never used Cordova.

aliakhtar3• 11 years ago

I have, and I agree with what he said. One thing which isn't that great, are the plugins. I feel like there could be easier ways to access / write plugins. But overall, everything said was pretty spot on.

frou_dh• 11 years ago

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

wolf550e• 11 years ago

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)".

weego• 11 years ago

If you need to get to market, then it could well be a win for both. If you then have significant traction and resources and still think 90% is good enough, well then, that's your risk to take as a business. Personally I feel that 90% is only good enough to get you started and there is a tipping point where user experience necessitates quality over business optimisations (shortcuts).

onion2k5• 11 years ago

I don't think the tools we use impact the user experience that much, certainly not as much as the designs we use or the UX choices we make. If a hybrid app has a bad user experience it'd probably still be a bad experience if it'd have been built as a native app instead.

72deluxe4• 11 years ago

Developing for native does not always take twice as long. I would write a desktop C++ app faster than attempting to write a web app and wrap it in desktop runtime capability.

If you're not used to writing desktops apps, yes it will take longer.

moonchrome• 11 years ago

I recently needed to build an internal GUI app - after seeing how much time it will take me to get a HTML client/server set up I looked around for a GUI framework in Python and I was thrilled when I found : https://python-gtk-3-tutorial.readthedocs.org/en/latest/

With Glade + Python 3 I was chucking out GUI code faster than the Visual Studio + Win Forms because there was no compile step. No over engineered MVVM ala C#/WPF for a simple app - load a glade layout file, hook up callbacks - bam everything works together. The MVC is already there because the content pipeline (model) is already separated and views are defined in glade files. I had a prototype functional by the end of the day - it would take me that much just to choose which tools to use if I went Javascript client/Python server.

Seriously - couldn't believe how fast you could get stuff done with it - everything works as expected, you get all the controls you need - no need to learn random stuff like that qtscript, no build process (this is actually huge !), insanely fast iteration (faster than web-dev). I always thought of GTK like some obscure C gui lib but the Python wrapper makes it very usable.

My only complaint so far is that Glade seems to be getting progressively slower as you remove/add stuff so you need to restart it from time to time (eg. once per hour) but it starts instantly so it's not really an issue.

Note : I haven't yet tried to get it running on Windows or OSX since we all use Linux internally.

iLoch2• 11 years ago

I'm using React Native as a web developer who wants to create a native app. Native performance with the familiarity and simplicity of web devlopment. I don't know why anyone would build a Cordova app anymore.

ramblerman• 11 years ago

does react native support android yet?

onion2k5• 11 years ago

In my case it's very simple - so I can deploy the same code to the web. Not many people will want to do that though.

KaiserPro2• 11 years ago

Yes and no.

One thing that is more and more important is batterylife. The more layers involved, the more energy they suck.

nextw33k• 11 years ago

That's kind of old world thinking, it's been bugging me. In traditional programming and processor architectures that statement would be true. But if it were true today then Google wouldn't have built the Dalvik and then ART layer into the OS. They'd be compiling them on the developers PC and you'd end up with a fully static App.

The VM approach allows the VM to synchronise application wake-ups which can increase battery life.

Google chrome on Android is acting much like a VM to developers and I'm willing to bet the Android Chrome team are spending a much time as the Java runtime team are on optimising.

kyriakos• 11 years ago

crosswalk adds 58mb of weight on your app though and works on android only.

onion2k5• 11 years ago

That's not been a problem for me, but if it is you can separate the x86 and Arm builds so it only half as much for each one.

rsynnott2• 11 years ago

Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app

People always go on about Cordova etc, but I've never used one of these that wasn't a clunky, slow non-native looking mess. Do you have any examples of Cordova apps which aren't noticeably more crap than, say, an average-quality iOS app?

onion2k5• 11 years ago

The best example I know of is http://snowbuddyhq.com/ ... It's pretty much impossible to tell that it's not a native app, it's fantastically well designed, and it works really well. There's a good article about it on Digital Arts: http://www.digitalartsonline.co.uk/news/interactive-design/w...

mreiland4• 11 years ago

I really dislike steam's hybrid approach.

joeblau2• 11 years ago

Something based on Cordova (eg PhoneGap, Ionic) with Crosswalk can get you to about 90% of the performance of a native app

Companies like Famo.us have proven this is incorrect mathematically over 2 years ago. That is precisely why Famo.us built its own rendering engine that subverts the DOM and renderings content similar to a gaming engine (Unreal Engine). The DOM can't render as many surfaces as a native app in one view smoothly.

You can still make a very performant cross platform DOM based application (http://hn.premii.com is an excellent example), but in order to get that performance you need to limit your interface to very basic UI elements.

leonatan2• 11 years ago

And even that site lags in animations. Something as simple as pull to refresh drops frames.

mbesto• 11 years ago

building a hybrid app wins every time.

Define your criteria for "winning". If I'm truly building a user experience, then I don't know a single hybrid app that has "won" (my definition of winning here is an app I use daily, and I don't know of a single app I use daily that is hybrid)

90% is easily good enough for most applications

The problem is most applications (80%) don't really even need a native app to begin with.

s73v3r5• 11 years ago

"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."

This is true only if you're working with people without experience. Someone who is experienced with the mobile toolkits is going to be able to develop the app just as fast, with more functionality.

Navarr3• 11 years ago

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/

EliRivers3• 11 years ago

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.

Navarr3• 11 years ago

"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.

userbinator• 11 years ago

But what if the browser is the OS?

There's still an extra layer, because the browser's API is far more complex and higher level than that of an OS.

charliefg2• 11 years ago

This is clearly just my laptop (or maybe firefox) but that google site took about 30 seconds to load up. Every time I click on the tab that has it open - my computer fan whirs up to near full speed and it locks up firefox's graphic rendering until it finishes the page. Once loaded there is an unusable level of lag on the browser and CPU usage is levelling at 55 odd percent.

rsynnott2• 11 years ago

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.

Recreating the glory days of whole-page Flash sites, or those old Macromedia multimedia CDs?

pjc507• 11 years ago

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.

tragic• 11 years ago

Disclosure: I work on the website of a blue-chip dead-tree newspaper. But I agree. As someone else said in another comment, the basic requirements of a news site is, let's be honest, Web 0.5 stuff. Look, some text about stuff that happened! A picture of stuff happening! These are, shall we say, solved problems.

If there's anything where you wouldn't expect significant value-add from the native or pseudo-native experience, it would be news. Certainly as a consumer I have no news apps installed - I go to the website.

duncanawoods2• 11 years ago

> If there's anything where you wouldn't expect significant > value-add from the native or pseudo-native experience, it would > be news

I strongly disagree. I see "the news" is a perfect counter example because technology has changed what news is. Its not daily static content anymore, its now real-time, multi-media, interactive and interconnected.

The types of media on a news page include: recorded video, live feeds, audio, pictures and embedded digital content from other services like twitter created by both journalists and amateur eye-witnesses. These are not just value-less decoration like cute animations on landing pages but real content from the event being reported.

When news is data like election results, tax changes etc. interactive data visualiations are essential for digesting it. Interactivity lets us understand the impact of the news to us personally instead of single homogeneous national agenda. We expect all this and for it to be real-time and provide ways for us to be notified about changes, to share it and discuss it with friends and strangers.

Margh• 11 years ago

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

Disagree. Case in point: steam://friends 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.

pjc507• 11 years ago

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)

leoedin• 11 years ago

They didn't say it was impossible, they said it was hard. And it is. Deep linking into an app requires a link handling implementation and knowledge of the operating system's procedures for registering that you can handle certain protocols. The web gives it to you for free.

TazeTSchnitzel10• 11 years ago

Links into native apps are great!... Until someone doesn't have it installed

The few successful native apps with linking (iTunes, Spotify) go via the web.

cicero2• 11 years ago

I think it is possible that a news app done well could provide a slightly better mobile UX than a browser (better navigation and pagination), I would want the content to be mirrored on the web, and it should be easy to get at and share the web links.

tootie• 11 years ago

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

It's not much easier to debug multiple versions of multiple native apps than it is to debug one web site.

orthoganol• 11 years ago

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?

KaiserPro2• 11 years ago

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.

ianstallings• 11 years ago

This logic is flawed. Disabling back/forwards, copy/paste. and embedding video has nothing to so with a website being a single page app.

aliakhtar3• 11 years ago

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.

landmark2• 11 years ago

rant of the day

mozumder3• 11 years ago

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.

msutherl• 11 years ago

Likely this hasn't been done because it would require many very difficult, "subjective" decisions to be made i.e. which font, line-spacing, photo-viewer UI, etc.? Better to make no decision at all than to spawn a few dozen endless committee debates.

By contrast, corporations can more easily make these sort of decisions – by fiat – which is why native app frameworks are more "opinionated" / make more design decisions for you out of the box.

This topic is as much the story of two historical forms: the operating system GUI and the World Wide Web hypertext project as it is about two organizational forms: hierarchical corporations and decentralized design-by-committee non-profits / multiple competing corporations.

pestaa• 11 years ago

Don't forget that you can specify related pages as <link rel="next/prev" /> and let the browser handle pagination.

I recall when I used Opera, you could scroll down, hit space, and it would go to the next page as long as the website provided that information (forum softwares often do.)

mozumder3• 11 years ago

That's just one UX issue among thousands.

I also mentioned the column width because this site has the obvious problem of long horizontal text, which is a no-no. People naturally read in chunks of 10-15 words scanning vertically. Long, horizontal text is easy to lose track of location.

jfoster• 11 years ago

How much have browsers invested in their pagination solution, though? If I specify that tag on my pages, does that mean users who visit my site will have an awesome experience when it comes to pagination?

zhte415• 11 years ago

There's an answer to your questions. It is documented here: http://motherfuckingwebsite.com/

xt• 11 years ago

This is what you want => http://bettermotherfuckingwebsite.com/

accatyyc• 11 years ago

That is beautiful. Perfectly expresses how I feel about the web today...

nkuttler2• 11 years ago

After 25 years, why do web designers need to create their own page transition mechanics for long-form articles

Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays. Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant.

photo galleries - after 25 years, why isn't there a standard user experience for viewing photos related to articles?

Because there's no one size fits all solution. Look into magazines, newspapers, etc. After a few centuries there is still no standard. Grouped, with captions, position, size, etc.

why do we need to write CSS to create a basic readable document in the first place

You don't. Browsers can display semantic markup just fine without any CSS. The fact that you even ask this question is why you write CSS, because different people in different times expect different styling, and they don't think the default style is pretty. I agree that the default styles could be improved though after 20 years, but that could lead to breakage of current CSS styles, and why risk that if everybody uses CSS anyway?

And the fact that I wrote this comment is just another reason why you have to write CSS: because not everybody agrees on how the web should look.

mozumder3• 11 years ago

Ok, if you have, say, a long manual with multiple chapters that would be several hundred pages when printed it can be nice to break it up, but that's probably not what you meant.

Actually yes this is the use-case I was referring to.

HTML has semantics to define sections, headers, etc.. but it doesn't manage them in any way.

If you write HTML that define sections, for example, it's no different than if you write HTML without sections.

thaumasiotes• 11 years ago

Why do you need page transitions for articles at all? The only reason I can think of is for more ad displays.

What I read was that it's not for "more ad displays", although closely related. It's because news sites keep (and market themselves based on) a "pageviews" metric, so they try to get as many pageviews as possible out of each piece of content.

felipeerias2• 11 years ago

Have you tried to disable pagination in reading apps like iBooks or Instapaper?

Long articles and books are more comfortable to read if they are paginated: one small tap, one pageful of new stuff. Far more convenient and less prone to losing your place than scrolling.

omouse• 11 years ago

It looks like you've brought up the most important point: the design of a page is altered based on advertising revenue.

90% of the JS being loaded is for tracking to increase advertising revenue. Much of the styling for a site that has no advertising can be fairly light.

If we focused less on revenue generation we'd have a much much smoother web experience that would run quickly on mobile devices.

jasode10• 11 years ago

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.)

rimantas3• 11 years ago

No, the web means web. Internet means internet.

pjmlp17• 11 years ago

... TCPIP, DNS routing..

Also known as Ethernet protocols, nothing to do with "The Web".

weland5• 11 years ago

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.

Dewie34• 11 years ago

The "web" also means the whole internet stack, TCPIP, DNS routing, etc.

I'm pretty sure there are different protocols for email, torrent, etc. And I don't see how that is a bad thing, or why The Web has to be a frontend to everything that comes from The Internet (desktop email application for instance).

rpcope1• 11 years ago

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.

No, absolutely not. The "web" refers only to what you mentioned above. It's only a recent bastardization that we started referring to the "Internet" as the "web", because of the dominant nature of HTTP. You're right though that the Internet is important, but the GP's point stands that HTTP was really only intended as a document protocol (Hypertext, yeah?) and it has seems a somewhat strange perversion that we've bent it to doing so much more.

Someone not in the know may call the transmission in a car "an engine", or call the differential a transmission. Just because someone outside of the industry does silly things like that doesn't mean all of a sudden obfuscate the usefulness of terminology at all, as it really helps no one.

EdiX2• 11 years ago

After 25 years, why do web designers need to create their own page transition mechanics for long-form articles

As far as I am concerned those things only exist to inflate ad views, they have negative usability impact. I don't really see why a long document should be broken up in pages to be readable.

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

There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with.

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?

I find plain un-styled HTML to be much more readable than the tiny light gray webfont on white background that designers usually settle for these days.

provemewrong• 11 years ago

There is one: right click → open in new tab. It work very well, much better than the jquery kludges that people come up with.

Except when people nest the images as deep as posible and overlay other elements in front of the images so you can't simply right click the image, you have to inspect source and hunt for that image URL (or check resources tab in developer mode, or whatever).

/rant

amelius2• 11 years ago

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.

to3m2• 11 years ago

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.)

amelius2• 11 years ago

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.

TazeTSchnitzel10• 11 years ago

HTML, CSS and javascript have grown so complicated that they lack certain desirable properties, such as verifiable security, flexibility.

Verifiable security? You can't statically verify a program is secure.

Flexibility? The complexity has given it greater flexibility.

For instance, a developer has no choice of programming language, but has to resort to javascript

Just like on native platforms, where the developer has no choice of programming language, but has to resort to machine code!

Unless you use a compiler. Which you can do, and it works very well.

I thought you thought complexity was a problem? Introducing "native" other-language support would only increase it.

also, the developer has no choice of render engine

I thought complexity was an issue?

But this is also not true. You can use your own if you really want to.

Although why you need your own rendering engine is a good question. Almost all native apps use the OS's GUI framework.

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)

Who said they did? They can choose to write code that doesn't work well on other platforms. Though that's largely a UI thing, the code will run on any without changes.

And of course, the fact that those platforms are not identical is also due to the fact that the web is too complicated.

What? From a code perspective, if it runs on one, it runs on the others. The API is the same. The only difference is UI: screen sizes and input methods.

We need simpler primitives

We have those. If you want to run a 50MB C++ GUI framework in the browser, you can! It's just a terrible idea.

LunaSea3• 11 years ago

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• 11 years ago

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.

LunaSea3• 11 years ago

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

robmcm2• 11 years ago

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.

This is because you are using tools and paterns to avoid having to think about the differences. Those tools are also on native platforms, and those differences apply to the web.

LunaSea3• 11 years ago

Yes but it's quite easy to handle to differences using shims / transpilers and feature detection.

pavlov6• 11 years ago

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

soft_dev_person• 11 years ago

"With all that, the last 20% of a Cordova app may well take 80% of development time, and that's rarely been budgeted in."

To be fair, that could be said about most software projects. "80% done, now the last 80% remains."

Not that I disagree with you, I had the same experience trying to make an Android app in Phonegap. It's lacking, like most cross-platform frameworks (for most types of apps, but typically not games) I have tried. They are only suitable for basic stuff where the native feel isn't critical.

pavlov6• 11 years ago

To be fair, that could be said about most software projects.

Yes, absolutely true. The difference here is between "known unknowns" and "unknown unknowns", to paraphrase a certain renowned military strategist...

With Cordova/PhoneGap, it's easy to get the initial impression that you're dealing with "known unknowns", just the typical web development project pitfalls -- "This is HTML, I know this stuff".

When the "unknown unknowns" hit the fan, it's often pretty late in the development cycle, and so things blow past original estimates even though they were competently planned. It's just that the plan was for web development, not the shifting art of websites-in-drag-pretending-to-be-apps-development.

touristtam• 11 years ago

side comment: the rule is called the 90-90 rule [https://en.wikipedia.org/wiki/Ninety-ninety_rule]

jsingleton2• 11 years ago

What do people think of frameworks like https://jquerymobile.com and similar?

I tend to think it's good when running in a browser but not when it's made mobile web app capable and running full screen without native controls. Unless it's a super simple single page app.

At the other end there are things like Instagram where you basically can't do anything on the website (can't sign-up, can't upload photos). Everything requires the app.

fabean• 11 years ago

I absolutely hate jquerymobile, you should just make your website responsive with CSS media queries then pepper in a little bit of javascript to handle things like slide out navigations.

k__2• 11 years ago

I read that Appcelerator Titanium and NativeScript are a much better way.

You can use much of your JavaScript skills and still get to go native.

joshstrange• 11 years ago

Unless that platform has changed completely in the last year or so then they are wrong. Appcelerator (and things like it) generally make "Hello World" super easy and even the first week or two will be awesome. Then the cracks will start to show. You will add a listener on a button and the app starts crashing with a cryptic error, you start having to litter your code with `if(isAndroid)`/`if(isIOS)`, or for some reason a view will be really show to render to lag between clicking and doing something. When you get down to it you'd be better off learning native or just accepting a mobile website instead. Normally (IMHO) the only apps worth using appcelerator for are simple websites and at that point you'd be better off just doing a mobile website.

I'm excited to play with React Native but I fear it will suffer from the same issues.

thekingshorses3• 11 years ago

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/

Now download this. Android : https://play.google.com/store/apps/details?id=com.premii.hn Or iOS: 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

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.

pavlov6• 11 years ago

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.

babby• 11 years ago

As a user of Android HN apps, premii seems to beat them in all aspects. The major aspect being them actually working properly.

It seems like apps are less maintainable. Right now pretty much all of the Android HN apps are broken in some way, or missing a core feature of the desktop experience.

fanf2• 11 years ago

Premii is a great example of spending a great deal of effort to fuck up basic native behaviour like scrolling. The inertia is completely wrong.

nostrademons4• 11 years ago

Both Android Studio and XCode will give you usable iOS and Android code from visual layouts. I've found that usually the easiest way to prototype an interface is just to build it for real - it's faster than Photoshop, even.

The hard part about X-platform mobile development is that oftentimes you need different product concepts on Android & iOS, because the idioms, best practices, device capabilities, and user expectations are different on each platform. So your client generally has to be ground-up development by an experienced expert in the platform, you can't just take the same layout and make it run on both.

pavlov6• 11 years ago

Both Android Studio and XCode will give you usable iOS and Android code from visual layouts.

Well, for some definitions of "usable" and "visual layouts"!

Our goal is to make a designer's tool that can output complete, store-ready projects for simple apps and for both platforms. That includes three things that neither Xcode nor Android Studio does:

1) Interface Builder and Android Studio's layout editor are not meant for designers. (Seriously, try giving them to a Photoshop-educated designer.)

2) Xcode and Android Studio let you define views, but neither of them produces the controller-level code from visual designs. (We do that and also produce model-level code for simple apps; there's a plugin API for more complex situations, or you can of course do that in handwritten code.)

3) Cross-platform. Anything you do in Xcode or Android Studio needs to be rebuilt from scratch on the other platform.

...the idioms, best practices, device capabilities, and user expectations are different on each platform.

I feel that this doesn't hold true anymore. iOS 7+ and Android 4+ have largely converged on a flat style where a 3rd party app can define its own style that is easily compatible with both.

With Windows 10, even Microsoft is coming into this "common mobile" UI fold. They're giving up on the idiosyncratic (and interesting) Windows Phone concepts, and instead adopting a generic look that makes it easier to port Android/iOS apps directly. They're also offering new APIs and runtimes for that.

(Edit: To clarify, you can customize layouts separately for iOS and Android in Neonto Studio.)

joeyspn2• 11 years ago

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.

That is a thing of the past. At the current rate of smartphone/phablet specs growth the differences with desktop are laughable (you can currently get 64bit octacore@1.7Ghz mobile devices with 3Gb of RAM for around $100) [0]. And this will only continue to grow. 16core and 32cores will be here in 2-3 years [1].

IMO, hybrid apps are already the present. The difficult times when we didn't have the required performance in our pockets are long gone... and frameworks like Ionic are really convenient for certain use cases.

browser differences between devices (even Android devices with the same base OS can have very different web view browser engines)

That has been already solved with xwalk [2]... but again, this will be irrelevant in a couple of years.

[0] http://www.gearbest.com/cell-phones/pp_152602.html

[1] http://www.xbitlabs.com/news/cpu/display/20130304235830_Pres...

[2] https://crosswalk-project.org/

throwaway2048• 11 years ago

the amount of cores makes no difference when javascript is single threaded. Infact its often detrimental especially on mobile because each individual core is significantly weaker.

Plenty of websites doing advanced html5 gunk bring top of the line systems to their knees.

thomasfoster962• 11 years ago

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.

castell2• 11 years ago

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.

pjmlp17• 11 years ago

Both drive my desktop PC fan to full speed, let alone what they do to my mobiles when the sites manage to render, if at all.

thomasfoster962• 11 years ago

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.

janl• 11 years ago

I’d love to take this discussion offline with a number key people. We have the Web Technology Fest in Berlin (http://wwwtf.berlin formerly 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/) 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

Thanks! <3

sytelus• 11 years ago

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.

aliakhtar3• 11 years ago

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

Agreed. I was just watching this talk the other day called 'Making web apps appy' froom Chrome Dev Summit: https://www.youtube.com/watch?v=QbuLq4f6DGQ

It talks about a lot of new incoming features, like push notifications from the browser, adding icons to home screen directly, offline access, etc.

slightlyoff• 11 years ago

Those features have all launched; see: http://blog.chromium.org/2015/03/chrome-42-beta-push-notific...

pjmlp17• 11 years ago

You mean, RPC, CORBA, DCOM, XML-RPC, SOA,....?

As someone has written on his tweeter account "Web APIs are hipster RPCs".

rimantas3• 11 years ago

  > Web APIs will and should become the standard way of
  > developing apps across platforms

God forbid. There are few lamer things than those Web APIs. Why do you think the gazzilion of frameworks exists, if not to work around all the things broken? And take a look at the web in 2005 and now, see what real progress was made. Yep, we got a bunch of half-baked APIs, which will never mature, because all the crowd already run forwrad to tick another checkbox.

TazeTSchnitzel10• 11 years ago

Why do you think the gazzilion of frameworks exists, if not to work around all the things broken?

Actually, most frameworks don't work around anything.

the84729• 11 years ago

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.

TazeTSchnitzel10• 11 years ago

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.

shawnreilly• 11 years ago

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).

robmcm2• 11 years ago

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".

blub2• 11 years ago

Many companies and teams had a "web hammer" and went looking for things to nail even when that made no sense. At the peak of the web frenzy, web apps were going to kill desktop apps, and one could feel the pity when web devs were talking about desktop and mobile apps. And now... someone finally stops and thinks that maybe it's not such a great idea to turn everything into a web app.

When a group of individuals takes such a strong position and they are proven to be wrong, I personally think some crow eating is due :-)

fizk• 11 years ago

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.

pjc507• 11 years ago

Youtube is an interesting choice of example, since in a way it's "just documents" - those documents happen to be video, and are surrounded by hyperlinks to other video's pages. The real achievement here was cutting through the intellectual property thicket so that everyone could have an in-browser video player in HTML5.

The first site I ever saw that used Javascript to produce a useful application rather than annoying frippery was Google Maps.

(Rhetorical question: why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces)

nivla2• 11 years ago

why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces

Two reasons: Bandwidth and Speed. Google has contracts with most major ISP's for caching Youtube videos. This gives them access to the best CDN money can buy! No matter how awesome or powerful your current datacenter/CDN is, it still wouldn't be able to match the fetch-straight-from-the-ISP performance. Interestingly this also creates a hidden monopoly since the barrier to entry is costly.

Grue3• 11 years ago

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.

Flash DRM replaced with another closed source DRM. No progress whatsoever. And now it has embedded in the browser itself, greatly increasing its vulnerability.

coldtea4• 11 years ago

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.

What exactly is incredible about YouTube today (apart from it being a huge repository of videos, of course)?

That it almost works like a 2000 era video player, only slower and clunkier? The new fangled DRM? That it can bring a decent computer to its knees with the fans blaring playing HD video? The automatic non-skippable ads?

pcwalton• 11 years ago

Discoverability, and elimination of the downloading friction.

YouTube is about as proven as you can get. The fact is that it didn't just edge past 2000-era video players in popularity, it totally trounced them. I think we should try to figure out why that is instead of arguing against YouTube's viability—it's about a decade too late for the latter.

haberman2• 11 years ago

That it almost works like a 2000 era video player, only slower and clunkier?

What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet. You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound. If you have a Chromecast, you can display the video on your TV instead.

Nothing in 2000 had a remotely similar feature set.

72deluxe4• 11 years ago

This cracked me up haha thanks

Fans blaring haha

the84729• 11 years ago

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.

mreiland4• 11 years ago

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

That's it exactly. The author claims it's an unsolved problem, I think it's the inevitable solution (that web and native will merge).

baldfat2• 11 years ago

shhhhssss there is no such thing as youtube-dl! I believe that the tool should be like Fight Club or it gets noticed and gets shut down through a drawn out war of changing code and apis.

adamc• 11 years ago

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.

wernercd• 11 years ago

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

And at it's core, BetMax is better than VHS. HD-DVD is better than Blu-Ray.

Often, it's not about what is "better". It's about who has the most moment, is easier, less encumbered by DRM, etc.

Sometimes it's better to download Youtube... more often than not, Youtube "just works".

rockdoe6• 11 years ago

pdfjs is great. but every 3rd scientific paper I read tends to be somewhat broken (missing diagrams/images) or sometimes fails to render completely.

Do you report these? It's been ages since I saw a PDF that pdf.js misrendered.

codingdave2• 11 years ago

You seem to be under the misunderstanding that video playback is YouTube's core function. No, the core functionality is to drive traffic to Google-owned sites, to be monetized as they see fit.

Remember, on the web, you are the product.

flowless• 11 years ago

Youtube's HTML5 video playback on my 3Ghz i7 is so bad that I rarely watch videos in browser. Now it's even worse as all videos play in low quality unless you use DRM enabled "tech".

This is what I use instead: mplayer -fixed-vo $( youtube-dl -gf mp4 $* "$link" )

gnaritas• 11 years ago

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

That isn't its core functionally, it's a social video sharing site, not a video playback site. It's core functionality is social sharing and all that goes with that, comments, related videos, channels, etc.

Nadya2• 11 years ago

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

I would argue YouTube's core functionality is "making it easy to share videos with family, friends, and the world". Allowing playback of the videos on the page makes this functionality easier.

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.

I do this too - although only because an addon I have causes Firefox to memleak if I leave a YouTube tab open too long. Rather than finding the problem and fixing it - I download a video I want to watch and close the YouTube tab. Honestly my video player of choice (MPC-HC) does exactly what the YouTube player does. It plays the video. Not a whole lot of bells and whistles needed to do that.

Too3• 11 years ago

Youtube used to be better before at video playback, not as good as VLC but much better than what it is today. I think they have to deliberately hamper the user experience in order to save bandwidth, just imagine how much bandwidth youtube must cost with the amounts of users they have. Even their native android app isn't exactly the greatest which makes the web vs native comparison a bit easier.

Examples of this hampering is that they only stream 20sec ahead instead of the whole clip in one shot. There are many other annoyances like this, like not giving you the HD version even though it says the video is HD and you've selected HD, or when it re-streams the movie when you switch from windowed to fullscreen, probably because the windowed version was too low quality.

baddox3• 11 years ago

YouTube's video playback problems might have nothing to do with the web. Despite having an iPad app that is otherwise mostly great, their iPad video player itself is abysmal. It's just flat-out broken, and they're presumably not going to fix it. If you start playing a video, the timeline at the bottom will start turning grey from left to right to indicate the part of the video that is buffered. But if you scrub to a position in the timeline that is buffered, the video player will spin for a rather long time, and sometimes just spin forever until you scrub to a new spot or manually change the video quality. Bizarrely, if you scrub to a position in the timeline beyond the buffer, the video will load nearly instantly like one would expect. Somehow the buffered video loads slowly, while unbuffered video loads quickly. It's a huge bug, it's been in the iPad app for as long as I can remember.

dbpokorny• 11 years ago

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

But can you build a democratic 24/7 music/video feed with a native video playback app? Maybe, but it is much easier with the web. And it has already been done:

http://botwillacceptanything.com:3000/video

https://github.com/botwillacceptanything/botwillacceptanythi...

I invite anyone with the time and inclination to submit a pull request that changes the content of the video feed.

webtards• 11 years ago

The problem is two-fold: it sucks for web developers who end up having to learn a new shitty framework every day, dogshit tools to even work with CSS and JS, endless preprocessor and transpilers, perverted markup and tag hell to support said shitty frameworks and having to deploy massive fuuckton heavy sites for a simple blog post. It also sucks hard for the end users : they can see their whole months mobile data allowance get pissed away on a couple of bling websites. It can takes ages now for modern site to finally work as it downloads so much shite. Some big name sites used to render quicker five or ten years ago. At least in the past, you could turn off scripting, images and styling and get to the basic content, but not even that works now due to crap developers. It all sucks. Diseased turtles all the way down.

wpietri5• 11 years ago

Sure. And you're also made out of meat and will die soon. And we're living on a planet that is in the long term doomed even if we half-evolved, tool-using monkeys get our shit together. (Did you know that we're half-way through the lifespan of forests? [1] That one day the conditions just won't be right for them anymore? That never fails to sadden me.)

But the interesting thing to me is what happens when we move past the existential despair that comes when we first recognize the true nature of things. Sure, things are fucked, but they always have been. What's next?

When I was as bitter as you sound here, I took a break. Burnout sucks. But eventually I found myself coming back to technology because it's my best chance to make the world suck slightly less. Or, put more accurately, to shift it in the direction of my irrationally high ideals.

So maybe take a break? Go hike the Pacific Crest Trail or work on a goat farm or something. You're not going to help anybody, yourself included, by soaking in something you hate indiscriminately. At least rest until you can come back and focus your hate in a laser-like beam on one particularly awful thing.

[1] http://en.wikipedia.org/wiki/Future_of_the_Earth

bphogan2• 11 years ago

I keep hearing this argument touted, but if you view source on the HN home page it uses tables and a <center> tag.

You do not have to learn a new framework to do things on the web. The browsers all seem to support stuff that's worked for years.

The problem is that web developers feel the need to learn new things because they fear getting out of date. "oh, dude, I learned React this weekend. It's hot stuff! You need to learn this."

No, you really don't. You have a plethera of choices, and one of those choices is to rock it like it's 1999.

yellowpop• 11 years ago

I can't help but feel like a lot of this has to do with "business realities", but maybe more importantly, it is also due to a whole generation of "developers" who have simply failed to learn CS fundamentals or did not start out with more traditional languages. The bad practices of the web are far easier to spread

voidhorse• 11 years ago

The framework problem is a real interesting one... I'm a hobbyist--I am not employed as a web developer, but I like too experiment and see what I can create, so for me, learning a new framework is always a fun little project to embark on.

At the same time, i can't imagine how hellish it would be to work for a company that always wants to use the latest technology -- the framework market seems saturated to me, and I would wager it's probably better for a company to find a few technologies and stick to them, tackling problems/weak points as they arise and brewing custom solutions for those if necessary. Having to stop and shift over to a new framework every now and then seems like it would be a massive productivity hit.

I also don't like it when a framework becomes a crutch. Though I don't think that happens too often for most people.

I've also run into the heavy weight problem -- there have been a few instance where I've wanted to create something simple, and in most cases using a framework in that situation becomes the very definition of over kill. So instead I'll usually just write a simple php script or something to do whatever I need to get done, but even that feels a bit unnecessary. While I'm not sure if javascript should be elevated to all the use cases it has been recently, I do think it should be a language that enables a developer to natively(that is to say, w/o a framework) handle any simple functionality that might be expected for a site that is just a little bit fancier than a static site, so handling very simple data such as bare-bones blog or a simple mailing system. While it is getting there you still can't do something like write a simple form based mailer in pure js as far as I know, you can only open the client's native mailing app. You'd have to write a single php file or some other mechanism for that simple purpose.

But yeah, it seems like bloat is a tricky thing to avoid these days, especially since frameworks are the easiest, usually most error proof, and quickest way to get your website full of some modern bells and whistles, when in reality you may only be putting half of the technologies features to use.

lloeki• 11 years ago

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.

The article says exactly that! It just says we shouldn't shoehorn native stuff into the web (e.g look at Synology's UI mimicking a nested desktop and windows).

We shouldn’t try to compete with native apps in terms set by the native apps. Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.

Youtube example perfectly fits that bill.

Yet there is also a critical difference to be made between "the web" and "web technology": while the former is operated in a browser, platforms such as Electron leading to apps such as Atom or Slack that totally don't try to mimic the native platform they're running on, powering cross-platform applications that nonetheless do try hard to respect† the platform they're running on, achieving something Java's cross-platform WORA GUI toolkit thoroughly failed to††.

† there's a clear, visible boundary between the native system and the webtech app, but that boundary is easily crossed, whereas historically we've been trying to erase the boundary and pretend it doesn't exist, only to veer straight into an uncanny valley.

†† dare I say Firefox sits right there too, forever battling the tide of mimicking native components with each OS release, from UI elements appearance (vanishing scrollbar, input fields...) to behaviour (non-"sheet" modal windows on OS X), in subtle but aggravating ways, if only because it erodes the product's image and detracts development resources from other efforts.

Fr0styMatt8• 11 years ago

It's interesting that you mention YouTube, because the thing that finally convinced me that a 'web app' could be indistinguishable from a native app was YouTube's Leanback interface (YouTube TV). Check it out:

https://www.youtube.com/tv

Video player functionality aside (I understand the complaints), that thing full-screened just feels like a native app.

lgieron• 11 years ago

For me, it was the Netflix web client. Feels 100% as smooth as a good native app.

Dewie34• 11 years ago

YouTube on TV is not supported on this device?

Is it only for mobile? I didn't see any "mob" or something in the URL. Anyway, with regards to being indistinguishable from native, I guess there is nothing quite like being reminded that you are "native" than an app complaining that you are on the wrong native device. :-)

72deluxe4• 11 years ago

I never knew about this URL, thanks very much.

pswenson• 11 years ago

sadly and inexplicably, youtube still uses flash for video on the desktop...

kuboa• 11 years ago

They had HTML5 video as a beta option for quite a while, and actually dropped Flash in favor of it as the default player about 4 months ago: http://www.theverge.com/2015/1/27/7926001/youtube-drops-flas...

the84729• 11 years ago

check https://www.youtube.com/html5

I get full <video> playback capability in FF nightly on windows and linux

smrtinsert• 11 years ago

Youtube is the first thing I point to apps on my mobile devices... Why would you ask your phone to dl megs of crap everytime instead of having instant video load?

Over the chain of ownership of any website I would say starting out trying to mimic a native experience will inevitably lead to a bad UX. Maybe not at first but it will. Part of the reason I use HN as a web site on my phone/tab is because it doesn't try to get fancy and just gives me a great web experience. Shocker.

stcredzero2• 11 years ago

You can spin this either way. Clearly, the web is just another UI for "your data." It's going to have a different set of tradeoffs than native or mobile. Why not just use tools for what they are the best at?

MPlayer can kick the pants off of YouTube in some contexts. Likewise, MPlayer wouldn't be viable for a vast number of YouTube use cases.

I can benefit tremendously from using both Audacity and SoundCloud. Why does one have to "win?"

wahsd• 11 years ago

Maybe I'm misunderstanding something here, but I don't think the argument is to cede the web to documents, but I also don't think the idea is to cede all functionality to apps.

I think the problem is the hype about native apps and everyone wanting an app without understanding their purposes, utility, and unique characteristics. There are situations where a web app / site is the exceedingly more appropriate solution, but there are other uses where a native app is equally exceedingly more appropriate. The problem is that people are having a difficult time discerning the two and the appropriateness of each.

I don't agree with this article and the sentiment about the critical question being whether people want your icon on their homescreen as being the differentiating characteristic. What is not discussed is the possibility for putting the icon on the home screen as a link to a web view that can function the way a native app can function. It even addresses a question regarding distribution if you simply ask your user whether they want to "install" or add an icon to their homescreen to install your "app" / web app / site. It can be designed in such a fashion that it is indistinguishable from a native app of a certain type that has rather narrow requirements.

marssaxman2• 11 years ago

I'm not sure we'd be missing out; the abandonment of the document model has cost the web much of its democratic, decentralized usefulness, and it still isn't a very good application platform no matter how hard people try to make it act like one.

jjtheblunt• 11 years ago

Are you kidding? YouTube is displaying a binary format, not ridiculous html, rendered by _native_ code integrated into the browser.

nly• 11 years ago

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

VLM• 11 years ago

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.

jlebrech• 11 years ago

web byte code

pornel3• 11 years ago

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• 11 years ago

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

pornel3• 11 years ago

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.

rockdoe6• 11 years ago

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 same problem exists on native.

pornel3• 11 years ago

Indeed, that's why I think it's a mistake to copy native with problems plaguing it (when we don't know how to add these features without the downsides).

I'd prefer the Web to stay safe and hassle-free, and use native apps—with the risk of letting malware in—only when I really need more powerful features.

bobajeff• 11 years ago

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.

archagon3• 11 years ago

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?

TazeTSchnitzel10• 11 years ago

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.

archagon3• 11 years ago

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

kokoloko• 11 years ago

I think it should be a subset of DOM / CSS designed for speed and flexibility. A normal browser could render the page correctly but an optimized browser for apps would be able to make some assumptions to render everything much faster. Something like asm.js but for DOM/CSS.

castell2• 11 years ago

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 and Mozilla's MDN have replaced it completely for me as it offers up-to-date information.

TazeTSchnitzel10• 11 years ago

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!

drinchev• 11 years ago

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.

pjmlp17• 11 years ago

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.

stuartmemo2• 11 years ago

Amazon's best selling laptops - http://www.amazon.com/Best-Sellers-Computers-Accessories-Lap...

brudgers2• 11 years ago

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• 11 years ago

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

brudgers2• 11 years ago

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.

gjvc• 11 years ago

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

some better-than-most discussion here:

http://arstechnica.com/the-multiverse/2015/04/from-the-vault...

whoisthemachine3• 11 years ago

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.

pjmlp17• 11 years ago

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.

whoisthemachine3• 11 years ago

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.

smhg• 11 years ago

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• 11 years ago

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.

rimantas3• 11 years ago

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.

blisterpeanuts• 11 years ago

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!

frik2• 11 years ago

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.

jrbapna• 11 years ago

Agreed

wwwtyro• 11 years ago

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/

cbd1984• 11 years ago

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

forgotAgain• 11 years ago

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.

joeblau2• 11 years ago

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.

virmundi2• 11 years ago

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• 11 years ago

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.

frik2• 11 years ago

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.

acdha2• 11 years ago

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.

The auto-update process on iOS is basically the same as recent versions of Android: check a box for completely automatic background updates or see a notification with the available update count and an “Update everything” button. The main difference is for things like games which hit the legacy 100MB cellular transfer limit which Apple added back when AT&T had grossly underprovisioned their network.

gwbas1c• 11 years ago

Ever hear of these things called "app stores?" I hear they make pushing apps quite seamless.

Apparently, these things called "app stores" are so good, that on these new things called "mobile devices," native apps are more popular than web applications!

Sorry for being a pedantic. Updating applications is quite painless on every platform except for Windows. (On Mac, you can use the app store or include Sparkle in your application.) It's only Windows that makes updating difficult; and this is the fundamental weakness of the operating system.

virmundi2• 11 years ago

I've heard plenty of people on HN bemoan the process of pushing updates out via Apple. You can have a critical bug (yes, yes better testing), but it can take the store up to a week to review, approve and deploy your app. Sure there are ways to expedite that, but should you have to be so concerned?

To me there should be a bit of a feeling when to use native vs web on mobile. If you're making a fairly static, pretty booklet app, I'd use web. Cordova makes this simple and clean. If your moving much beyond that, from personal experience, I'd go native. I've tried all of the free-to-type hybrids. The tools try to smooth over the issues of complex API centralize business logic in JS while having multiple views to target different OSs. Sadly, most only really support iOS. For example, Ionic tries to support Android, but it's general appearance is iOS. Appcelerator is the same.

stephenr6• 11 years ago

What about the benefit that the web brings to updating the user's install

What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data?

Notify the users to keep their equipment on the network from time X to Y

Not your problem. Have your packaged app in the place its expected to be updated from (a HTTPS server for something like Sparkle framework, and/or the respective App stores).

The client will periodically check for updates and download the new version.

If your back-end functionality somehow changes in a way that breaks the old version (or something changes such that the old version cannot be allowed to operate, such as a law changing) - you simply use a versioned API in your backend, and respond to requests to the old version of the API, with an error message telling user an update is required.

Your app is not the product. Your app is tool to get the product: information

That makes a huge assumption about the purpose of the app. If the app in question is a game, or an image editor, or a word processor or any number of other types of app - the app very much is the product.

If it lacks UX for native, don't target native. Target app-y

And say goodbye to customers. People like the experience of a real native app.

TazeTSchnitzel10• 11 years ago

What about the detriment the web brings to having apps that work offline reliably and ensure control over their own data?

The web has supported this for years, but few use it.

blub2• 11 years ago

This ease of updating can be beneficial for some types of software (e.g intranet LOB). I have two issues with it for consumer software:

* the customer is powerless when it comes to deciding whether to upgrade when e.g. the company decides to change strategies.

* the customer data lies unsecured, covered by a standard privacy policy in some foreign jurisdiction somewhere. HTTPS by itself is useless when the data is available to pretty much anyone working at the company and in some cases the server providers too. I think this covers 99% of web services out there like Evernote, Dropbox, FB, Google's stuff, etc.

jpswade• 11 years ago

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.

wtbob• 11 years ago

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.

UUMMUU• 11 years ago

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• 11 years ago

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.

Thiz2• 11 years ago

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.

Thiz2• 11 years ago

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.

pinaceae• 11 years ago

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.

bovermyer• 11 years ago

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.

snarfy• 11 years ago

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

Zigurd2• 11 years ago

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.

Zigurd2• 11 years ago

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.

codingdave2• 11 years ago

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...

jebblue• 11 years ago

jQuery Mobile and done.

dfield• 11 years ago

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... :)

fixermark2• 11 years ago

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• 11 years ago

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.

Too3• 11 years ago

Google docs is a great example of an app that should not be web. Especially google sheets, brrhgh, i get shivers just thinking about it. Even Excel 98 on a pentium 3 has better performance.

kwijibob• 11 years ago

Maybe for an advanced use you hit speed issues.

But Google Sheets has transformed many collaborative functions in our organisation. Especially at budget time.

The ability to have concurrent access to the latest version always is wonderful. No more emailing attachments.

Also being able to sit down at a budget meeting and everyone can view the work-in-progress as it develops on their own device.

In all of this we've never had any one bothered by lack of speed.

mangeletti• 11 years ago

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).

leecarraher• 11 years ago

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.

markbnj• 11 years ago

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.

hypertexthero2• 11 years ago

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...

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

[3] http://worldofends.com/

tim333• 11 years ago

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?

dasil003• 11 years ago

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?

Too3• 11 years ago

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.

zokier3• 11 years ago

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

netfire5• 11 years ago

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.

EGreg• 11 years ago

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

gwu78• 11 years ago

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.

xtx23• 11 years ago

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.

_urga• 11 years ago

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...

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.

methehack• 11 years ago

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.

hypertexthero2• 11 years ago

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

kogus• 11 years ago

I think this is a false choice. To a large extent, the web is native, and the browser is the operating system.

perseusprime2• 11 years ago

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

netfire5• 11 years ago

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.

perseusprime2• 11 years ago

Wouldn't they then become emulators of app runtimes?

oldpond• 11 years ago

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.

thegoodlab• 11 years ago

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.

dgreensp2• 11 years ago

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.

gedrap2• 11 years ago

>> 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.

dgreensp2• 11 years ago

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.

piyush_soni2• 11 years ago

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?

bcg1• 11 years ago

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.

kenjackson2• 11 years ago

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.

ghostly_s• 11 years ago

If someone tells me about an "app idea" without specifying platform I assume a mobile-native app. I do not think I am in the minority in this.

vezzy-fnord2• 11 years ago

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.

kenjackson2• 11 years ago

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. :-)

mike_hearn2• 11 years ago

Yeah? Spotify, Skype, Google Earth, any developer tool, iTunes, Sonos, Keynote, MS Office, Photoshop, any video game ..... there are plenty of popular native desktop apps out there. I'd say there'd be more too, if the industry made them more frequently. But all we churn out are web apps these days - not because that's what users demand but for all sorts of other reasons.

_joev• 11 years ago

"Native desktop" spotify is just a web app wrapped into an embedded Chromium browser.

millstone• 11 years ago

The last time is probably Photos for OS X (though of course that's not Win32). I doubt that a web app can manage the same number of photos as well.

I think the biggest change is that people have mostly stopped paying for desktop apps, outside of professional tools. I have yet to buy a program written in HTML and JavaScript, though I have paid for content and services provided through such apps.

rawTruthHurts• 11 years ago

Yep. The Firefox version of Photoshop really cuts it. Not to mention the 3dsMax one.

anthony_romeo• 11 years ago

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.

fixermark2• 11 years ago

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).

kuma4• 11 years ago

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.

javiramos• 11 years ago

I consider Onshape to be a big win for web: https://www.onshape.com/

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

feld• 11 years ago

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.

orthecreedence• 11 years ago

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), 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.

BadassFractal• 11 years ago

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.

pbreit• 11 years ago

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?

downandout• 11 years ago

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.

carsongross• 11 years ago

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).

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.)

krick2• 11 years ago

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.

zokier3• 11 years ago

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

krick2• 11 years ago

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.

z3t4• 11 years ago

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• 11 years ago

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-y2• 11 years ago

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.

mathattack• 11 years ago

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?

sixQuarks2• 11 years ago

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.

JoeAltmaier2• 11 years ago

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.

sixQuarks2• 11 years ago

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

mike_hearn2• 11 years ago

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

That's a common belief but isn't correct, of course. Otherwise ChromeOS would have crushed the competition and it's hardly made a dent.

Many, many people use and heavily rely on native desktop apps every day. Usually for getting real work done once they tire of procrastinating on hacker news/facebook/etc :-)

Just consider the importance of MS Office to the global economy!

This is despite the fact that the shepards of the native desktop app platforms all screwed up big time and dropped the ball in major ways allowing the totally unsuitable yet somehow still good HTML platform to take over:

• MS/Apple/etc STILL have never shipped non-terrible software update mechanisms. Only Google managed to get this right and their online update engine was basically just for them.

• No discovery or sandboxing mechanisms worth a damn.

• Heavy reliance on languages like C++ that many developers can't handle (whereas web was fully built around scripting languages)

• The only people who cared about doing cross-platform desktop apps were Sun and Trolltech, and they sunk into the swamp of pretending to be the real OS-specific widget toolkits. Web apps collectively said "fuck that shit" and we saw a glorious explosion of styles with every web app branding its own widgets differently. Users, it turned out, wanted attractive apps rather than native-looking apps and so the web won on this count even though the HTML widget toolkit is a joke.

• Speaking of widget toolkits, the web is so primitive that it forced developers to abandon UI design paradigms that were actually rather user unfriendly, but commonly used because the platforms made it so easy. Prime offender: tree widgets. Hardly ever used these days as they have terrible usability. HTML has no such widget. Also: context menus. Users never find things in them. HTML simply doesn't let you customise the context menu at all.

So the combination of uber-simple programming languages, a cross platform UI story that ignored the massive must-look-native timesink, clean/invisible online updates, etc ....... almost by accident it ended up being compelling.

Now compare to mobile, where native apps are doing a lot better. Android is Java based so no problem with C++ being unapproachable. Objective-C kind of sucks but is still easier than C++ in many ways, plus iOS is big enough that developers just have to suck it up. There's built in sandboxing and app updates have been a part of the platform right from day one. The widget toolkits are way more modern and result in simpler/more intuitive UIs than classical desktop toolkits, so dysfunctional design patterns like nested trees with tiny icons don't crop up. The toolkits almost force simple, intuitive designs. And because mobile is (a) very new and (b) very restricted, writing the app twice with two different user interfaces isn't necessarily a killer problem, whereas for gigantic mature desktop apps with a 20 year feature set like Photoshop/Office it's just really expensive to do that. So the not-quite-native issue is less prominent.

eighthave2• 11 years ago

Look at Android, the most popular computing platform in the world, and you will see how native has won. Even Facebook and YouTube are native apps on Android.

superuser2• 11 years ago

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• 11 years ago

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!

lewisl90292• 11 years ago

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/

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.

s73v3r5• 11 years ago

"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.

lewisl90292• 11 years ago

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.

bcheung2• 11 years ago

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.

meesterdude• 11 years ago

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.

ajkjk• 11 years ago

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.

eighthave2• 11 years ago

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.

nickpsecurity• 11 years ago

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.

sclaxton• 11 years ago

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...

RRRA• 11 years ago

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!"

click1702• 11 years ago

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?

shiggerino• 11 years ago

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‽

minusSeven• 11 years ago

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.

hlfcoding• 11 years ago

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

AnonJ• 11 years ago

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.

MidoAssran• 11 years ago

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.

Web vs. native: let’s concede defeat

Related Stories