Resource Loader dependency management feature was not design to also host this kind of use-case.
- Our frontend codebase in Wikibase Repo is pretty modular which is good but we are using RL for dependency management and class loading resulting to have 300 RL modules with a very complex dependency relationship that causes TTFB to be high and pretty big network overhead (e.g. T203696: Drastically reduce the number of ResourceLoader modules that WikibaseClient registers: "It looks like Wikibase is trying to use ResourceLoader as a class loader(!) which may be difficult to quickly re-architect, but any reduction would be worthwhile.").
- Testing modules and developing them is rather hard due to the deep integration with RL.
- RL's minification method is also a little bit outdated and inefficient (See T49437: Consider a pipeline for enhanced minification (e.g. support UglifyJS)). Webpack solves or improves all of these issues.
- Currently we can't use ES6.
- We can combine RL modules and reduce their number in Wikidata's production to decrease the traffic sent to users and TTFB
- It has better minification than RL.
- it has been already done and used in our production for MobileFrontend skin T195475: [EPIC] Automate asset bundling in MobileFrontend T207787: [EPIC] Reduce the amount of modules in MobileFrontend T194098: Reduce number of different MobileFrontend bundles
- On performance: Webpack is not the only mean to improve performance.
- Every module removed from lib or client will have ~30GB/day reduction on network. We planning to drop probably around 10-20 of them
- Every module removed from view or repo will have ~55 MB/day (wikidata) + 90 MB/day (commons) reduction on network. We are planning to drop probably around 100-200 of them.
- TTFB is hard to measure. Can be measured afterwards.
- The network reduction due to using webpack instead of RL manification is hard to measure. Can be measured afterwards.
Estimated Trailblazing length
couple of weeks (2-3 weeks for 100-150% FTE)