While I agree on your point, your comment made me smile as I’m reading HN using a mobile app

I'm curious, did you start using HN with the mobile app or migrate to it after you realized the usefulness of the website?

I migrated to the mobile app after discovering the site. I find the app greatly increases the readability of the site by adding just a few more colors, some icons for particularly popular threads, and a palatable dark mode.

So nothing that couldn't be solved by a better mobile friendly web site?

You could always use https://github.com/openstyles/stylus to customize HN looks like

Oh wow, this is fantastic, thanks! I wonder if I can run it on FF mobile to make the site more friendly.

EDIT: I can, awesome. If anyone has a good theme to suggest, that would be fantastic.

Which app are you using? There are quite a few on the Apple store.

> Think of it like this: If Hacker News required a fat client to function on your desktop, would you actually be here at all?

HN essentially is a service that provides only a couple of text views to list and read submittions and their discussions, and requires zero processing or interaction. That's hardly a challenging problem that requires a fat client.

If however we were discussing an application that required significant data processing, access to your personal data, or even access to photo ir video input... You'd hardly be able to implement something with HTML+CSS.

Case in point: twitter is very usable as a website but instagram is not.

On mobile, you don't use a fat client for HN? I've even paid money for an app (MiniHack) to have a nicer experience on mobile.

Truth be told, a full blown mobile app isn't needed to tweak the UI or provide different views.

They wouldn’t have to change much about Instagram to make it into Twitter.

If you take away those features then you cease to have instagram.

Instagram users only use instagram because it provides access to those functionalities.

What functionality are you referring to? The only one I can think of is photo editing. It’s not that difficult to make a photo editor in the browser. The only problem is performance. It would’ve been harder when Instagram was originally launched.

Instagram is perfectly usable as a website, at least on an iPhone. I guess some features might be missing, but the core stuff is there: browsing, adding photo, filters, stories.

How do you post a photo on instagram in a web browser? I thought that was reserved for the app.

You can post a photo on instagram in a browser on iphone. you also can on other platforms by changing your useragent to webkit

Add a file input -> the users taps it -> ios asks if they want to use an existing photo or take a new one -> take a new photo. Result on android may differ.

Interesting, they don’t seem to allow this on the desktop browser. Changing the user-agent yo a mobile browser exposes it. What a strange decision.

I don’t use Instagram so can’t check the code, but I would guess they use something like

    <input type="file" accept="image/*" capture>

Which does what you’d expect on a mobile device (launch the camera) but behaves differently on desktops (opens a file upload dialog). They may have decided that this behavior would confuse users.

How do you ensure that a client only sees a picture/video once and can't save it?

The photos are available as publicly accessible jpgs through http. They’re not really trying to do that.

You can't ensure this natively either.

> That's hardly a challenging problem that requires a fat client.

That's irrelevant. It doesn't matter that making a fat client for HN isn't necessary; that's completely beside the point. You're looking for reasons to ignore the stated premise of an analogy rather than accepting that the premise would be true.

It's like this. Say you were beginning to explain how network services work with an anecdote: "Say you need to go to the market to get a carton of milk." Suddenly your listener stops you and says, "But I don't like milk."

If your response to the above paragraph is, "But I don't know how network services work," then, congratulations, you can look forward to an exciting career in either comedy or politics, depending on whether or not you were serious.

Can you please not post flamewar-style comments to HN, regardless of how wrong or provocative you find another comment? We're trying for better than this here.

https://news.ycombinator.com/newsguidelines.html

Ok, jumping in here. So yes, HN doesn't 'need' a full app, but the functionality difference between this site and Reddit isn't that great. So why, pray tell, does Reddit nag me every time I visit on mobile?

It certainly isn't that the app provides functionality that isn't avaliable through the browser, but somebody decided that it was worth spending development time and nagging users over. So yes, there are things that can't be implemented through the browser and require an app, but it's incorrect to state that nobody develops an app unless they absolutely need to.

I would suggest that quite a few people write mobile applications because their managers tell them to do it. This is totally independent of whether the use case requires a mobile application.

Given that all websites are running code on your device, that seems like a distinction with a very small difference. The question is what has the better sandbox to protect yourself. The web is definitely better but somehow I still get tracked across sites and shown "relevant" ads. Mobile apps are also fairly well sandboxed and yet some apps that need your permission to do something useful also use that permission to do evil.

As web applications get more powerful, they will become a greater and greater source of the issues that currently plague mobile apps.

Most mobile apps are really just glorified websites that don't need anything above and beyond the web sandbox. But they're going to ask for those permissions anyway, because when an app is the only way to use a sufficiently popular service, people will grant them.

It is much easier when being nice is enforced by a third party - in other words, the webpage might have an interest in taking all your cycles, but the browser app has an interest in the opposite (battery life and whatnot). So far, this seems to work well - for all the gripes of FB Messenger taking all the CPU and requiring every permission in the known universe, the FB mobile web gets adequately sandboxed by the browser.

(I am aware that the Android app model has also promised some sandboxing, but apparently even in a low-permission mode, the protection seems to be rather anemic)