Change Details

- identify the pain points of mobilefrontend in terms of difficulty, efficiency, and ease of building and maintaining features from their perspective - brainstorm optimal solutions - provide result to whomever {T156259} is assigned to --- =Results= ##Pain points Unless otherwise specified, bullet points refer to front-end code. * More than 1000 lines of JSON configuration with order of files and dependencies. Manually specifying and reasoning about the dependencies between files is error prone and has caused us many problems. * Unit tests take too long to run since they require a running instance of mediawiki, so each test run needs to load a page and all the resources from the server. This complicates doing test driven development because of the long feedback cycles. * Many unit tests are integration tests. * Tooling runs through grunt, making it slower than it should. * Example, running eslint directly from the cli, instead of using grunt, usually takes half or even a third of the time for doing the same linting. * There are no code coverage reports, and when we had them we were at a quite low coverage. * Too many style sources. There's probably a lot of unused styles. * No CSS naming convention, really hard to know what html a selector will affect to. Hard to know if changes will change styling in unexpected places * Tooling is php based and outdated. There's more modern tooling like uglify that would shave the size of our files by a big chunk, or newer lessc compiler versions that fix bugs and add good features. * Can't use front-end libraries from npm. * Templates aren't pre-compiled, resulting in sending the compiler and the source to the client, and compiling it there. Mobile browsers are under-powered and shouldn't be doing any of that. * Code complexity seems to be high and quality low (hard to quantify, here are some things to look at): * Responsibilities are coupled (view + logic + fetching in the same place, big methods that do a lot) * Tests are full of stubs/mocks, which indicates high coupling of the artifacts and not good design * 1 level deep file hierarchy because of restrictions to run all tests automatically or otherwise having to manually specify all the tests files in proper order and dependencies. * Complicated to reason about the code entry points on a given page. Resources are added from many different places, php pages, hooks, on the module definitions. * No live UI components style guide. * jQuery is big and heavy to parse and run. Is it really needed in the mobile site given the clients it serves? Can we improve performance by not using it?

- identify the pain points of mobilefrontend in terms of difficulty, efficiency, and ease of building and maintaining features from their perspective - brainstorm optimal solutions - provide result to whomever {T156259} is assigned to --- =Results= ##Pain points Unless otherwise specified, bullet points refer to front-end code. * More than 1000 lines of JSON configuration with order of files and dependencies. Manually specifying and reasoning about the dependencies between files is error prone and has caused us many problems. * Unit tests take too long to run since they require a running instance of mediawiki, so each test run needs to load a page and all the resources from the server. This complicates doing test driven development because of the long feedback cycles. * Many unit tests are integration tests. * Tooling runs through grunt, making it slower than it should. * Example, running eslint directly from the cli, instead of using grunt, usually takes half or even a third of the time for doing the same linting. * There are no code coverage reports, and when we had them we were at a quite low coverage. * Too many style sources. There's probably a lot of unused styles. * No CSS naming convention, really hard to know what html a selector will affect to. Hard to know if changes will change styling in unexpected places * Tooling is php based and outdated. There's more modern tooling like uglify that would shave the size of our files by a big chunk, or newer lessc compiler versions that fix bugs and add good features. * Can't use front-end libraries from npm. * Templates aren't pre-compiled, resulting in sending the compiler and the source to the client, and compiling it there. Mobile browsers are under-powered and shouldn't be doing any of that. * Code complexity seems to be high and quality low (hard to quantify, here are some things to look at): * Responsibilities are coupled (view + logic + fetching in the same place, big methods that do a lot) * Tests are full of stubs/mocks, which indicates high coupling of the artifacts and not good design * 1 level deep file hierarchy because of restrictions to run all tests automatically or otherwise having to manually specify all the tests files in proper order and dependencies. * Complicated to reason about the code entry points on a given page. Resources are added from many different places, php pages, hooks, on the module definitions. * No live UI components style guide. * jQuery is big and heavy to parse and run. Is it really needed in the mobile site given the clients it serves? Can we improve performance by using DOM apis instead?

- identify the pain points of mobilefrontend in terms of difficulty, efficiency, and ease of building and maintaining features from their perspective - brainstorm optimal solutions - provide result to whomever {T156259} is assigned to --- =Results= ##Pain points Unless otherwise specified, bullet points refer to front-end code. * More than 1000 lines of JSON configuration with order of files and dependencies. Manually specifying and reasoning about the dependencies between files is error prone and has caused us many problems. * Unit tests take too long to run since they require a running instance of mediawiki, so each test run needs to load a page and all the resources from the server. This complicates doing test driven development because of the long feedback cycles. * Many unit tests are integration tests. * Tooling runs through grunt, making it slower than it should. * Example, running eslint directly from the cli, instead of using grunt, usually takes half or even a third of the time for doing the same linting. * There are no code coverage reports, and when we had them we were at a quite low coverage. * Too many style sources. There's probably a lot of unused styles. * No CSS naming convention, really hard to know what html a selector will affect to. Hard to know if changes will change styling in unexpected places * Tooling is php based and outdated. There's more modern tooling like uglify that would shave the size of our files by a big chunk, or newer lessc compiler versions that fix bugs and add good features. * Can't use front-end libraries from npm. * Templates aren't pre-compiled, resulting in sending the compiler and the source to the client, and compiling it there. Mobile browsers are under-powered and shouldn't be doing any of that. * Code complexity seems to be high and quality low (hard to quantify, here are some things to look at): * Responsibilities are coupled (view + logic + fetching in the same place, big methods that do a lot) * Tests are full of stubs/mocks, which indicates high coupling of the artifacts and not good design * 1 level deep file hierarchy because of restrictions to run all tests automatically or otherwise having to manually specify all the tests files in proper order and dependencies. * Complicated to reason about the code entry points on a given page. Resources are added from many different places, php pages, hooks, on the module definitions. * No live UI components style guide. * jQuery is big and heavy to parse and run. Is it really needed in the mobile site given the clients it serves? Can we improve performance by not using itusing DOM apis instead?