Live data from Hacker News

Web vs. native: let’s concede defeat

quirksmode.org

261–270 of 515 posts

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

#261
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

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

#262

Earlier quoted context omitted.

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

Care to name the technology that allows a browser app to read/write file data to local storage that isn't inherently tied to the browser?

Why is it being tied to the browser a problem?

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

#263

Earlier quoted context omitted.

The business realities make direct, free, downloadable videos impossible rather than unlikely at scale.

>business realities make direct, free, downloadable videos impossible at scale And yet it's existed for years using p2p/torrents. So they're more like business fictions

Do you feel you made a point by listing services that exist only by breaking the law to exist as somehow related to business reality? Making your money by trampling the rights of others isn't exactly sustainable. The only way you have a point is to be rampantly intellectually dishonest, or ignorant of reality. Neither option is great, so charitably, it's best to assume you know this stuff and you're just trolling. Also not great. Do you have a 4th option?

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

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

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

#265
post #168

Earlier quoted context omitted.

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.

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

Works in Chromium on Linux for me.

In Firefox (my default br.) the message is: "Youtube on TV is not supported on this device, for more info go to: www.youtube.com/devicepartners" which is unclickable and unselectable. Modern web...

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

#266
post #248

Earlier quoted context omitted.

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

I agree with most of what you say, but: you start having to litter your code with `if(isAndroid)`/`if(isIOS)` That's an inevitable drawback of a cross-platform framework like this. XCode and Android Studio only work with one OS, so they sidestep it.

Sidestepping a problem in universal app development by don't doing it.

You're joking right? ;)

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

#267
post #85

Earlier quoted context omitted.

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

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

I don't think that you can call BetaMax's somewhat superior picture quality objectively better than VHS's factor of two advantage in storage.

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

#268

Earlier quoted context omitted.

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.

To modify the Fight Club rules to ensure X (whatever topic you mention) does not get discussed: 1. There is no X. 2. There are no comments about X. 3. There are no comments about comments about X. 4. (recur away) Oh, wait. This sounds like censorship.

Or just get down voted to where no one can see the comments.

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

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

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

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

Post reply on HN