Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

Post reply on HN
Print view View original

451–460 of 515 posts

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

#451

Post by zenware »

ams6110 wrote: post #313
piyush_soni wrote: post #299

Earlier quoted context omitted.

People had imagined and implemented that long back. They were called plugins. Thank god, media player plugins are dead.

I don't recall plugins ever offering much choice. "Please install Flash to view this content" is what I remember. If I could stream directly to VLC or a player of my choice I'd be happy with that.

Someone wrote a browser extension for Flash to be replaced with VLC on twitch.

https://www.reddit.com/r/WatchPeopleCode/comments/3273es/pro...

It wouldn't be hard to make that work on other sites that have a flash player. But we aren't quite sure if it improved the performance or anything, it just felt right.

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

#452

Post by ajkjk »

Things native apps do well:

- Run offline

- Access large files stored locally

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

- Use graphics cards and other peripherals

- Run quickly

- Tune performance to your platform

- Come pre-installed on your system

- Exist for all time

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

- Security is pretty easy to solve

- Coded in pretty much any language

- Interop with other native software

- Run in windows or fullscreen

- Easily convince people that they ought to be purchased

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

- Handle large amounts of data without network bandwidth constraints

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

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

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

- Save data across multiple systems

- Allow you to login anywhere

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

- Receive updates from their maintainer

- Run multiple instances at once with a single click

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

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

- Live in easily manageable tabs

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

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

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

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

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

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

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

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

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

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

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

--

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

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

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

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

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

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

#453

Post by throwaway2048 »

joeyspn wrote: post #450
pavlov wrote: 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…

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

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.

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

#454

Post by Nadya »

ams6110 wrote: post #313
piyush_soni wrote: post #299

Earlier quoted context omitted.

People had imagined and implemented that long back. They were called plugins. Thank god, media player plugins are dead.

I don't recall plugins ever offering much choice. "Please install Flash to view this content" is what I remember. If I could stream directly to VLC or a player of my choice I'd be happy with that.

This is an issue with the service not providing direct links to the video.

If you open an .mp4 file in Firefox you can set it to open in an application through your "Applications" settings. By default it prompts "Open with..." or "Save as..." in a dialogue.

If you open a direct link to a video you can open it to play in VLC (or player of your choice).

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

#455

Post by netfire »

EliRivers wrote: post #440
netfire wrote: post #300

Earlier quoted context omitted.

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

I'm not limiting the web. You're not limiting the web. The web has limits . Actual, hard physical limitations (along with confidentiality and privacy limits); limits that something running entirely locally, directly with your actual operating system simply suffers, and will always suffer, to a much, much, much lower degree. Your opinion (and my opinion) is meaningless when confronted with actual, physical reality. Ri…

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

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

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

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

#456

Post by [deleted] »

_joev wrote: post #409
mike_hearn wrote: post #399

Earlier quoted context omitted.

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.

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

[deleted]

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

#457

Post by yellowapple »

pavlov wrote: post #396
yellowapple wrote: post #359

Earlier quoted context omitted.

> Android 5.x has less than 10% marketshare, and 4.x seems quite resilient in low-end devices. Folks were saying the same exact thing about 2.x when 4.x came out. By the time 6.x comes out, everyone will be yammering on about how 5.x marketshare is still strong and "seems quite resilient in low-end devices", blissfully ignoring the point in time when 4.x - like 2.x - fades out of view as it's increasingly ignored by…

In the real world, Firefox OS has zero marketshare at the low-end. Mozilla announced just a day or two ago that they're abandoning the low-end strategy. Featurephones are largely gone. Microsoft bought Nokia's featurephone business, shut down further development and has been converting it to low-end Lumias as fast as they can, but Android is nibbling away most of that market.

Mozilla only announced that they're abandoning efforts to build the lowest-end stuff. IIRC, most FirefoxOS handsets are still pretty low-end, and have been doing reasonably well.

And feature phones are still dominant in places like Africa and South America, particularly due to their lower cost and power consumption (smartphones are still unable to reach the battery lives of even dumbphones from a decade ago, which is an important consideration in environments with limited/inconsistent electricity). Even in "developed" countries, feature phones are popular with the elderly and disabled, since they usually feature physical buttons that are easier to work with (better tactile feedback, easier to find with poor vision, etc.) and have simpler interfaces.

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

#458

Post by joeyspn »

throwaway2048 wrote: post #453
joeyspn wrote: post #450

Earlier quoted context omitted.

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

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.

Ok, valid point... But still the Ghz's per core are also increasing, and with that the overall performance. If you've used webapps like Popcorn-time or Slack you'll understand what I'm trying to say.

Are they native? No, they're JS apps

Do the users care? No, cos they do the "job" pretty well

We're reaching that computing power with mobile devices. In fact current mobiles are like desktops of 3/4 years ago. For certain kind of apps it won't matter if they're built with web technologies. (I'm not saying that you should bet on WebGL vs OpenGLES)

It's all about the use case.

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

#459

Post by yellowapple »

nucleardog wrote: post #411
yellowapple wrote: post #346

Earlier quoted context omitted.

You could easily address those concerns without turning what should be a simple video into a clusterfsck of Javascript. For example: https://mytube.com/$username/my_first_video.ogg With such a scheme, you immediately know who made it - $username - and (if this hypothetical mytube.com built a proper website) navigating to mytube.com/$username would return a list of videos (maybe with some additional routes for playlis…

URLs are opaque strings to the typical user.

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

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

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

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

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

#460

Post by eighthave »

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