Differentiating apps vs sites

[andreicek]

This is a migrated issue. Original issue by @filipjakov.

Why?

(Inspired by this article) I feel like on a team level we haven't put a clear line between working on a (Web)app and working on a (Web)site. I'd like to evaluate them on a couple of points (first came to my mind, ofc there are many more):

1. Team size:

• Web Apps are usually developed with bigger teams, and in order to develop more efficiently, we face some "people challenges": a well-defined file/project structure, proper systems (for example styling), branching/merging/release system, proper PR reviews, inter/intra team communications, documentation, testing, knowledge sharing, ...
• Web Sites are usually developed with smaller teams, meaning that (usually), some above points are overhead

2. Purpose:

• Web Apps primarily exist for interaction. CRUD apps, live stream apps, games, integrations
• Web Sites primarily display content, while interaction is limited. First-load times are paramount since users may bounce and/or their limited data/power/CPU may deprive them of important information

3. Project lifespan

• Web Apps usually have longer lifespans, which puts even more emphasis on the first point (team size "problems")
• Web Sites usually have shorter lifespans

4. Estimation:

• Web Apps: initial + additional as the project lives
• Web Sites: usually just the initial; everything should be known/taken into account beforehand to plan accordingly

5. Where is the code run:

• Web Apps: sometimes on the server, but mostly on the client
• Web Sites: preferably on the server; the tendency is towards just serving "pre-compiled" Html to the client (SSG)

6. Tests:

• Web Apps: +
• Web Sites: -

7. Dependencies:

• Web Apps have a "tendency to simulate native apps". Introduced dependencies are usually JS-heavy (to complement the interactions) and are meant to take care of the shortcomings of the platform
• Documents are first-class citizens of the web. Since the interactions are limited, the main focus is on the content and its presentation which is usually done through CSS

Also, although both sites and apps should take the following points when starting the project:

• a11y
• minimal code footprint and its optimization (min js, above-the-fold-css)
• optimizations of assets - images, fonts, svgs, ...
• performance scores (lighthouse)
• client testing (for example bandwidth throttling)
• SEO

they are usually an afterthought in apps since the focus is on rapid feature development and delivery and the previous points (maybe) get taken care of later when the app "stabilizes". For web sites, it is very important to have the previous points in mind and work with/plan them as soon as the project starts.

The proposal:

1. Introduce the notion of apps vs. sites into our handbook

We already have a lot of great handbook content centered around specific technologies (Angular, React, ...), and lots of that content is interdisciplinary (apps vs sites):

• file/module organization and naming,
• formatting, naming, and best practices
• ...

What we do not manage on a team level:

• SSG vs. SSR
• a11y (there's already a task for it :D )
• minimal code footprint and its optimization (min js usage, above-the-fold-css) - tooling and practices in the context of site creation
• optimization of assets - images, fonts, SVGs, ...
• performance scores (lighthouse), their meaning, and how to tackle them
• client testing (example: bandwidth throttling)
• SEO

2. Just add the chapters:

Some of the previous points that would need to be tackled can just be separate chapters on the handbook, and people can reference them when they need them.

The execution

Since I am currently in the possession of a huge number of articles that describe the previously mentioned points, the idea would be to give an overview and link to specifics (a collection of link-heavy documents).

Since we have a variety of technologies we are working on on a team level (React and Next.js being the obvious candidates when starting any new project, but also taking technologies like Scully/Universal (Angular) and Nuxt (Vue) into account), it makes sense that the chapters are framework agnostic and just link to explicit implementations/usages.

IF we are going with this because the idea of sites vs apps overlaps in some aspects, I am not sure about how to structure this document(s) and how much (even if), existing documents need change.

What do you think?

[andreicek]

This is a migrated comment. Original comment by @DarkoKukovec.

We already talked about this in person, the problem is that (at least for our projects), there is no clear line between those two types - almost all projects have a certain site and a certain app component.
Therefore, if we go into a separation, it should be more granular, e.g. page based instead of project based.

The better question is, what would be the goal of this separation...

• SSG vs. SSR - both of them will be most likely be used on sites, it will depend on the context which one is the right one in that specific scenario
• a11y - should there be any difference between sites and apps? Everything should be accessible (at least to a certain degree)
• optimization of assets - should be done for everything
• minimal code footprint, performance scores, client testing - agree, makes sense to spend more time on this for sites
• SEO - I would say that this is more of a public vs. private page thing instead of site vs. app

The problem is, the difference between them is not that big (mostly related to optimizations). IMHO, everything else has some unrelated factors and will probably need to depend on the common sense of the developer.