Would it be worth holding off on this for a bit and
then putting it in the
Agora extension when we've got it put together, then? The entire point of
the extension (well, other than "stop increasing developer workload and
long-term maintenance duties" and "don't make Roan cry by breaking
protocol") is to allow us to make small, iterative tweaks structured in
such a way as to avoid FOUCs.
On 14 November 2012 16:12, Erik Moeller <erik(a)wikimedia.org> wrote:
On Wed, Nov 14, 2012 at 5:47 AM, Steven Walling
In the interest of not waiting any more, my
instinct is to deploy the
JS-reliant version, and defer perfecting the
implementation based on
patches get submitted. :)
I would prefer that we not get too much in the habit of accepting
degradation of front-end performance and long term maintainability of
our codebase in order to push features out the door more quickly --
especially where it concerns code that gets loaded on every pageview.
Existing poor practices and problems are not a good reason for
exacerbating the issue (and indeed setting a poor example will reduce
our ability to set standards for others).
As you yourself say, site performance really matters, and that
includes flashes of unstyled content and DOM changes that shouldn't be
necessary. Moreover, JS cruft leads to maintenance burden down the
I'm very accepting of doing this when our objective is to learn
whether something is working or not (cf. ACUX). But the moment we
actually decide that a change makes sense, we should implement it at a
reasonable level of quality instead of layering on cruft.
So if you want to make the decision now that this change makes sense
based on the data we already have, please do a clean implementation
first. It can't become someone else's problem to do so.
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Design mailing list
Community Liaison, Product Development
Design mailing list