GoKawiilHere's how Misago works currently:
You request https://misago-project.org . Django view gathers data to render list of threads. Django view renders template that contains almost complete HTML with list of threads, but also includes a JSON with same data used to render this HTML. And there is no interactivity because forms are disabled. JavaScript downloads. JavaScript runs, reads JSON embedded in the page's body and replaces most of HTML rendered from Django templates with HTML from React.js components. Buttons become active, and timestamps in UI swap.
This approach has some problems:
A lot of pages in Misago are implemented twice: as Django templates and React.js components.
People who start customizing HTML get burned because they edit Django templates and see their changes flash for a second on a site before being replaced by React.js HTML which they didn't know they also need to customize.
Every view accessible to both users and guests needs to be done twice: as Django view with templates, and as React.js route with components. It also requires an API and JSON serializers to power data fetching.
JSON serialization to pre-bake data for React.js app slows down response generation.
A large part of translation messages is duplicated, living in both django.po and djangojs.po files. JavaScript translation files also increase the initial download size.
and files. JavaScript translation files also increase the initial download size. Lots of JavaScript can kill performance, especially on older and slower mobile devices.
Enabling plugins to replace or inject custom HTML to the page requires for those plugins to implement both Django templates and React.js components. And Misago will need to implement a JavaScript build step as part of site build in misago-docker . Plugin devs need to know both.
... continue reading