Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

61–70 of 515 posts

Re: Web vs. native: let’s concede defeat

#61

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

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

Re: Web vs. native: let’s concede defeat

#62
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?

Re: Web vs. native: let’s concede defeat

#63
post #28

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…

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

Re: Web vs. native: let’s concede defeat

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

Re: Web vs. native: let’s concede defeat

#65

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

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

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

Re: Web vs. native: let’s concede defeat

#66
post #5

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 b…

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

Re: Web vs. native: let’s concede defeat

#67
post #5

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 b…

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

Re: Web vs. native: let’s concede defeat

#68
post #21

Earlier quoted context omitted.

does react native support android yet?

About 4 months away now I think. But you could conceivably use something like Reapp until React Native supports Android. That's what I'll likely end up doing. Not ideal but React Native has already saved me so much time I'm not worried about the Android problem really.

Thanks for mentioning Reapp, I hadn't heard about it. I'm facing the same problem as you as I'm starting to build an app for Android and iOS and I can't really see myself building it the 'old way' after having tried React Native. Have you tried Reapp?

Re: Web vs. native: let’s concede defeat

#69
post #44

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 rep…

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.

Re: Web vs. native: let’s concede defeat

#70
post #24

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.

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

Post reply on HN