I would say interactivity. A spreadsheet for example, you are constantly modifying rows. You want that in memory in the browser, not on a server, where you need to constantly be making ajax calls.

How many micro-interactions do you want --- the more you have, the more likely you want an application rather than a site.

For me it is reading vs doing.

When you first go to aws.amazon.com, you get a website with content about AWS.

Once you log in, you’re in the AWS web application, and it’s time to start doing things.

Forums like HN, I would consider websites because there is a lot of reading and not much doing.

I'd say there's is not a clear definition, but I think: low interaction intensity / no personalized experience = website, high interaction intensity / personalized experience = application.

Wikipedia and blogs are mostly for consuming content and it's the same content for everyone. Clearly a website. Instagram usually isn't super interactive, but it's extremely personalized, so it's much more like an app. Gmail also clearly a web app.

Facebook used to be server side PHP and it always was personalized. I think the distinction is more about the degree of interactivity. Highly interactive GUIs (the hell of jQuery developers) went to SPAs and are called webapps. Low interaction GUIs could be server side rendered with the technologies of 20 years ago even today. Most banking sites are low interaction and could be old style Java even if almost every one I see is a SPA now. The distinction is very fuzzy.

Why would an SPA do a "personalized experience" better than a traditional website?

Amazon is highly personalized and fits well into the standard web page paradigm. What about Instagram's "personalization" wouldn't work as a standard web page?

> What about Instagram's "personalization" wouldn't work as a standard web page?

Really nothing. But for most people Instagram is primarily a mobile application and comes with the usual experience of a mobile application. Transitions, fast reactions, no "whole page" reloads, etc.

Continuing this experience into the less frequently used browser version only makes sense, especially given the fact that Instagram's tooling allows for a relatively easy transfer (iirc large parts of the mobile apps are implemented using React Native)

Possibly old fashioned view here but I think of it in two ways.

Firstly if it's "transactional" it fits more often into the label of "application". If it is there mainly for consumption of media, it's more "Web site".

Secondly, I think it's useful to think about what it'd feel like as a desktop app. Stuff like say Google Sheets would feel perfectly normal running on your desktop. It's super snappy, all on-page. Something like the BBC or HN, not so much.

At a very superficial level, HN feels like a website and logging in to do my banking feels like a web application. But trying to drill down into specific definitions or draw a clear line between them seems to fall apart quickly. So I guess for me at least I really don't know the answer, but also don't think it's terribly useful to make a distinction either.

A bank should be a website (if only my bank would agree...). If you're making a Photoshop clone in the browser, that's web app territory.

>But trying to drill down into specific definitions or draw a clear line between them seems to fall apart quickly.

The only clear line I've seen is javascript. If it uses javascript for anything nontrivial, people believe it's a web app. This comes up all the time in threads about "the old web" or "how you would fix the web," in the context of what seems to be a prevalent belief on HN that the web should be split up between the two paradigms, with purely static, noninteractive "sites" in one place, and "apps" in the other.

Problem is, as mentioned upthread, the vast majority of sites using javascript, including SPAs, are still meant to be read as documents. If you include any form of interactivity, including backend processing and rendering, even more sites become apps.

In practice, it seems to me to be more of a religious taxonomy than a technical one, based on the belief that the modern web has become tainted by complexity and needs to be made pure again.

> In practice, it seems to me to be more of a religious taxonomy than a technical one, based on the belief that the modern web has become tainted by complexity and needs to be made pure again.

I see it more being whether a page uses progressive enhancement. If I can disable JavaScript and at least be able to read a page's content, then its a web page rather than an app. If JavaScript is an absolute requirement for any functionality it's an app.

A page with some client-side form validation, AJAX submissions, or even just some dynamic content are awesome uses of JavaScript so long as the pages themselves don't hinge on me running the JavaScript. Posting a comment might be a POST and clicking an image thumbnail might load it in a new tab instead of a light box. The functionality is all still there if for any reason the JavaScript doesn't load.

One of my big problems with "apps" is they have zero provisions for JavaScript not running. Most "apps" don't even give an error page telling you explicitly JavaScript is required. Even when you have JavaScript enabled they tend to break in stupid ways if you've got an ad blocker.

i'd say the dynamic of the content.

anything that can be done offline ought to be an SPA so that it can be made to actually still work without internet access.

number of pages