Skip to content
This repository has been archived by the owner on Aug 2, 2020. It is now read-only.

Make web application more lightweight #60

Open
clarfonthey opened this issue May 7, 2019 · 8 comments
Open

Make web application more lightweight #60

clarfonthey opened this issue May 7, 2019 · 8 comments
Labels
A-accessibility (Affects) accessibility A-compatibility (Affects) compatibility with apps, other software, etc. C-main-view Main view on web interface (component) E-big (C) Big (effort) to implement K-planning (Kind) is a general goal without concrete plans P-substantial (A) Substantial (impact) of change V-compatibility-bump Breaking changes that require a compatibility (version) bump

Comments

@clarfonthey
Copy link
Member

Right now, everything is a giant React app, which is very heavy. We might want to consider moving to something like Redux which is lighter weight, or potentially something entirely different. #48 (separating frontend and backend) might also allow for different web app versions, depending on user needs.

Basically, this is going to be a master tracking issue for ways to make the web app faster.

@clarfonthey clarfonthey added A-accessibility (Affects) accessibility K-planning (Kind) is a general goal without concrete plans C-main-view Main view on web interface (component) V-feel-bump Really big, disruptive changes that require a feel (version) bump A-compatibility (Affects) compatibility with apps, other software, etc. labels May 7, 2019
@clarfonthey clarfonthey added this to the 2.0.0 and beyond milestone May 7, 2019
@jhaye
Copy link
Contributor

jhaye commented May 7, 2019

Another suggestion from my side: The web client seems to be fetching the originally uploaded avatar image. Which usually means that they are much larger than they need to be at the size they are displayed at.
Also if the original file was uploaded as a PNG, that file will be loaded unaltered.
I don't know if Mastodon's API offers different resolutions for a file like this, but if not, that should be implemented. This would also improve the bandwidth requirement for other clients, if they choose to implement it.

@Feufochmar
Copy link

About the icon, I noticed that the actor's icon provided in the ActivityPub API is also the original image. There is no way in ActivityPub to provide different sizes, however it is indicated about icons in the ActivityStream spec that: "The image should have an aspect ratio of one (horizontal) to one (vertical) and should be suitable for presentation at a small size".
There is no need to keep the original image when the user sets their avatar. We could already resize the avatar to 128x128 (if larger) when the user sets the avatar and when the server fetches the avatar of non-local users. This may already improve bandwidth (and disk usage).
On the public profile page, the size of the avatar is 128x128, and it is smaller in the other contexts.

In the Mastodon API, the avatar of an account is typed as "String (URL)". Providing several sizes means we need to change the API to provide an object listing the different URL by sizes or to add a mecanism in the url to indicate the wanted size and let the server resize the image.
However, the Mastodon service does not usually serve itself the images, they are served directly by the proxy in front of it (when stored on the same server), or by a storage service (when stored on the cloud).

@jhaye
Copy link
Contributor

jhaye commented May 7, 2019

There is no way in ActivityPub to provide different sizes

I have to concede that I don't know much about ActivityPub, but within the ActivityStream spec there is this example for the icon object:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "A simple note",
  "type": "Note",
  "content": "A simple note",
  "icon": [
    {
      "type": "Image",
      "summary": "Note (16x16)",
      "url": "http://example.org/note1.png",
      "width": 16,
      "height": 16
    },
    {
      "type": "Image",
      "summary": "Note (32x32)",
      "url": "http://example.org/note2.png",
      "width": 32,
      "height": 32
    }
  ]
}

I guess the biggest challenge is keeping things compatible.

@meltheadorable
Copy link

There are two different reduxes, neither is a replacement for react

Redux Framework linked above is for building wordpress plugins
The Other Redux is for state management in javascript apps, and mastodon's frontend already uses it

Most lighter-weight solutions would imply moving more of the logic and rendering from the client to the server -- in general that means less separation between backend and frontend rather than more.

Performance improvements are either going to have to come from harder optimizations to the SPA, dramatically reducing the complexity of the frontend so that it can still be implemented client-side with something lighter than react, or moving logic & rendering to the server. It's a game of tradeoffs, so articulating the performance goals here will be important.

@Feufochmar
Copy link

@jhaye I misread the spec... However, I haven't seen yet an instance where an array of images is provided for the avatar (only an image, without any indication of size). I should investigate with the other implementations.
Though, I don't think we will be able to offer this feature while staying compatible with the current Mastodon API.

@mkljczk
Copy link

mkljczk commented May 16, 2019

What about trying to migrate from React to something like Inferno or Preact?

@clarfonthey clarfonthey modified the milestones: v1.2, v2 May 25, 2019
@clarfonthey clarfonthey added V-compatibility-bump Breaking changes that require a compatibility (version) bump and removed V-feel-bump Really big, disruptive changes that require a feel (version) bump labels May 25, 2019
@ghost
Copy link

ghost commented Jun 3, 2019

Preact would be a nice first goal, but I personally found that Vue apps are really lightweight. If you go that route I can help a bit :)

@mkljczk
Copy link

mkljczk commented Jun 3, 2019

@Makmm I really love Vue, but Preact and Inferno apps are usually more lightweight and migration seems to be easier…

@clarfonthey clarfonthey added E-big (C) Big (effort) to implement P-substantial (A) Substantial (impact) of change labels Jun 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-accessibility (Affects) accessibility A-compatibility (Affects) compatibility with apps, other software, etc. C-main-view Main view on web interface (component) E-big (C) Big (effort) to implement K-planning (Kind) is a general goal without concrete plans P-substantial (A) Substantial (impact) of change V-compatibility-bump Breaking changes that require a compatibility (version) bump
Development

No branches or pull requests

5 participants