MobileFrontend/JS code organization

Current state
Currently JavaScript code in MobileFrontend is divided into separate modules. Each of them is responsible for a distinct feature in the mobile frontend, e.g.  folds and unfolds sections in articles,   adds additional feature to the mobile watchlist (thumbnails). The concept is similar to plugins.

Some modules use the  function which expects an object with an   function as its argument. After the main code is initialized the  function of each module is called.

Other modules simply do something without ever calling, which can be binding to an event of the   object or performing some actions after the DOM is ready.

There are no guidelines as to how modules should look like. They are usually a collection of functions that perform everything needed for the given module without following any programming paradigms. Object oriented patterns are not used, there are no separate objects which would take care of different parts of a particular feature, like interpreting data from APIs (model) and building user interface (controllers/views/templates).

Very often a single JavaScript function has multiple responsibilities, like fetching data from API, fetching data from DOM, manipulating this data and rendering the user interface.

Problems
There are two main problems with our current JavaScript code:


 * Lack of code modularity, lots of functions that "do everything" (this is not about splitting code among many files, it's about enforcing Separation of concerns).
 * Lack of a standardized module system (just loose JS files).

Code modularity
The lack of code modularity has three consequences:


 * It makes code reuse or even noticing that a part of the code could be reused harder.
 * It makes reviewing the code more tedious. When even a small change is introduced in a large function that has many responsibilities, the reviewer often has to reread the whole function to understand that small change.
 * It makes testing more difficult. A piece of code that has many responsibilities can not be unit-tested which often leads to not testing that code at all.

TODO: add example of tangled code and how it can be untangled (modularized)

Module system
The lack of a good module systems has the following consequences:


 * Modules do not inter-operate, i.e. one module can't use another module's functionality easily. Right now we put all the functions we need in several places in mf-application.js but this file keeps growing and the functions it contains are often not related (e.g.  and  ).
 * There is no dependency management (there is no way to indicate that a module requires any other module to be loaded before it can run, we have to manually figure out loading order of JS files in PHP files).

Solutions
Developers struggled with JavaScript code organization in many other big projects before us, so the most obvious solution to make the code more modular would be to use one of the popular JavaScript frameworks to structure the code. Apart from that we need to standardize our modules somehow.

Frameworks
There are two important things to note where it comes to our mobile frontend though if we are to use a framework:


 * We use various data sources. Typically, web apps rely on a standardized AJAX API to get data. We have many APIs that sometimes don't follow guidelines and are not RESTful. We also often fetch required data from the DOM of the server-side generated web site (e.g. titles of articles in the watchlist to query the PageImages extension). This means we need really flexible models.
 * Our web app is not a typical one-page web app where everything is loaded dynamically. It's more of a hybrid between a web site and a web app. The main reason for this is compatibility with devices with no JavaScript support. In the future we might think about separating it into a legacy mode without JS and a one-page dynamic web app. This would make the development easier and the mobile fronted more responsive.

The framework we choose should satisfy the following:


 * Be popular, with active community and good docs.
 * Be small (mobile).
 * Be flexible, do not impose too much on how we communicate with the backed or how we modify DOM.
 * Do not assume a fully dynamic one-page app.

Modules
Right now modules are just scripts that do something by themselves and optionally have an  function. It would be useful to have something similar to AMD modules. We should investigate if Resource Loader can help us with that.