How and why we moved our skins to Mustache
As part of the desktop improvements project we spent time investing in the core code that powers skins. With support from volunteers (the majority of this support coming from the prolific @Ammarpad), we identified code patterns and made changes to the MediaWiki-Core-Skin-Architecture to retroactively define a data layer API for generating a skin.
Should Vector be responsive?
Here I share some thoughts around the history of "responsive" MediaWiki skins and how we might want to think about it for Vector.
Creating a vue.js based skin with server side rendering
For WMF staff's inspiration week, I decided to take a step back from my work building out a new skin architecture and a redesign of Vector and put myself into the shoes of a skin developer to see if the changes my team had made life easier. As a secondary objective, I was interested in how a MediaWiki skin could be written in Vue.js and what the challenges were to get there.
All code is built
HEADER CAPTION: The head of the Statue of Liberty on exhibit at the Paris World's Fair, 1878. The statue was built in France ahead of time, shipped overseas in crates, and then assembled in New York. Image by Albert Fernique / public domain.
The best documentation automation can buy
HEADER CAPTION: Screenshot from Wikimedia's famous Visual Editor. The typo "documenation" has a red squiggly line under it indicating the spell checker has automatically detected a spelling error by the author.
Why does building a skin require PHP knowledge?
One of my longstanding pet peeves is that skin development for MediaWiki is so hard. I propose a radical change to how skins are installed and ask for feedback.
Migrating code from MediaWiki's ResourceLoader to Webpack
The lack of tooling or support for tooling has been causing problems in complicated code bases like the codebase for our mobile site, so we carved out a proposal to create a bridge from our existing codebase to a more modern one using Webpack. I'll talk about what we did and why.
Minimal MediaWiki for frontend engineers
I use OSX. Vagrant has not been kind to me, but I'm hopeful that Docker will make development a lot easier for me in future.
Until then, I use MAMP which provides a pretty easy LAMP setup. I wanted to share it with other frontend engineers as this minimal setup works well for me - it's fast, it minimises the extensions I need to update and most importantly brings me closer to problems with frontend end-users are experiencing.
Page previews front-end tooling: Conclusions
Fast and isolated JS unit tests
Table of contents - Versions: HTML, Markdown
Better minification for the frontend sources
Table of contents - Versions: HTML, Markdown
Automatic JavaScript file bundling and library consumption
Table of contents - Versions: HTML - Markdown
Extension:Popups (Page Previews) front-end tooling
Extension:Popups is a MediaWiki extension that shows previews when hovering a link in a popup.
mustache.js replaced with JavaScript template literals in Extension:Popups
The Popups MediaWiki extension previously used HTML UI templates inflated by the mustache.js template system. This provided good readability but added an 8.1 KiB dependency* for functionality that was only used in a few places. We replaced Mustache with ES6 syntax without changing existing device support or readability and now ship 7.8 KiB less of minified uncompressed assets to desktop views where Popups was the only consumer.
Beacons
The Reading Web team recently discovered a bug in Firefox wherein a load event is fired when Firefox loads certain pages from its Back-Forward Cache (BFCache). To JavaScript on those pages, this event is a second load event (the first having been fired before the user navigated away from the page). This proved to be problematic for the cornerstone of our instrumentation, the EventLogging extension and delayed the deployment of Page Previews for approximately three months.